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!
jQuery Compat 3.0 seems like an odd name for a version that supports old browsers. jQuery Legacy 3.0 or something to that effect seems much more descriptive. Compact is just confusing, makes it seem like the minified version or something.
Compat, I’d imagine, means “compatible.”
Ha! I read this as compact instead of compat. Doh! :)
+1 for ‘jQuery Legacy’, you’re not the only one who’s going to read ‘compat’ as ‘compact’
>>Ha! I read this as compact instead of compat. Doh! :)
Same for me
Another +1 for “jQuery Legacy”, less confusing and rolls off the tongue better too ;-)
I agree that compat get read as compact, but jQuery Legacy implies that it is an old & unsupported version. I dislike any unnecessary shortening of words, and this is a prime example. The name should be “jQuery compatible”. What difference does 4 extra characters make?
“denoting software or hardware that has been superseded but is difficult to replace because of its wide use”
the lib is not legacy. the browsers that it is compatible with are.
+1 for “jQuery Legacy.” – it just has a nice ring to it. I take legacy to mean it provides support for legacy plugins that require the old lib.
Doh, i ALSO read that as ‘compact’ until I got to the comments section!
…and my vote is for “JQuery Legacy” too. ( I do like the sound of it , and it supports “legacy” browsers ) Makes sense to me.
Well done jQuery team! You continue to be a model for good open source project management at a massive scale.
+1 for compat. Lodash and others already use it. People will learn, along with ‘contrib’.
If I hadn’t read the comments I wouldn’t have noticed it’s compat and not compact. So +1 for Legacy
+1 for compat. Because I know how to read. And because my ego isn’t big enough to think I could change the name of software they most likely spent a good amount of time thinking about and -just- announced.
Definitely a bigger fan of “compat” over “legacy”. “Legacy”, as pointed out, makes it sound like it’s a legacy version of jQuery itself, and is somehow feature-crippled or out-of-date.
Petty arguments over naming aside, I’m a huge fan of this change. It makes the active development status of the compatibility version more visible, and helps eliminate confusion over which version to pick for new development. Kudos to the jQuery team.
I have no idea how feasible this is for this project, but would it be possible for a jQuery 3.0 Compat to monkey patch jQuery 3.0 core with backwards compatible approaches for browsers like oldIE, rather than being a separate library from the ground up? That way, everyone could start by including the same base jQuery 3.0, which would be ideal for simplicity and CDN cache hits. Then, if you needed compat support, you could include jQuery 3.0 Compat on the next line (with a conditional comment, like the standard approach for conditionally including 1.x or 2.x today, maybe?).
+1 for jQuery legacy sounds much better than compat
For those in the ‘compat’ naming argument – Android’s been using the ‘compat’ suffix for their appcompat libraries (http://developer.android.com/tools/support-library/features.html#v7-appcompat) that polyfill new operating system libraries onto older phones. So there is a standard for it outside of the jQuery world, though I’ve never seen it in the JavaScript world.
Lodash also uses it, but it’s the default so most people never notice. They also use a “modern” version, which in this case would be identical to plain old jQuery.
Since jQuery Compat will be the most used version, why not just call it jQuery and then rename the other jQuery Light or something else ? That way the developper think first using jQuery and then notice that there is a light version, and will check what is missing, and if he can use it instead.
Why not jQuerIE?
Just kidding.
Also learned from the comments that it is not jQuery-Compact, but jQuery-Compat.
+1 for jQuery-Legacy
As a developer, a little background on the naming:
In the linux/unix world the “legacy” and “compat” naming conventions have been well-established for years. Legacy is generally used to denote something which has been discontinued, and Compat is generally used to denote a specialized package that adds compatibility features.
So if jQuery were to call their “compat” release “legacy” instead, it would probably raise alarms for developers all over the world as they would assume a particular branch of development was being discontinued and support for it dropped.
On another note, I like what I hear about the changes, naming and otherwise. Keep up the good work!
seriously? new major version release with split versions, and every comment is about the naming?
i won;t waste any more bandwidth on that one. i for one, applaud the JQ team for transforming web development and making this major, welcome move.
I think keeping 2 API compatible versions with different levels of browser support is a good idea, but I’m not sure Legacy or Compat are great names. Odddly, I think calling the Compat version jQuery + Legacy or jQuery + Compat might be a better way to differentiate the two.
I don’t think there is really a clear, obvious choice though in what to call it, so it probably doesn’t matter.
Yes. Please please don’t call it Compat. It does not sound very descriptive and is easily confused with Compact, as in something built for lightweight or mobile browsers. Legacy is nice.
As a MooTools developer I strongly suggest to avoid compat, which causes lot of confusion, as people believe that it means compatible with other libraries (or just generally more compatible) and will use that over newer code, legacy would be a better naming IMHO, but
I also find it rather odd that 1.11.1 makes the transition to 3. It’s going to cause a lot of confusion before most people know what’s going on. However, I do appreciate the effort still put into the compat version. Cheers!
There’s no buts in my previous comment, I just accidentally hit some suggestions on my android keyboard and and hit the submit button while commuting to work, lol.
+1 for jQuery-Legacy
I read it comapct too.
Compat is read as “Compact”, voting for Legacy too!
+1 for “Legacy” as there is no moving forward without dealing with legacy.
I like the idea proposed by Dave Ward. Would like to hear feedback from the jQuery team on that. As a developer his approuch sounds much more maintainable und streamlined.
+1 “compat”. Not many developers use ‘compact’ to denote minified, we would use ‘min’ for that… so it’s fairly obvious.
“Legacy” sounds like an older version that is not maintained any more. It doesn’t convey a feeling on being kept up to date. -1 for “Legacy”
I can’t believe people can’t see how “compat” can easily be confused with “compact”.
It doesn’t have to be “legacy” (although it makes sense), but domething that will create less confusion would be nice.
If they’re saying Compat should be used in most cases, then that could be jQuery, and the other one jQuery Lite or whatever.
yes, you are all correct in that we should change the name to something that doesn’t make sense because you guys can’t read.
+1 for JQuery-update-your-browser-dude
Shadow Dom support for Polymer etc. ??
Compat is confusing, Legacy denotes old or outdated. Maybe we could go with these two versions:
jQuery 3.0
jQuery 3.0 Forward
Because the currently-named “Compat” edition is more widely recommended, it should be the default name. The one that is recommended only in specific instances (only supporting newer browsers) should have additional verbiage (in my suggestion, “Forward”), to be seen as something “special,” “beyond,” or “alternative” to the main jQuery 3.0 library.
Those interested will seek out what “Forward” means and those who aren’t paying attention will download the one that works with most browsers rather than needing to investigate what “Compat” means to them.
What a breathe of fresh air after the fiasco that is currently happening in the angular world :-)
Jup, read it like “compact”. If “Legacy” is not a good option, maybe just use the full word “compatible”. Super clear for everybody.
Why bother continuing to update the old IE version anyway? We shouldn’t be catering to people (or IT depts) that refuse to update, it’s just encouraging them to continue holding back innovation.
Will source in repo support commonjs, not AMD?
I would rather see a jQuery compatibility plugin that extends the main version instead of maintaining two versions. If you need support for an browser, make that extendable, especially if you can make it per browser.
Wow you guys, Compat is completely fine. I read it as “compat” the first time, you guys are programmers are you not? Your brain should recognize this easily. You should have used deductive reasoning and ruled out compact and re-read the word if you misread it the first time because compact makes no sense. Even if you do mess up reading it, who cares? Compact or compat, they could call it anything really, maybe dinosaur. JQuery Dinosaur: for older browsers.
The chain of comments suggesting legacy is unconstructive. It is PERFECTLY clear as compat. Compat is a cool fake word.
And as for legacy, it’s not really a bad choice either, legacy does give the meaning of “Deprecated” but really, that’s what it is. Old browsers are naturally deprecated, and anything that supports them are also deprecated.
I would also prefer something like this syntax:
That way every new website would be using the latest jquery 3, but a subset would also include the jquery 3 compatible library which overrides certain functionality with methods that are compatible with older browsers.
Syntax was hidden: Something like:
include jquery-3
include jquery-3-compat
I read it as jQuert Kompot. Which would be delicious.
Who cares about the name… you are all missing the important question. When is all of this happening? I don’t see any mention of timeframes.