14 ms·

JQuery 2.0 Released

472 points by Encosia 14y ago

ConceitedCode 14y ago
The "How 2.0 Changed" section only lists dropping support for IE 6/7/8 and reduced file size (from dropping the IE support?). Are there any other note worthy/major changes or just minor bug fixes and the like?
- apendleton 14y ago
  No, the idea has pretty much always been that jQuery 1.9 and 2.0 would be feature-comparable, just with different sizes and supported browsers. See http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/ http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-an...
  - as_if 14y ago
    They hate IE SO much, they even made the drop a new major release. This is what I call commitment.
    - dmethvin 14y ago
      Since people see jQuery as a solution for cross-browser issues, dropping some browser support is the biggest change imaginable.
      - jjs 14y ago
        Deprecating old-IE is the solution for cross-browser issues.
    - pbhjpbhj 14y ago
      So Microsoft hate WinXP so much they made dropping support in MSIE a new major release?
    - ward 14y ago
      But isn't that exactly the thing about major releases? That compatibility may be broken. See also http://semver.org/ http://semver.org/
- deleted 14y ago
  [deleted]
gesman 14y ago
No more support for IE 6/7/8. Yay!
- marcosdumay 14y ago
  Gone, with half of the compressed file size. Lots of people will serve the two versions.
apendleton 14y ago
The addition of the ability to just use querySelectorAll as the selector engine and not ship Sizzle is a pretty big deal, and not something I remember being included in earlier discussions about jQuery 2. qSA still includes a pretty broad set of selectors, and the ability to get the build down to 10k minified and gzipped puts it squarely in Zepto's territory, size-wise, eliminating the need for that particular wheel reinvention.
- dmethvin 14y ago
  If you use really simple class and id selectors, the qSA-based selector engine may be fine. However, I think a lot of devs would be surprised about how much Sizzle is doing for them.
  - apendleton 14y ago
    qSA does a lot more than class and id selectors; those have been trivial since long before qSA came along. You can also do selection on element attributes, parent-child selections (include strict child selection with ">"), and a few other higher-order selector combinations. Still, I don't mean to slight Sizzle, and certainly won't stop using it. It's just nice to see jQuery compete with Zepto, since apparently there's a demand for a build that small, and jQuery is better-tested and less brittle.
    - dmethvin 14y ago
      I didn't mean to say that's _all_ you can do, but people often expect more than qSA can deliver, especially if they've been using jQuery/Sizzle for a while. Sizzle also works around bugs in qSA implementations when they exist. qSA's design shortcomings have been well documented, John Resig did a blog long ago about them [1]. The list of what you lose if you remove Sizzle is in the native selector file [2]. [1] http://ejohn.org/blog/thoughts-on-queryselectorall/ http://ejohn.org/blog/thoughts-on-queryselectorall/ [2] https://github.com/jquery/jquery/blob/master/src/selector-native.js#L4 https://github.com/jquery/jquery/blob/master/src/selector-na...
- KaoruAoiShiho 14y ago
igravious 14y ago
Serious question. Please hit me with a clue stick. Regarding 1.9, how can "old-IE compatibility often causes problems of its own" and "simplest way to support older browsers is to use jQuery 1.x on your site, since it works for all browsers." both be true at one and the same time?
- epmatsw 14y ago
  Keeping old-IE compatibility prevents some optimizations and makes the code have to do extra checks, but using one file that supports it is simpler than using two files?
  - igravious 14y ago
    Ok, so the problems it causes are pain points for the jQuery devs and not for website devs? Also, the underlying code is more complex and lacks optimizations? Until old drops off the radar completely we'll have to use 1.9 solely or do a conditional check and serve the suitable version - serving 1.9 seems simpler ^^, call me lazy, many have,
    - apendleton 14y ago
      Depends what you're doing. If you're building a mobile app (particularly one meant to be distributed via PhoneGap), or a Chrome extension, maybe you don't care about IE support.
    - kaeawc 14y ago
      Its also a pain for every website serving jQuery because of increased data for every single page load. Cutting out the support for old IE should also help with performance.
    - dmethvin 14y ago
      Not dumb at all. Keep using 1.x for everything until IE 6/7/8 drop off your radar.
- themgt 14y ago
felixthehat 14y ago
I wish Microsoft would shoehorn at least IE9 into XP, maybe like Chrome Frame. It's crazy how many people are still stuck with XP/IE8 which is a massive web dev headache.
- yuhong 14y ago
  My favorite is how it fails to support decade old features like DOM Level 2 and XHTML.
  - angersock 14y ago
    but nobody gives a shit about xhtml
- ancarda 14y ago
  I'm annoyed XP doesn't have IE 9 or DirectX 10+, but I guess that's Microsoft's way of getting people to upgrade to newer versions of Windows. Based on current stats, I'd say IE 8 hasn't got long till you can ignore it but it really depends on how much market share you care about. Do people STILL target IE 6? IE 8 is on ~10%[1] and at the current rate it's dropping at should be at 5% by October - Just in time for IE 11? As for blaming XP, I'm not sure you can completely. IE 8 is the default browser of Windows 7 and XP has more than double the market share of IE 6/7/8 combined. Most IE users seem to be schools and companies that haven't upgraded. Although IE 6 will definitely be gone by April 2014, we could very well be stuck with IE 8 for a very long time. For the record, IE 6 and 7 should be ignored completely. Combined they have a market share of less than 1%. For a rule of thumb, I commonly drop support once a browser crosses 5%. Might seem high but usually once it's at that level, it's only going to keep falling. Something to look forward to, my estimates[2] put Firefox 3.6, Safari 5/5.1 and IE 6/7/9 to all be gone by the start of 2014. Of course, linear estimations should always be taken with a grain of salt. [1] http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-201203-201303 http://gs.statcounter.com/#browser_version_partially_combine... [2] http://cl.ly/image/2d1G3Y1Q2m3k http://cl.ly/image/2d1G3Y1Q2m3k
  - yuhong 14y ago
JoeCortopassi 14y ago
I think what a lot of people are upset about here, is jQuery entered the web development scene as "the library that solved cross-browser compatibility issues". Now while IE 6 is an obvious one to drop, IE 7 is a little tougher, and IE 8 is down right impossible to drop at this time. I understand that jQuery wants to promote a modern framework, but people didn't adopt it for it's fancy features. They adopted it because those fancy features worked the same in every major browser . The stop gap solution of 1.9 as being parallel to 2.0 but with compatibility, is understandable, but will probably promote distrust in developers who just need a stable cross-platform solution. I think the immediate concern with 1.9, is how long it will continue in parallel with 2.x before being dropped
- spicyj 14y ago
  I don't think that's true. There were a handful of competing libraries (Prototype.js, Mootools, etc) and jQuery won out because people seemed to prefer its API.
  - chollida1 14y ago
    Only one data point here, but we originally chose jquery for browser compatibility support and I know we're not alone:) The rest of jquery was just gravy.
  - speg 14y ago
    I can only speak for myself, but IMO jQuery won because of their docs. I seem to remember having a hell of a time trying to get MooTools to work in the summer of '06, and finding docs to be of no help.
    - nbouscal 14y ago
      People underestimate just how important jQuery's documentation has been to its success. Even jQuery themselves seem to underestimate it, because the documentation for jQuery UI and jQuery Mobile really are not as good as the core docs (though still far better than the average). I probably would not have started using jQuery for my projects nearly as soon or as often had it not been for the excellent documentation.
oneeyedpigeon 14y ago
I cannot believe IE8 is now considered 'old'. It is the second most used browser+version on our site, and has about 80% as much usage as the leader, IE9. Can't see IE8 support being droppable for many years yet.
- ahoge 14y ago
  Even IE9 is pretty old. It's over 2 years old by now. IE8 is over 4 years old. IE11 will be released soon. How many versions of IE do you intend to support?
  - igravious 14y ago
    As many versions as used by the audience that they serve I suppose; how is the choice up to him?
    - jhack 14y ago
      At the speed web development is moving, I don't see much sense in coddling browsers that are more than 2-3 years old.
      - monkeynotes 14y ago
        That all changes if your client uses browsers that are more then 2-3 years old, and you are financially dependent on your client being served properly.
        nbouscal 14y ago
        You can tell your client to use a new browser. It's all in how you phrase it. Everyone in this thread seems so damn scared of their clients. You have a way to improve their experience of using the internet and using your product. That's an opportunity to embrace, not something to run away from.
      - dave5104 14y ago
leeoniya 14y ago
it would be nice to see a 2.0 vs 1.9 bench on FF/Chrome/IE9+, much more interested in that than a non-noticeable 11k size reduction for the end user (maybe only slightly noticeable on very slow mobile).
- deleted 14y ago
  [deleted]
- monkeynotes 14y ago
  Yeah, I was also scratching my head as to the 'performance' gains. Even if jQuery 2.0 has computational benchmark gains they also are likely insignificant in proper context.
  - byroot 14y ago
    I found this one: http://jsperf.com/jquery-1-7-2-vs-jquery-1-8/29 http://jsperf.com/jquery-1-7-2-vs-jquery-1-8/29 2.0 is slightly faster on every measures.
