FB Web Tips

Speaking With jQuery’s Core Team Lead: Dave Methvin

By Rey Bango

Most of us are familiar with the jQuery JavaScript library, and likely use it in at least some of our projects. But how much do we know about the people who tirelessly give their time to maintaining the web’s most popular JavaScript library? I recently had the chance to interview jQuery Core Team leader, Dave Methvin, and discuss how he became involved with the project and where he sees front-end development headed. He’s been a contributor to jQuery since 2006, and is also the President of the jQuery Foundation.


jQuery’s success has made it difficult for us to change anything.

Q Tell us about your professional background. How’d you get into JavaScript?

I started my career as a full-time C programmer doing embedded systems stuff like shipboard navigation, robotics, factory automation, and telecommunications. After that, I moved into computer journalism and wrote a JavaScript column while I was at Windows Magazine. When WinMag closed its doors, I co-founded a startup that built a JavaScript- and HTML-based system utility for Windows thatbasically automated a lot of the advice we used to give in the magazine.

Q Which road led you to jQuery, and when did you join the team?

When I was at the startup, I was looking for a better way to organize the JavaScript and HTML we were writing. I saw John Resig’s 2005 blog post describing what eventually became jQuery. I sent him an email and he replied saying he was setting up a mailing list for interested people.

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?

Khan Academy

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?

Bug tracker

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?

jQuery Core has the ability to be used as an AMD-named module and loaded dynamically. In general, named modules are frowned upon, but so many jQuery plugins expect to share a global jQuery object. I am not satisfied with the current state of JavaScript module loading, and I prefer a simple combine-and-minify process for most of the work I do. Still, AMD is popular enough that we wanted jQuery Core to support it so that AMD users can load jQuery from a CDN for example.

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?

jQuery Mobile

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.

Source: Nettuts+

I've worked very hard for this, so please help me by donating a cup of coffee. Thanks in advance.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *