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