DivisibleByZero 14y ago
I was just debating the merits of going with one of the lightweight jquery substitutions for a phonegap app. This couldn't come at a better time. Dropping the cruft and supporting 1.9 is such a wonderful way to go. Congratulations on a great release jquery team.
dave1010uk 14y ago
Now we can say "but even the latest version jQuery doesn't support IE 8!" (even though the supported 1.9 branch still does).
DigitalSea 14y ago
This is a welcome change. Considering the market share of IE 6, 7 and 8 is pretty minuscule and Google dropping support for IE8 back in November 2012 should be cause enough to drop it from jQuery too. It's great to hear they'll be supporting the older 1.9 branch for users who need to support older versions of IE as not everyone has the luxury of being able to ditch older versions of IE like that. There's no cause for concern here, the jQuery team covered their bases well and lets face it, there aren't many open source projects out there that drop support for older versions of something like a browser and then commit to continue to support an older branch for a lengthy amount of time.
- hobbes78 14y ago
  Is 31.37% pretty minuscule? I don't think so... Source: http://www.netmarketshare.com/ http://www.netmarketshare.com/
  - colmvp 14y ago
    It is if your customer base are comprised of very few IE users.
  - nbouscal 14y ago
    As best I can see on the site you linked, IE8 is 23.23%. That also disagrees significantly with this source: http://caniuse.com/usage_table.php http://caniuse.com/usage_table.php where IE8 is 8.89%
  - DigitalSea 14y ago
    You combined all aforementioned versions of IE together to yield that result: http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0 http://www.netmarketshare.com/browser-market-share.aspx?qpri... — even combined the market share is still in my opinion minuscule. The only browser with a substantial market share is IE 8 which according to the site has a market share of 23%, it's not even worth adding in those other percentages on-top to try and make it seem as though a lot of people still use those browsers. 31% is not justification enough to maintain legacy code in a library that has become a little bloated over the years because of the backwards compatibility with older browsers. If you want to support that 31%, use the 1.9 branch it's better than the alternative being no support whatsoever. Edit: Why all of the down-votes, is my response offensive?
sturmeh 14y ago
Until Windows XP is banished from corporate machines worldwide, I don't think we can drop IE8 support. (You can't install 9/10 on Windows XP.) I'm glad they decided to continue support for 1.x for now.
- deleted 14y ago
  [deleted]
da_n 14y ago
Well done jQuery team, nice work. Wether I can use it production before April 8, 2014 is going to be debatable. I dearly would love to delete the XP VM running IE8 however.
davis_m 14y ago
I don't understand why the smaller file size is such a big deal. The file is going to be cached, and with the use of CDNs, is more than likely already cached before the client ever visits my website. So if the Query team is still going to support these browsers in 1.9, why even make the 2.0 version?
- Perceptes 14y ago
  File size is not only a concern in terms of download time. There's also parse time, and the amount of extra memory used to consider.
- ethermal 14y ago
  it isn't, it's all political.
rurounijones 14y ago
I am not too troubled by the drop of support of IE 6/7/8. As long as they continue to support IE8 in 1.9 until Windows XP EOL next year I don't really see a problem. Asking jQuery to support those browsers longer than Microsoft itself is willing do seems a bit harsh.
- reustle 14y ago
  > Asking jQuery to support those browsers longer than Microsoft itself is willing do seems a bit harsh. While I agree with jQuery's decision here, this isn't really fair right? Windows XP and most old stand-alone software they have installed will continue to work after MS drops support. When we're talking about the web, a reasonable effort should be made to support those legacy users. Of course, you can only do so much, but according to the general consensus in these comments, that's around 10% of visitors. Whether or not dropping them is worth saving the 12% in code size, is a different question.
