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.

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.

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.

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.

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.

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.

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.

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.

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?

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."

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.

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.

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.

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.

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.

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.