jQuery 3.0: The Next Generations
It’s hard to believe it’s been nearly eight years since jQuery was released. Web development has changed a lot over the years, and jQuery has changed along with it. Through all of this time, the team has tried to walk the line between maintaining compatibility with code from the past versus supporting the best web development practices of the present.
One of those best practices is semantic versioning, or semver for short. In a practical sense, semver gives developers (and build tools) an idea of the risk involved in moving to a new version of software. Version numbers are in the form of MAJOR.MINOR.PATCH with each of the three components being an integer. In semver, if the MAJOR number changes it indicates there are breaking changes in the API and thus developers need to beware.
The concept of versioning gets a little more nuanced with jQuery, where browser compatibility can be just as important as API compatibility. In order to create a slimmer jQuery, the team started shipping two versions in 2013. The first version remained numbered in the 1.x line and, currently at 1.11.1, maintains compatibility with a maximal number of browsers. The second version, starting with 2.0.0 and now at 2.1.1, dropped support for browsers like IE8 or lower in order to streamline the code. Both the 1.x and 2.x versions of jQuery have the same public APIs, even though they differ somewhat in their internal implementations.
Our next releases will use a different nomenclature. As before, there will be two different released files. The successor to what is now version 1.11.1 will become jQuery Compat 3.0. The successor to jQuery 2.1.1 will be jQuery 3.0. There are two different packages on npm and Bower, but they share the same version to indicate they have the same API behavior.
We’ll also be re-aligning our policy for browser support starting with these releases. The main jQuery package remains small and tight by supporting the evergreen browsers (the current and previous versions of a specific browser) that are common at the time of its release. We may support additional browsers in this package based on market share. The jQuery Compat package offers much wider browser support, but at the expense of a larger file size and potentially lower performance.
Despite the big version number jump, we don’t anticipate a lot of migration issues for most current jQuery code. We’re just being good semver citizens with this version bump. Changes such as removing deprecated methods will be detected by a new version of the jQuery Migrate plugin to make them easy to find and fix. We’ll have more details on the changes in future blog posts.
So, here’s the TL;DR for version 3.0 of the jQuery API:
- If you need support for the widest variety of browsers including IE8, Opera 12, Safari 5, and the like, use the jQuery-Compat 3.0.0 package. We recommend this version for most web sites, since it provides the best compatibility for all website visitors.
- If your web site is built only for evergreen leading-edge browsers, or is an HTML-based app contained in a webview (for example PhoneGap or Cordova) where you know which browser engines are in use, go for the jQuery 3.0.0 package.
- Until we announce otherwise, both packages will contain the same public APIs in correspondingly-numbered major and minor versions. This should make it easy for developers to switch between the two and be maximally compatible with third-party jQuery plugins.
With each future release, we’ll be making both packages available on npm and bower. Both packages will also be available as single-file builds on the jQuery CDN. Using them from there is as simple as including either jquery-compat-3.0.0.js or jquery-3.0.0.js depending on your needs. We’ve talked with the folks who run Google’s CDN and they will also be supporting both packages.
As we make further progress on version 3.0, we will update everyone with the details about code changes, supported browsers, and the like. Stay tuned!
Looking forward to these changes and what’s to come for the future of jQuery.
Eagerly waiting fro the release
Expecting something more interesting and exciting new stuff. At the same time it would be better if jquery compat 3.0.0 be more light or at least useful to use in big projects.
Sooper Cool! I was waiting for Apache Cordova specific jQuery! Can’t wait to try it!
If the modern and ‘compat’ 3.x.x versions of jQuery are routinely released simultaneously and maintain API consistency between themselves, then developers can implement server-side browser detection and serve up the appropriate library on the fly. As long as intermediate caching by proxies is avoided, browsers could still cache the script for re-use so that extra trips to the host are avoided.
TBH jQuery 3 has been in the wild for a few years now, and is called vanilla js.
How ’bout builds where people select what they need from jQuery and no more?
Absolutely +1, for jquery-legacy.
Dave Ward: It would be impossible to have jQuery Compat just use jQuery and monkey patch the methods. Changes between those two versions are enormous, some modules are changed completely.
We could (maybe, don’t hold me to it) do such a thing in the future for Android 2.3 but IE<9 are just too broken.
can not wait to use it
It’s will be better if it is more lighter then before and can handle every project.
caring about when this will happen, too!
I’m waiting.
I guess I really do need more information before drawing any conclusions. but it felt like 2.x barely got a foothold and now 3.x is on the horizon? Doesn’t feel right. And having a “Compat” variant of jQuery doesn’t really seem to simplify things in my mind… what will be the difference between jQuery Compat 3.0 and jQuery 1.1.1, for example? Some drastic internal changes, but the same API on the surface?
How about just end-of-lifing it?
What about ECMAScript 6 features, any of part of this?
+1 for SemVer.
So why not add a jquery-3.js or jquery-3.x.js on the CDN that will always return the lastest minor version?
@yguedidi
> So why not add a jquery-3.js or jquery-3.x.js on the CDN that will always return the lastest minor version?
Because referencing on CDNs files that change is a bad practice. It basically prevents caching; besides, every patch version can (it shouldn’t but it can) introduce breakages so you should always update jQuery yourself, not automatically on a living site.
@The Digital Orchard
> but it felt like 2.x barely got a foothold and now 3.x is on the horizon?
Why does it matter? It’s just a version number and we don’t want to break people who include “^1.11.0” on npm, which would catch 1.12.0 automatically.
> what will be the difference between jQuery Compat 3.0 and jQuery 1.1.1, for example? Some drastic internal changes, but the same API on the surface
jQuery Compat 3.0.0 will be a continuation of jQuery 1.11.1. This will be what would otherwise be named jQuery 1.12.0.
> Some drastic internal changes, but the same API on the surface?
APIs doesn’t change a lot but there will be breaking changes.
Literally can’t wait. When is it due for release?
Could the names be changed to something like:
JQueryWeb
and
JQueryEmbedded
In this way, there is no plain “JQuery” which could be confused with older versions. Also, anyone using JQuery on a public web site should be supporting more than just the most recent versions of browsers. The Web edition would support all browsers in common use (eg. not IE6, etc.).
nice
I would like to include this new version to my next project… I love jquery
cool
Will you guys update jQuery’s Deferred and Promises implementation to match the ECMAScript 6 Promises spec? It would be nice to have all our Promises promise the same promise.
GITHUB SEEMS PROMISING?
@Robert
> Will you guys update jQuery’s Deferred and Promises implementation to match the ECMAScript 6 Promises spec?
Yes, we already have a patch; it should land soon.
Nice and lighter than old version
Exciting stuff – when is the expected roll out?
Good ECMAScript 6 Promises spec? It would be nice to have all our Promises promise the same promise.
Awesome post +1, From me
alert(“dfioudsiou”);