verisimilitude 14y ago
Am I the only one who can not use Closure Compiler with jquery 2.0.0? ( http://closure-compiler.appspot.com/ http://closure-compiler.appspot.com/ )
- Skalman 14y ago
  Yeah, it gives me 29 errors. You might as well use UglifyJS, the same compressor that jQuery uses. https://github.com/mishoo/UglifyJS2/ https://github.com/mishoo/UglifyJS2/ You can try it out on http://skalman.github.io/UglifyJS-online/ http://skalman.github.io/UglifyJS-online/. It's just a light-weight wrapper.
Zangrief 14y ago
The point of separation is simpler jQuery development and reduced file-size for the >= 2.x versions. You will serve two files. You serve 1.9.x to IE 6/7/8 users, and 2.x to everyone else. You save bandwidth. You save money. Features will be the same. It's OSS folks. It's not like it's ran by a closed-source team at Google who may suddenly pull the plug if it deems the project unpopular. My guess is folks who work in enterprise (where older IE still plagues) will be the big maintainers of 1.9.x.
laurent123456 14y ago
> If you want, you can serve 2.0 to newer browsers and 1.9 to older ones using our conditional comment trick I'm really surprised they would suggest doing this. The two APIs are quite different since many functions from the 1.x branch have been removed in the 2.x or sometime behave differently (for instance `$("some <strong>bold</strong> text")` will be parsed as HTML in 1.x but considered a CSS selector in 2.x). Basically, I really wonder what could be the benefit of using this kind of conditional comment trick.
- Skalman 14y ago
  It'll be parsed as HTML in 1.8, but it's a CSS selector in 1.9.
- curiousdannii 14y ago
  If you can find a case where 1.9 and 2.0 have different APIs, file it as a bug!
darkandbrooding 14y ago
I've read through the 100+ comments that preceded me, and I must be missing something stupidly obvious. Thanks in advance to anyone who can enlighten me. Can't you just host your own copy of JQuery? If your web app needs version x.y.whatever, is there some reason why you can't just host your own copy of the library on the same servers the provide the rest of your web content? I understand the convenience of using some CDN's copy of JQuery, but I'm unsure why it's anything other than a convenience. Maybe it's about money: "It'll cost us an extra $X per month in bandwidth fees to host our own version of JQuery." Maybe it's about user experience: "By hosting JQuery on our own site we add 100ms to page load times." To the people who seem most unhappy about the version bump, can you describe how hosting your own version of JQuery would complicate your lives? Just so there is no ambiguity, I'm asking from a point of ignorance, not snark. I would genuinely like to read the answers.
- crazygringo 14y ago
  There is zero problem with hosting your own copy. Lots of people do. The main advantage to using a CDN is that a single copy can be cached across multiple websites, meaning that the first time someone visits your site, there's a good chance your version of jQuery already sits on their computer. Plus, the Google CDN will often serve content faster than your own site. And, since jQuery is now so "integral" to websites, it almost seems silly to have to maintain a copy of it yourself. But the main downside to using a CDN is that, CDN's have gone down before, and that means your site will stop working. Obviously, it doesn't happen often, but it happened once to a widely used site of a friend of mine, and he swore, never again will he reference jQuery on a CDN. I personally prefer to host myself too. (But not out of bandwidth savings, that just winds up being trivial.)
  - Dave9k 14y ago
    You can use a CDN and fallback to local if it goes down. http://stackoverflow.com/questions/5257923/how-to-load-local-script-files-as-fallback-in-cases-where-cdn-are-blocked-unavai http://stackoverflow.com/questions/5257923/how-to-load-local...
colemorrison 14y ago
So I find that the majority of people are missing a very LARGE improvement that I value far beyond any of the stated benefits by the jQuery team: -One of the most popular libraries is dropping support for IE 6,7, and 8. Thus, yet another cornerstone of the web is going to push users forward and increase the chance that those miserable browsers will disappear. The most disturbing thing I find is that there are developers that are DEFENDING existence for those older browsers. Are you masochists? Do you enjoy the headaches of fucking around with those?? "Oh but so many clients are still using them, and it writes off potential users!" How can we ever expect for them to upgrade their damn browser unless the builders the web (developers, not just browsers) quit allowing them to rot in complacency???? Of course, there is a thing as going "too leading edge" and expecting "too much" from the user...but when the cornerstones (libs, browsers, etc) start pushing them forward - then we should embrace this change. Coding for the multi-browser/platform/device/version web is hard enough.
- theycallmemorty 14y ago
  The main problem I see is that IE9 does not work on windows XP. How long will we continue to see Windows XP machines in the wild?
  - acdha 14y ago
    Microsoft will not be doing it past 2014. I wouldn't care more about their OS than they do, particularly given the extreme security risks.
- democracy 14y ago
  Not defending, but if you cannot degrade your functionality to make it work in old IE then you doing something wrong. Please, give me a use-case that is not too niche but absolutely requires the latest generation of browsers.
- ethermal 14y ago
  I don't get this line of thinking. Do you know there are programs written on system/36 machines from the early eighties still in production today on ibm iSeries machines? And even older software/systems in place that are older then that. Business requirements don't change hourly/weekly/monthly. If the business requirement that existed at that point in time, that the software solution put in place at that time met those requirements why would a business be compelled to change if those requirements have not changed and the solution met those needs? I've been a developer a really long time, 25+ years professionally. Businesses demand stability, this absolutely absurd idea that software that is only a few years old must be thrown out and some new flashy unproven shit put in its place is mind boggling. The last job I put a bid on, one of the requirements was that the software in initial form be supported for a minimum of 10 years. And in my experience that is a short life span.
silasb 14y ago
Anyone know if the jQuery 2.0 fixes/enhancements will also be applied to the 1.x branch, particular the 1.9 series. Based on what I've read they are running in parallel with the IE stuff removed. I can't seem to find anything that mentions that 1.x stuff has been updated and released.
jrochkind1 14y ago
One thing that confuses me: If the JQuery team is committed to keep supporting 1.9/1.x, entirely API-compatible with 2.0 -- what is the benefit to JQuery of the 1.x/2.x fork? You get a cleaner easier to maintain codebase in 2.x -- but you've got to keep maintaining 1.x anyway. If there was a feature you didn't want to add to 1.x because it was too hard -- you still can't add it to 2.x and not 1.x, because you committed to supporting 1.x as API-compatible, no? Is the idea that 2.x will provide better performance on capable browsers than 1.x? So, yeah, the development burden is no less, but the results are better. I guess I understand why people are doubting whether they will really follow through -- because if they do follow through, it makes it somewhat unclear what the benefit of the 2.x refactor was in the first place.
EGreg 14y ago
It would be nice if jQuery made builds for every browser, so savvier developers who can write server-side code can actually spit out only the relevant jQuery to the relevant browser. I mean, it's not like caching files at the ISP level is the limiting factor here, so each browser can cache its own file.
drorweiss 14y ago
Will jquery still work with jsdom on node.js? the 2.0 or 1.9 jquery?

472 points by Encosia 14y ago

The "How 2.0 Changed" section only lists dropping support for IE 6/7/8 and reduced file size (from dropping the IE support?). Are there any other note worthy/major changes or just minor bug fixes and the like?

apendleton 14y ago
No, the idea has pretty much always been that jQuery 1.9 and 2.0 would be feature-comparable, just with different sizes and supported browsers. See http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/ http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-an...
- as_if 14y ago
  They hate IE SO much, they even made the drop a new major release. This is what I call commitment.
  - dmethvin 14y ago
    Since people see jQuery as a solution for cross-browser issues, dropping some browser support is the biggest change imaginable.
    - jjs 14y ago
      Deprecating old-IE is the solution for cross-browser issues.
  - pbhjpbhj 14y ago
    So Microsoft hate WinXP so much they made dropping support in MSIE a new major release?
  - ward 14y ago
    But isn't that exactly the thing about major releases? That compatibility may be broken. See also http://semver.org/ http://semver.org/
deleted 14y ago
[deleted]

gesman 14y ago

No more support for IE 6/7/8. Yay!

marcosdumay 14y ago
Gone, with half of the compressed file size. Lots of people will serve the two versions.

apendleton 14y ago

The addition of the ability to just use querySelectorAll as the selector engine and not ship Sizzle is a pretty big deal, and not something I remember being included in earlier discussions about jQuery 2. qSA still includes a pretty broad set of selectors, and the ability to get the build down to 10k minified and gzipped puts it squarely in Zepto's territory, size-wise, eliminating the need for that particular wheel reinvention.

dmethvin 14y ago
If you use really simple class and id selectors, the qSA-based selector engine may be fine. However, I think a lot of devs would be surprised about how much Sizzle is doing for them.
- apendleton 14y ago
  qSA does a lot more than class and id selectors; those have been trivial since long before qSA came along. You can also do selection on element attributes, parent-child selections (include strict child selection with ">"), and a few other higher-order selector combinations. Still, I don't mean to slight Sizzle, and certainly won't stop using it. It's just nice to see jQuery compete with Zepto, since apparently there's a demand for a build that small, and jQuery is better-tested and less brittle.
  - dmethvin 14y ago
    I didn't mean to say that's _all_ you can do, but people often expect more than qSA can deliver, especially if they've been using jQuery/Sizzle for a while. Sizzle also works around bugs in qSA implementations when they exist. qSA's design shortcomings have been well documented, John Resig did a blog long ago about them [1]. The list of what you lose if you remove Sizzle is in the native selector file [2]. [1] http://ejohn.org/blog/thoughts-on-queryselectorall/ http://ejohn.org/blog/thoughts-on-queryselectorall/ [2] https://github.com/jquery/jquery/blob/master/src/selector-native.js#L4 https://github.com/jquery/jquery/blob/master/src/selector-na...
KaoruAoiShiho 14y ago

igravious 14y ago

Serious question. Please hit me with a clue stick. Regarding 1.9, how can "old-IE compatibility often causes problems of its own" and "simplest way to support older browsers is to use jQuery 1.x on your site, since it works for all browsers." both be true at one and the same time?

epmatsw 14y ago
Keeping old-IE compatibility prevents some optimizations and makes the code have to do extra checks, but using one file that supports it is simpler than using two files?
- igravious 14y ago
  Ok, so the problems it causes are pain points for the jQuery devs and not for website devs? Also, the underlying code is more complex and lacks optimizations? Until old drops off the radar completely we'll have to use 1.9 solely or do a conditional check and serve the suitable version - serving 1.9 seems simpler ^^, call me lazy, many have,
  - apendleton 14y ago
    Depends what you're doing. If you're building a mobile app (particularly one meant to be distributed via PhoneGap), or a Chrome extension, maybe you don't care about IE support.
  - kaeawc 14y ago
    Its also a pain for every website serving jQuery because of increased data for every single page load. Cutting out the support for old IE should also help with performance.
  - dmethvin 14y ago
    Not dumb at all. Keep using 1.x for everything until IE 6/7/8 drop off your radar.
themgt 14y ago

felixthehat 14y ago

I wish Microsoft would shoehorn at least IE9 into XP, maybe like Chrome Frame. It's crazy how many people are still stuck with XP/IE8 which is a massive web dev headache.

yuhong 14y ago
My favorite is how it fails to support decade old features like DOM Level 2 and XHTML.
- angersock 14y ago
  but nobody gives a shit about xhtml
ancarda 14y ago
I'm annoyed XP doesn't have IE 9 or DirectX 10+, but I guess that's Microsoft's way of getting people to upgrade to newer versions of Windows. Based on current stats, I'd say IE 8 hasn't got long till you can ignore it but it really depends on how much market share you care about. Do people STILL target IE 6? IE 8 is on ~10%[1] and at the current rate it's dropping at should be at 5% by October - Just in time for IE 11? As for blaming XP, I'm not sure you can completely. IE 8 is the default browser of Windows 7 and XP has more than double the market share of IE 6/7/8 combined. Most IE users seem to be schools and companies that haven't upgraded. Although IE 6 will definitely be gone by April 2014, we could very well be stuck with IE 8 for a very long time. For the record, IE 6 and 7 should be ignored completely. Combined they have a market share of less than 1%. For a rule of thumb, I commonly drop support once a browser crosses 5%. Might seem high but usually once it's at that level, it's only going to keep falling. Something to look forward to, my estimates[2] put Firefox 3.6, Safari 5/5.1 and IE 6/7/9 to all be gone by the start of 2014. Of course, linear estimations should always be taken with a grain of salt. [1] http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-201203-201303 http://gs.statcounter.com/#browser_version_partially_combine... [2] http://cl.ly/image/2d1G3Y1Q2m3k http://cl.ly/image/2d1G3Y1Q2m3k
- yuhong 14y ago

JoeCortopassi 14y ago

I think what a lot of people are upset about here, is jQuery entered the web development scene as "the library that solved cross-browser compatibility issues". Now while IE 6 is an obvious one to drop, IE 7 is a little tougher, and IE 8 is down right impossible to drop at this time. I understand that jQuery wants to promote a modern framework, but people didn't adopt it for it's fancy features. They adopted it because those fancy features worked the same in every major browser . The stop gap solution of 1.9 as being parallel to 2.0 but with compatibility, is understandable, but will probably promote distrust in developers who just need a stable cross-platform solution. I think the immediate concern with 1.9, is how long it will continue in parallel with 2.x before being dropped

spicyj 14y ago
I don't think that's true. There were a handful of competing libraries (Prototype.js, Mootools, etc) and jQuery won out because people seemed to prefer its API.
- chollida1 14y ago
  Only one data point here, but we originally chose jquery for browser compatibility support and I know we're not alone:) The rest of jquery was just gravy.
- speg 14y ago
  I can only speak for myself, but IMO jQuery won because of their docs. I seem to remember having a hell of a time trying to get MooTools to work in the summer of '06, and finding docs to be of no help.
  - nbouscal 14y ago
    People underestimate just how important jQuery's documentation has been to its success. Even jQuery themselves seem to underestimate it, because the documentation for jQuery UI and jQuery Mobile really are not as good as the core docs (though still far better than the average). I probably would not have started using jQuery for my projects nearly as soon or as often had it not been for the excellent documentation.

oneeyedpigeon 14y ago

I cannot believe IE8 is now considered 'old'. It is the second most used browser+version on our site, and has about 80% as much usage as the leader, IE9. Can't see IE8 support being droppable for many years yet.

ahoge 14y ago
Even IE9 is pretty old. It's over 2 years old by now. IE8 is over 4 years old. IE11 will be released soon. How many versions of IE do you intend to support?
- igravious 14y ago
  As many versions as used by the audience that they serve I suppose; how is the choice up to him?
  - jhack 14y ago
    At the speed web development is moving, I don't see much sense in coddling browsers that are more than 2-3 years old.
    - monkeynotes 14y ago
      That all changes if your client uses browsers that are more then 2-3 years old, and you are financially dependent on your client being served properly.
      - nbouscal 14y ago
        You can tell your client to use a new browser. It's all in how you phrase it. Everyone in this thread seems so damn scared of their clients. You have a way to improve their experience of using the internet and using your product. That's an opportunity to embrace, not something to run away from.
    - dave5104 14y ago

leeoniya 14y ago

it would be nice to see a 2.0 vs 1.9 bench on FF/Chrome/IE9+, much more interested in that than a non-noticeable 11k size reduction for the end user (maybe only slightly noticeable on very slow mobile).

deleted 14y ago
[deleted]
monkeynotes 14y ago
Yeah, I was also scratching my head as to the 'performance' gains. Even if jQuery 2.0 has computational benchmark gains they also are likely insignificant in proper context.
- byroot 14y ago
  I found this one: http://jsperf.com/jquery-1-7-2-vs-jquery-1-8/29 http://jsperf.com/jquery-1-7-2-vs-jquery-1-8/29 2.0 is slightly faster on every measures.

DivisibleByZero 14y ago

I was just debating the merits of going with one of the lightweight jquery substitutions for a phonegap app. This couldn't come at a better time. Dropping the cruft and supporting 1.9 is such a wonderful way to go. Congratulations on a great release jquery team.

dave1010uk 14y ago

Now we can say "but even the latest version jQuery doesn't support IE 8!" (even though the supported 1.9 branch still does).

DigitalSea 14y ago

This is a welcome change. Considering the market share of IE 6, 7 and 8 is pretty minuscule and Google dropping support for IE8 back in November 2012 should be cause enough to drop it from jQuery too. It's great to hear they'll be supporting the older 1.9 branch for users who need to support older versions of IE as not everyone has the luxury of being able to ditch older versions of IE like that. There's no cause for concern here, the jQuery team covered their bases well and lets face it, there aren't many open source projects out there that drop support for older versions of something like a browser and then commit to continue to support an older branch for a lengthy amount of time.

hobbes78 14y ago
Is 31.37% pretty minuscule? I don't think so... Source: http://www.netmarketshare.com/ http://www.netmarketshare.com/
- colmvp 14y ago
  It is if your customer base are comprised of very few IE users.
- nbouscal 14y ago
  As best I can see on the site you linked, IE8 is 23.23%. That also disagrees significantly with this source: http://caniuse.com/usage_table.php http://caniuse.com/usage_table.php where IE8 is 8.89%
- DigitalSea 14y ago
  You combined all aforementioned versions of IE together to yield that result: http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0 http://www.netmarketshare.com/browser-market-share.aspx?qpri... — even combined the market share is still in my opinion minuscule. The only browser with a substantial market share is IE 8 which according to the site has a market share of 23%, it's not even worth adding in those other percentages on-top to try and make it seem as though a lot of people still use those browsers. 31% is not justification enough to maintain legacy code in a library that has become a little bloated over the years because of the backwards compatibility with older browsers. If you want to support that 31%, use the 1.9 branch it's better than the alternative being no support whatsoever. Edit: Why all of the down-votes, is my response offensive?

sturmeh 14y ago

Until Windows XP is banished from corporate machines worldwide, I don't think we can drop IE8 support. (You can't install 9/10 on Windows XP.) I'm glad they decided to continue support for 1.x for now.

