Absolutely. My name is Addy Osmani, I’m a JavaScript developer to AOL ; I’m also on the jQuery Team, I’m on the number of sub-teams there. I contribute to a few open source projectors like Modernizer and I love making a lot of it a little bit better.
One of the biggest things that I’ve seen missing over the past couple of years is better modularization and what we’ve seen is the introduction of sort of temporary measures like AMD, asynchronous module definition and CommonJS as efforts to try giving developers something they can use right now.
Luckily, if you take a look at ES Harmony or the next version of JavaScript, it looks like we’re already gonna be getting better module formats and that’s definitely gonna help developers structure their code a little better in the future.
Sure, one of the reasons to use a library like Backbone or Ember or any of those structures solutions is that it helps you organize your code a little bit better; gives improved structure to your application; it helps you through separate concerns as well; so, a lot of the time these days, developers are using what are known as MVC frameworks; they’re really not necessarily MVC but they do help you sort of separate your concerns and in models views, and other components that maybe are a little bit more distinct.
And it just means that it’s easier to identify what is the presentation layer; where your logic should go and how you should be going about sort of adding other bits and pieces through your application. The reason to use those of types of solutions is that, you know, if you’re writing your own framework, you can, of course, do that but it requires that you fully understand design patterns like MVC if you’re gonna go about trying to say, “Okay, well, the data from application is gonna go on to models and the logic is gonna go into other controller,” or view if you’re talking about some frameworks. But it saves you a lot of time coming up with your own solution basically.
4. Have you seen similar like home-made solutions for this frameworks?
All the time. A while back, I created a project called, ToDo MVC and, as part of that, to make it easier for developers to actually figure out which ones of these framework to use. We actually implemented the same application in about 15 or 16 different frameworks; some of which are rather new or homebaked by their authors.
And it’s interesting, it seems like every developer has a slightly different take on how applications should be structured; and sometimes we’ll find that there are ideas in there that some of the existing libraries or things that have been mature have been around for a while and may not have thought about before.
In a lot of cases, you’ll see a lot of repetition in terms of their models, their views, and people don’t necessarily detract from that too much. What I find is …one of the reasons why I’m writing a book about Backbone and why I like Backbone is that it enforces a really clean structure for structuring your application but it’s also flexible enough that if you want to use it in a slightly different way, I know that many of the Backbone contributors, people who’d actually make codes use it quite differently to have the documentations says but it’s flexible enough that you can do pretty much with it whatever you want.
The past couple of years we’ve really started to recommend developers stop user-agent testing. Unfortunately, it’s just not that reliable and in a lot of cases, they’re gonna be browsers that inform the user that they’re one type of user agent when there might be something completely different. There are other cases where the form of user agent testing that you’re doing may not be reliable and just knowing what a browser is, isn’t necessarily gonna give you all the information that you need like: what features that it actually support? And this is one of the reasons why feature detection has really taken off. You’re able to fairly easily test what APIs or features that particular browser support. And it allows you to be more granular with your approach to solutions.
You can say, “Okay well, my browser supports maybe WebGL, I’m going to load up the scripts to that,” or, “My browser supports HTML5 video, etc.” And Modernizer has really made it very, very trivial for developers to be able to make those kinds of tests in application and extra logic in its presence.
Absolutely, so there aren’t really that many special debugging tools that we use with us. We do heavily use jsFiddle for sharing our test cases and we make sure that if anyone is submitting a test case saying that there’s something wrong with the library; that it is either on jsFiddle, or JS Bin; and that just means that it’s very, very easy for us to go and test out that case and try reproducing the behavior regardless of what browser it is reported about.
7. Aren’t you getting a lot of edge cases?
We do get a lot of edge cases. There are a lot of, you know, I need this fixed in the library; I need you to fix this, I need you to patch it for the next version. And we have to make decisions about, you know, “does that make sense for all the other millions of users actually using the library?” There’s quite a lot of effort that goes into deciding every single extra bite that has goes in there are features that might take a year or two even to the bit being included and unfortunately, you know, if there’s an edge case that we don’t think people we’ll gonna be running into that much we’ll just say, “turn it into a plug in,” or just be aware of the fix needed and document it and that’s it.
Yes. I mean with jsFiddle there are some cases where you’re not able to do everything it’s nice when it comes to AJAX testing and try to do things asynchronously. But there have been places where we need people to actually upload local files that they’re testing in order for us to reproduce the behavior. Sometimes, you know, jsFiddle being online means if people run into an issue with something being accessed over file that’s not something that you can easily reproduce but other than that it’s been fairly reliable although we have to say.
So unit testing it is extremely important obviously and I’ll talk about that for a moment, you simply can’t especially when it comes to putting out libraries that a lot of it we’re gonna be using. It’s essential that you test out every single part of that library works as you expect it and as other people expect it. When you write something, something you’ve learned quite quickly if it starts to pick up paces that people will throw things at it that you don’t expect a lot of the time; and even if, you know, as a library author or as a contributor you find that those cases are silly or that perhaps you don’t agree with them it is still important to make sure that you’re libraries are robust enough to be able to handle those cases and not fall over for example.
In terms of other types of testing beyond that not necessarily as specific to jQuery you got everything from UI testing using Selenium tools and things like that to BDD testing which I’m very much a fan of it at the moment. I think that there are not enough people perhaps understand BDD and TDD at a point where they realize it’s worth investing their time into but, you know, if you do the decide to go on the BDD route, I definitely recommend checking out Jasmine and Sinon.js, Qunit is of course used by jQuery and you can use Sinon with that teach you some quite some of the things but beyond that not really.
I would say that if you can break down the problem to its fundamentals it is usually possible to put together a unit test for it. So when you were saying you can’t track if a box overlays another box, you can actually use a headless browser for testing there or you can wait until the domain’s ready and it is actually rendered those two items and then you can asynchronously put together a test that will get all their positions and find out, you know, if their x’s and y’s cross over each other. So in a lot of cases something more advanced doesn’t necessarily need it just means thinking a little bit more deeply about the problems that you’re trying to detect.
It can add some overhead but I think you have to balance off the costs of putting out some solutions out there and application out there or service out there that isn’t as robustly tested versus something that requires 30% extra time. In a lot of the businesses that I’ve spoken to they’ve found that that added amount of time is okay, you know, they won’t necessarily go all the way of the Selenium testing maybe they’ll say, “Okay. Well there’s a certain level that we’re okay hitting for our first launch or first release.” And then we’ll go all the way for the next one and sometimes they can help balance out the time issues at least.