In this meeting, John will talk about jQuery and its future releases and share with us some professional tips to help us to get better applications. In addition he'll talk about his projects, as Sizzle and Dromaeo, and the browser Firefox.
John: HTML was one of the first things that I learned just after I started programming (back in about 1997/1998). I was doing QBasic when a friend showed me how to set up a web page (using Angelfire, no less) and the basics of HTML. That Christmas my Dad picked me up two books on HTML - I devoured them. It was so much more expressive than anything else that I had seen. Around that time I also started doing some Visual Basic but I was hooked on HTML and Web Design.
Riccardo: Among the huge amount of jQuery components which was the most difficult to develop?
John: I'd have to say the event core of jQuery. It's something that seems like it should be really simple and straight-forward to develop but there are a number of gotchas involved. Extensibility, performance, and confined code are paramount within an event implementation and it's hard to get all of them right.
Riccardo: jQuery offers a big flexibility to developers for creating end extending it with personal functionalities. In your opinion, when should a developer create his own plug-in instead of use the basic functionalities offered by jQuery? Can you give us a simple example of this?
John: Any time a user has a piece of reusable code they should probably make a plugin. It's a great way to simplify redundant pieces of functionality on a case-by-case basis. There are hundreds of jQuery plugins out there each meeting different purposes for different developers - which is great. A plugin doesn't have to be completely generic, either. For example Digg.com uses jQuery and they have some small, custom, plugins that work just for their site - which is fine. Those plugins help them to develop easier and in a more-reusable way, which is what every developer should strive for.
Riccardo: What are your future projects? What kind of news should jQuery users wait for?
Riccardo: Web application developers know that there are many other important frameworks in the Web, like Prototype, Dojo, MooTools, Ext and so on... In your opinion why should a developer choose jQuery to develop his applications?
John: I feel that a developer should choose jQuery over another library if - and only if - jQuery feels right to them. If they're able to pick up jQuery, code with it, and it just works for them. If it's not able to meet that goal - and, really, if any library isn't able to meet that goal - then it shouldn't be used. I'm confident in the quality of the library, the community, and the documentation which is why I really think that jQuery should be tried first-hand.
Riccardo: We know in the Web there are many resources linked to jQuery. What would you advice to a new developer, who wants to start using jQuery in his own applications, to learn to get best results?
John: Start with the jQuery tutorials, play around with some simple functionality and just familiarize yourself with the library. Probably the worst way to start using jQuery is in doing a massive port from one library to another. Just do it in steps - immerse yourself in the jQuery way of writing code and you'll end up with an end result that's better because of it.
Riccardo: Looking at your projects I found out that you are now developing a new "Selector Engine" named Sizzle, that will probably become the official jQuery selector engine. Which are the advantages of this engine compared to the one used at the moment in jQuery?
John: It's faster than the engine that's currently in jQuery while being more extensible, as well. It was really important for me to have an engine that was fast without sacrificing the extensibility that most engines provide. I'm also working with other libraries to try and get Sizzle integrated into their code bases, as well.
John: Thank you - I think Processing.js is pretty cool as well. I think the Canvas element is fantastic. It provides a whole realm of new functionality to developers. I think most developers don't realize how usable it is. They can start using it *today*, in all browsers, no hesitation. It's incredibly fast (much more so than SVG for a lot of simple functionality) and the result looks great. That being said I think it's going to be a while before all browsers are truly able to match Flash feature-for-feature - but we're getting close. Firefox 3.1, for example, is going to have Canvas and SVG support (drawing and interaction) and Audio and Video tag support - which, all together, is a big part of what developers use Flash for.
Riccardo: Recently I have written on Edit about the collaboration between either jQuery and Microsoft and jQuery and Nokia.
“Microsoft is looking to make jQuery part of their official development platform”, told the official Query blog. What do you think about this great news? What kind of impact will this new feature have on the jQuery community/development? Should jQuery users expect additional news/features?
John: We're quite excited about our relationship with Microsoft and Nokia. I don't think there will be any specific new features related to these companies. We're going to continue to work and bring the best features possible for all jQuery users. As it happens, the things that interest Microsoft and Nokia are the same things that all jQuery users want: Speed, stability, better documentation, etc. We will continue to work on those to improve the overall quality of the library. It isn't sexy but it's incredibly important for the longevity of the library.
Riccardo: John, tons of developer would love to know the secrets and the ways you write Javscript code and, therefore, jQuery. Do you use any particular or specific techniques when writing jQuery and its marvellous APIs (for example, testing the performance with Dromaeo)? How can a simple script or a plug-in become part of the official jQuery core and when it can be considered “stable” by the Team?
John: A big thing that we find to be important, in the jQuery team, is unit testing. Since there are a large number of developers potentially contributing to the jQuery code base we need to make sure that all new contributions are vetted for quality. Unit tests help us to make sure that we maintain that level of quality going forward. That's the biggest thing that I've found, in my personal development, that has helped me in developing cross-browser code.
Additionally, having performance test suites (such as Dromaeo) has been just as important for being able to improve the speed of jQuery as a whole. The tools in this area are still very new but the ones that we've built have been very helpful. For example this, like this deep profiling tool that I built: http://ejohn.org/blog/deep-profiling-jquery-apps/
In order for a plugin to become part of core it has to meet a number of properties. The most important of which is its overwhelming use by the community. It needs to be used by a large number of users and/or be a dependency of a large number of plugins. After that time we evaluate it for quality and then decide to include in jQuery core. Of course the code has to meet the same level of quality that jQuery has (unit tests, good code style, etc.).
More than anything else, though - you have to continue to develop new code. Stagnating will only lead to your skills going to waste, which would be a shame.
Second, a developer should worry about cross-browser compatibility of their application first (make sure it passes a good set of unit tests) before moving on to work on performance. If you can be sure that your code is already working as you expect it to then you can feel safe in knowing that the performance improvements that you're landing won't break your existing application.
Riccardo: The last but not the least: Firefox. We know you are fully involved with the Mozilla Corporation. What kind of news should Firefox users wait for with the future releases?
Riccardo: Thank you John for the completeness and the elegance that you have used!
John: I'm really glad that you liked the responses. It's been a pleasure.