The official jQuery project blog announces releases and changes for jQuery, including the 2.0, 3.0 and 4.0 versions.
HN links it for release announcements such as the jQuery 4.0 beta, and commenters discuss its RSS feed and hotlinking jQuery from CDNs.
There is a lot of misconceptions here.
There are two parallel tracks of JQuery maintained, with _identical functionality_, one which supports IE8 and less, one which doesn't.
JQuery team is supporting both. If they don't behave identically, that's a bug. If you don't need IE8 or less support, you can use the smaller higher-performance JQuery that doesn't support IE8. If you do need IE8 or before you use the other variant.
Your code remains identical either way.
JQuery still supports IE8 and less, and has announced no plans to stop.
A lot of people are confused about this, and it's made more confusing by their mistakes about version labelling.
At present, these two variants are JQuery 1.x (IE8 no problem), and JQuery 2.x (IE9 and above). There are identical parallel versions of each. 1.11.0 and 2.1.1 have identical functionality. Yes, this is super confusing, so going forward in the future, they will call the old-browser-compat variant "JQuery compat", and the no-old-browsers variant "JQuery", and version numbers will be sync'd.
http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-generations/
At present, the JQuery team is still committed to maintaining identical functionality in an old-browser-compat variant, and a newer no-old-browser variant, sync'd, for the indefinite future. And in fact they recommend the Compat version "for most web sites, since it provides the best compatibility for all website visitors."
They could at some point in the future decide to…
I thought that was true, but checked a few months back and the advice seemed a bit more equivocal than that:
> 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.
from http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-generations/
I personally currently need to support IE9 which I wouldn't class as an "evergreen leading-edge browser". I was hoping for a more in depth compatibility chart that named specific versions.
When I try to subscribe to http://blog.jquery.com/ or http://blog.jquery.com/feed/ in Thunderbird, I receive an error stating that "the Feed URL is not a valid feed". Also, I couldn't find a feed URL at the jQuery Blog that validates at the W3C Feed Validation Service.
I've seen multiple commenters at the jQuery Blog state that the feed is broken for them too. The following search results bring up some of these comments:
https://google.com/search?q=site:blog.jquery.com+broken+feed+OR+rss
I recall that this issue was acknowledged at some point by one of the contributors at the jQuery Blog. I don't recall who acknowledged it though, but I seem to recall that they stated it would be fixed eventually, which is why I didn't look for a solution until today.
This is a complicated set of trade offs and I've argued on both sides of the fence so I can't pretend to imply the decision is at all clear cut. But let me respond to a couple details here.
First, the 'jQuery bloat' you're worried about looked like it was going to happen without Chrome native support: http://blog.jquery.com/2015/02/24/getting-on-point/. One of our goals in revisiting the decision was to avoid frameworks like jQuery having to include such polyfills to Chrome users.
The other thing is that we shouldn't assume Chrome doing Pointer Events means we won't also improve Touch Events. That's a complicated decision influenced in large part by participation by other browser vendors in the standards process around Touch Events.
jQuery first came-out long before browsers had querySelector: it used a 100% JS reimplementation of a CSS selector parser and evaluator, which was eventually spun-off into its own library: Sizzle.js: https://github.com/jquery/sizzle - Surprisingly, jQuery didn't fully remove Sizzle until 2019 ( https://blog.jquery.com/2019/04/10/jquery-3-4-0-released/ ) - if that seems surprisingly recent, don't forget that querySelector wasn't added to the DOM API until 2013 - with only IE11 supporting it: some places were still using even IE6 well past then, so it makes sense for jQuery to support it for so long.
So using newer CSS selector features, like attribute value selectors, will work fine in post-Sizzle jQuery versions.
jasonkester: in jQuery 1.4.3 a lot of work was done to make jQuery more modular. So you could take the peices of the library that you want and leave out the rest (i.e. effects).
This isn't the recommendation of the jQuery Team but if you feel the library is getting too bloated you now have the option to cherry pick only the options of jQuery you'd like to use.
Read the blog post here http://blog.jquery.com/2010/10/16/jquery-143-released/
Also we discussed it on the jQuery 1.4.3 episode of the jQuery Podcast http://podcast.jquery.com/2010/10/29/episode-38-jquery-1-4-3/