deleted 14y ago
[deleted]

da_n 14y ago

Well done jQuery team, nice work. Wether I can use it production before April 8, 2014 is going to be debatable. I dearly would love to delete the XP VM running IE8 however.

davis_m 14y ago

I don't understand why the smaller file size is such a big deal. The file is going to be cached, and with the use of CDNs, is more than likely already cached before the client ever visits my website. So if the Query team is still going to support these browsers in 1.9, why even make the 2.0 version?

Perceptes 14y ago
File size is not only a concern in terms of download time. There's also parse time, and the amount of extra memory used to consider.
ethermal 14y ago
it isn't, it's all political.

rurounijones 14y ago

I am not too troubled by the drop of support of IE 6/7/8. As long as they continue to support IE8 in 1.9 until Windows XP EOL next year I don't really see a problem. Asking jQuery to support those browsers longer than Microsoft itself is willing do seems a bit harsh.

reustle 14y ago
> Asking jQuery to support those browsers longer than Microsoft itself is willing do seems a bit harsh. While I agree with jQuery's decision here, this isn't really fair right? Windows XP and most old stand-alone software they have installed will continue to work after MS drops support. When we're talking about the web, a reasonable effort should be made to support those legacy users. Of course, you can only do so much, but according to the general consensus in these comments, that's around 10% of visitors. Whether or not dropping them is worth saving the 12% in code size, is a different question.

