In the eight years since its initial release, jQuery has become the foundation of the modern Web. The popular cross-platform library has become bundled and intertwined with countless websites, developer tools and with JavaScript itself.
The next step for the open-source platform is jQuery 3.0. In a recent blog post entitled “jQuery 3.0: The Next Generations,” jQuery development team core lead and jQuery Foundation president Dave Methvin previewed what developers can expect going forward in jQuery’s next release. SD Times spoke with Methvin about the rise of the JavaScript library over the past decade, how jQuery has changed and where the platform, and ultimately Web development, is headed.
SD Times: In your blog post, you talk about how jQuery has changed along with the Web over the past several years. As team lead, can you describe how you’ve observed and shaped how those changes have manifested in the development of the library?
Methvin: Developer practices have gotten much more disciplined over that time, so for example things like browser sniffing were very popular years ago, but are considered a bad practice today. In early 2013 we released version 1.9 that removed jQuery APIs that encouraged bad practices, but also provided a jQuery Migrate plug-in to help developers identify and remediate their code.
During this time we’ve also made jQuery modular so that developers focused on the smallest possible file size can exclude parts they don’t need. If they use CSS animations exclusively, for example, they can exclude jQuery’s animation methods.
When we last checked in with jQuery, the project was knee-deep in jQuery Mobile, challenging UI conventions to bring more mobility to JavaScript. Would you say that goal has been achieved, and how has it changed along with the evolving Web landscape?
I don’t think we’ll ever be done with evangelizing important goals like accessibility, internationalization, and cross-browser design. As far as code goes, we’re in the process of merging the UI and Mobile code. There’s not a bright line between the two now that phones are as powerful as desktops.
How exactly are you realigning browser support policies and why? How does jQuery Compat 3.0 factor into it?
Previously, we tried to indicate browser support using the version number. The 1.x versions were compatible with older browsers like IE6, 7, and 8 but the 2.x versions only supported recent browsers. However, the two versions were actually compatible API-wise with one another. This led to confusion, because it’s not typical for major versions to be compatible like that. Thus, we came up with the 3.0 naming and two different packages: “jQuery” that supports only modern browsers and “jQuery Compat” that supports older ones as well.
What’s the thinking behind the decision to shift to semantic versioning and what does that signify for jQuery?
This is another change driven by modern best practices. Semantic versions usually indicate API compatibility, but we were using them to indicate browser compatibility. By separating jQuery into two different packages with the same version, we’re making it clear that the two are API compatible.
We don’t anticipate that jQuery 3.0 will break a lot of existing code, and we plan to update the jQuery Migrate plug-in to warn about most of the things that are changing. Even so, when you think about how widely jQuery is used, just about any change we make could be a breaking change. So we’re exercising caution.
What can Web developers and the open-source community expect in terms of other new features and improvements in jQuery 3.0? What else does the dev team have in the works?
Let’s be clear, this is not a major rework of jQuery’s API like Angular just announced. jQuery’s design doesn’t need a lot of change, and we’re quite happy to just make drama-free tweaks to improve it. Two changes that we’ve already decided upon are Promise/A+ compatibility for our Deferred implementation and the return of requestAnimationFrame for animations in order to improve performance and battery life.
We actually had incorporated requestAnimationFrame support into jQuery 1.6.0 back in May 2011 but had to remove it in 1.6.1 due to compatibility issues with browsers and several popular jQuery plug-ins. We think we have those issues worked out now.
What are some of the larger goals for jQuery and the jQuery Foundation right now, both in terms of the technology itself and the ecosystem around it?
You’re right on target when you mention the ecosystem. Because of jQuery’s role, we end up needing to pass along a lot of feedback to ensure that the Web platform really serves the needs of developers. Those go beyond writing code and require us to coordinate efforts within the community. The jQuery Foundation is actively involved in standards organizations like the [World Wide Web Consortium] and the TC39 EcmaScript committee. We keep communication lines open with the major browser makers, especially for things like bug reports. We have also joined collaborations with other industry groups for JavaScript library internationalization and CSS standard frameworks.
jQuery is much more than just a cross-platform library at this point, with all its underlying hooks on the Web and extensions such as jQuery UI, jQuery Mobile, QUnit, Sizzle, etc. What’s your vision for where jQuery—and by extension, Web development—goes next?
Through the projects we host, the jQuery Foundation has first-hand experience with the challenges developers face on today’s Web platform. Problems like package and dependency management on the client side are still pretty hard to tackle, and new technologies like Web Components are going to make those issues even more critical to solve. We’d also like to play a part in standardizing the other tooling that everyone should use on a daily basis, such as linters and style checkers. Web developers deserve world-class tools.
