jQuery’s success has made it difficult for us to change anything.
Q Which road led you to jQuery, and when did you join the team?
So suddenly, there is this group of very talented folks discussing the library.
A lot of them are still with the project to this day. This is one of John’s little-known talents and a big reason for jQuery’s early success; he is very inclusive and open to input from everyone.
Q When did John turn the project over to you and why?
I officially took jQuery Core’s reins in July of 2011, although I had been doing quite a bit of work on it before then. As for why? I think John was looking for his next big challenge, one that he seems to have found at the Khan Academy.
Q Since you’ve become lead developer, how has that affected your views of the direction of the project and the community?
jQuery’s success has made it difficult for us to change anything, even if it’s a change for the better, such as a bug fix or improving consistency of the API. Because about half of all Internet sites use jQuery, we can be pretty sure that any change we make to the library will be a breaking change for someone. Although we do betas, the vast majority of users like to wait until it’s final before trying the new code – meaning we are often flying blind when it comes to knowing the impact of a change.
jQuery Core is a library to simplify the traversal, manipulation, and retrieval of HTML documents.
Q What shifts have you seen in community expectations? What are people asking for?
When jQuery arrived in 2006, web developers knew the browsers’ quirks and were happy to have jQuery get them to the 90 percent mark for cross-browser compatibility. Many of today’s developers never lived in that world and are surprised that jQuery can’t make every little difference disappear across browsers. But there are limits to how well we can work around browser problems; developers need to understand that. Many times, the solution uses a simple fix at the application level, or to use a plugin that addresses some specific rare case.
Q Being an all-volunteer effort, how does the project manage these requests? For example, how are they prioritized?
Bugs are prioritized by whether they are a regression, their overall impact on the community, their severity, and the complexity of a fix. Most of the non-regression problems are edge cases or browser bugs bleeding through to the jQuery API. Our challenge is to fix these without creating a mass of complex workarounds that most people don’t need, and introducing further bugs in the process.
Q There’s been a bit of sniping at jQuery lately, to the point where some in the community look down at developers that use the library. I think it’s silly and nonsense, especially when other efforts like Backbone and Ember actively promote jQuery as complementary. What’s your take on this?
Since jQuery makes it easy to put some awesome effects together using just a few lines of code and some third-party jQuery plugins, it’s inevitable that non-professionals will try their hand at using it. Sometimes they’ll succeed, and other times they’ll make a big mess that someone needs to come in and clean up. I don’t see any solution to that “problem” other than making jQuery more obtuse so only professional programmers can figure it out. That’s not going to happen.
Q Do you think that some of the dissenters forget the complexities of cross-browser development?
Even if you take out IE 6/7/8 there is a LOT of code in jQuery to smooth out browser bugs and inconsistencies. I was somewhat depressed to see how many of those lines had to remain for jQuery 2.0. It seems that all the browser makers are too busy implementing shiny new features like CSS3 to go back and fix basic functionality. And why should they bother to fix it, since jQuery fixes it and therefore nobody complains to them?
Q Along those same lines, where do you see jQuery fitting in the library ecosystem with so many new frameworks emerging like Angular and Ember?
The MV* frameworks are where DOM libraries were six or seven years ago when jQuery arrived on the scene. There is a lot of diversity in their approach to design, which is a good thing. Most of these frameworks are happy to let jQuery take on the cross-browser DOM issues so they can focus on higher level application design concerns. We’re definitely complementary to their efforts.
I like to joke that “Core ain’t done until UI won’t run.”
Q Where do you see jQuery’s sweetspot?
jQuery Core is a library to simplify the traversal, manipulation, and retrieval of HTML documents. Sometimes people want to push the boundaries and ask why we don’t support SVG, VML or other webbish technologies, but that’s what plugins are for. We want to keep jQuery’s API focused on DOM operations. Going beyond that in the core library would add a lot of bloat that few people need.
Q Can you explain how jQuery fits into the CommonJS/AMD discussion?
Q jQuery 2.0 will focus solely on modern versions of Internet Explorer. Some view this as anti-IE. Can you explain this decision around it and what it means to IE users?
The workarounds for IE 6/7/8 account for more than ten percent of the total jQuery 1.9 library size, and those workarounds also impact performance. There are many places where these workarounds just aren’t needed, such as Windows 8 apps, Chrome and Firefox plugins, PhoneGap/Cordova apps on a specific mobile platform, or node.js programs where a library like Cheerio is used to load jQuery.
That is the primary audience for jQuery 2.0 at the moment; most Internet web sites should continue to support those older versions of IE by using jQuery 1.9.
For example I can’t see the Target or Wal-Mart websites using jQuery 2.0 for at least a few years; IE8 users have money too! Since the two APIs are in sync, it’s possible to use conditional comments to include one or the other for a specific browser, but to be honest, I don’t think it’s worth the effort.
Q The jQuery project encompasses not only jQuery, but jQuery UI, jQuery Mobile and QUnit. When building out the jQuery roadmap, what considerations do you need to make to account for these other efforts?
Since jQuery UI and Mobile depend on Core, we consult them on roadmap issues where needed. Those projects also run their unit tests against our most recent build directly from Github so that we immediately know if we broke something. Still, I like to joke that “Core ain’t done until UI won’t run,” and there is usually a few glitches we find after each release. QUnit is a bit different; we are their client. We sometimes ask them for features, and on occasion, their updates break our unit tests. So we get a taste of our own medicine.
Q jQuery events are no longer jQuery-specific. Would you like to discuss why the project chose this route?
We see the jQuery Conference as a gathering for developers who create web sites and web applications. Some of what they want to know is about jQuery, but we don’t want to stop there. Any good developer should expand their horizons and continue to learn tools and techniques that can help them improve.
Q What are the trends in front-end development that you see and recommend developers to keep an eye on?
Innovations are coming from all directions. The MV* framework wars are likely to yield some much better and faster approaches to develop web apps and sites; no doubt we’ll see some consolidation there, similar to what happened with jQuery.
Responsive design is another big topic, and I hope improvements in CSS and responsive images will make it easier to implement in the coming year.
On that last point, jQuery is working with the standards groups at W3C and ECMA to ensure that the web developers in the trenches are represented when making decisions.