verisimilitude 14y ago

Am I the only one who can not use Closure Compiler with jquery 2.0.0? ( http://closure-compiler.appspot.com/ http://closure-compiler.appspot.com/ )

Skalman 14y ago
Yeah, it gives me 29 errors. You might as well use UglifyJS, the same compressor that jQuery uses. https://github.com/mishoo/UglifyJS2/ https://github.com/mishoo/UglifyJS2/ You can try it out on http://skalman.github.io/UglifyJS-online/ http://skalman.github.io/UglifyJS-online/. It's just a light-weight wrapper.

Zangrief 14y ago

The point of separation is simpler jQuery development and reduced file-size for the >= 2.x versions. You will serve two files. You serve 1.9.x to IE 6/7/8 users, and 2.x to everyone else. You save bandwidth. You save money. Features will be the same. It's OSS folks. It's not like it's ran by a closed-source team at Google who may suddenly pull the plug if it deems the project unpopular. My guess is folks who work in enterprise (where older IE still plagues) will be the big maintainers of 1.9.x.

laurent123456 14y ago

> If you want, you can serve 2.0 to newer browsers and 1.9 to older ones using our conditional comment trick I'm really surprised they would suggest doing this. The two APIs are quite different since many functions from the 1.x branch have been removed in the 2.x or sometime behave differently (for instance `$("some <strong>bold</strong> text")` will be parsed as HTML in 1.x but considered a CSS selector in 2.x). Basically, I really wonder what could be the benefit of using this kind of conditional comment trick.

Skalman 14y ago
It'll be parsed as HTML in 1.8, but it's a CSS selector in 1.9.
curiousdannii 14y ago
If you can find a case where 1.9 and 2.0 have different APIs, file it as a bug!

darkandbrooding 14y ago

I've read through the 100+ comments that preceded me, and I must be missing something stupidly obvious. Thanks in advance to anyone who can enlighten me. Can't you just host your own copy of JQuery? If your web app needs version x.y.whatever, is there some reason why you can't just host your own copy of the library on the same servers the provide the rest of your web content? I understand the convenience of using some CDN's copy of JQuery, but I'm unsure why it's anything other than a convenience. Maybe it's about money: "It'll cost us an extra $X per month in bandwidth fees to host our own version of JQuery." Maybe it's about user experience: "By hosting JQuery on our own site we add 100ms to page load times." To the people who seem most unhappy about the version bump, can you describe how hosting your own version of JQuery would complicate your lives? Just so there is no ambiguity, I'm asking from a point of ignorance, not snark. I would genuinely like to read the answers.

crazygringo 14y ago
There is zero problem with hosting your own copy. Lots of people do. The main advantage to using a CDN is that a single copy can be cached across multiple websites, meaning that the first time someone visits your site, there's a good chance your version of jQuery already sits on their computer. Plus, the Google CDN will often serve content faster than your own site. And, since jQuery is now so "integral" to websites, it almost seems silly to have to maintain a copy of it yourself. But the main downside to using a CDN is that, CDN's have gone down before, and that means your site will stop working. Obviously, it doesn't happen often, but it happened once to a widely used site of a friend of mine, and he swore, never again will he reference jQuery on a CDN. I personally prefer to host myself too. (But not out of bandwidth savings, that just winds up being trivial.)
- Dave9k 14y ago
  You can use a CDN and fallback to local if it goes down. http://stackoverflow.com/questions/5257923/how-to-load-local-script-files-as-fallback-in-cases-where-cdn-are-blocked-unavai http://stackoverflow.com/questions/5257923/how-to-load-local...

colemorrison 14y ago

So I find that the majority of people are missing a very LARGE improvement that I value far beyond any of the stated benefits by the jQuery team: -One of the most popular libraries is dropping support for IE 6,7, and 8. Thus, yet another cornerstone of the web is going to push users forward and increase the chance that those miserable browsers will disappear. The most disturbing thing I find is that there are developers that are DEFENDING existence for those older browsers. Are you masochists? Do you enjoy the headaches of fucking around with those?? "Oh but so many clients are still using them, and it writes off potential users!" How can we ever expect for them to upgrade their damn browser unless the builders the web (developers, not just browsers) quit allowing them to rot in complacency???? Of course, there is a thing as going "too leading edge" and expecting "too much" from the user...but when the cornerstones (libs, browsers, etc) start pushing them forward - then we should embrace this change. Coding for the multi-browser/platform/device/version web is hard enough.

theycallmemorty 14y ago
The main problem I see is that IE9 does not work on windows XP. How long will we continue to see Windows XP machines in the wild?
- acdha 14y ago
  Microsoft will not be doing it past 2014. I wouldn't care more about their OS than they do, particularly given the extreme security risks.
democracy 14y ago
Not defending, but if you cannot degrade your functionality to make it work in old IE then you doing something wrong. Please, give me a use-case that is not too niche but absolutely requires the latest generation of browsers.
ethermal 14y ago
I don't get this line of thinking. Do you know there are programs written on system/36 machines from the early eighties still in production today on ibm iSeries machines? And even older software/systems in place that are older then that. Business requirements don't change hourly/weekly/monthly. If the business requirement that existed at that point in time, that the software solution put in place at that time met those requirements why would a business be compelled to change if those requirements have not changed and the solution met those needs? I've been a developer a really long time, 25+ years professionally. Businesses demand stability, this absolutely absurd idea that software that is only a few years old must be thrown out and some new flashy unproven shit put in its place is mind boggling. The last job I put a bid on, one of the requirements was that the software in initial form be supported for a minimum of 10 years. And in my experience that is a short life span.

silasb 14y ago

Anyone know if the jQuery 2.0 fixes/enhancements will also be applied to the 1.x branch, particular the 1.9 series. Based on what I've read they are running in parallel with the IE stuff removed. I can't seem to find anything that mentions that 1.x stuff has been updated and released.

jrochkind1 14y ago

One thing that confuses me: If the JQuery team is committed to keep supporting 1.9/1.x, entirely API-compatible with 2.0 -- what is the benefit to JQuery of the 1.x/2.x fork? You get a cleaner easier to maintain codebase in 2.x -- but you've got to keep maintaining 1.x anyway. If there was a feature you didn't want to add to 1.x because it was too hard -- you still can't add it to 2.x and not 1.x, because you committed to supporting 1.x as API-compatible, no? Is the idea that 2.x will provide better performance on capable browsers than 1.x? So, yeah, the development burden is no less, but the results are better. I guess I understand why people are doubting whether they will really follow through -- because if they do follow through, it makes it somewhat unclear what the benefit of the 2.x refactor was in the first place.

EGreg 14y ago

It would be nice if jQuery made builds for every browser, so savvier developers who can write server-side code can actually spit out only the relevant jQuery to the relevant browser. I mean, it's not like caching files at the ISP level is the limiting factor here, so each browser can cache its own file.

drorweiss 14y ago

Will jquery still work with jsdom on node.js? the 2.0 or 1.9 jquery?