5 ms·
The premise is that jQuery 1.9 and 2.0 are API-compatible, so you can do something like: <!--[if lt IE 9]> <script src="jquery-1.9.0.js"></script>
by wycats 14y ago
The premise is that jQuery 1.9 and 2.0 are API-compatible, so you can do something like:
<!--[if lt IE 9]>
<script src="jquery-1.9.0.js"></script>
<![endif]-->
<!--[if gte IE 9]><!-->
<script src="jquery-2.0.0.js"><</script>
<!--<![endif]-->
New browsers will get a lighter download and a faster runtime. oldIE will still work with all the hacks required to make it work.
- mkmcdonald 14y agoYou do realize that IE 10 dropped conditional comments, right?
- wycats 14y agoIf you look at the second conditional comment, it will not be parsed as a comment in browsers without conditional comment support. In other words, it will correctly use jQuery 2.0, like any other browser without conditional comment support.
- seldo 14y agoIt's a conditional conditional comment. I feel ill.
- deleted 14y ago[deleted]
- WickyNilliams 14y agoIt's known as a downlevel revealed conditional comment. You will see it in use in the HTML5 boilerplate. That said, I echo your sentiment, it is an immensely horrid syntax. For more info: http://css-tricks.com/downlevel-hidden-downlevel-revealed/ http://css-tricks.com/downlevel-hidden-downlevel-revealed/
- deleted 14y ago[deleted]
- Zarel 14y agoYou do realize that IE 10 will be supported by jQuery 2.0, right?
- jcromartie 14y agoYou do realize that saying "you do realize, right" is about the rudest and most condescending way to pass on information, right?
- tambourine_man 14y agoWe deal with enough conditionals already. Besides, sharing the same API won't stop you from bumping into some bug that's present in one version and not the other. We'll have to deal with two codebases. Download and runtime speed are not a problem on the Desktop. They should have had the guts to admit that this is all about mobile. Their denial at the end of the post is symptomatic.
- solox3 14y agoWill running functional tests help?
- CrazedGeek 14y agoDownload and runtime speed are definitely a problem on desktop OSes -- mobile broadband, slow DSL, netbooks, that sort of thing.
- alecr 14y agoIf you don't like conditionals, then don't use them. Stick with 1.9 or 1.8 Download and runtime are absolutely a problem on the desktop. There will always be a decent amount of people on unreliable connections and mobile devices with slow processors
- tambourine_man 14y ago>Stick with 1.9 or 1.8 That's a terrible solution. >unreliable connections and mobile devices with slow processors Which are not Desktops, so I don't see your point.
- alecr 14y agoWhy is it a terrible solution? What jQuery API features (that might be developed in 2.x) are missing that you need? The current API fulfils the purpose of the jQuery Project; many of the recent API changes have been syntactic sugar changes and I imagine most future ones will be as well. >Which are not Desktops, so I don't see your point Oops... Well anyway, I know plenty of people who cannot get DSL or cable in their area and rely on spotty wireless connections
- acavailhez 14y agoElegant solution, but it's not possible if you bundle/minify all your scripts in one giant file, as more and more do.
- secoif 14y agoIt is only not possible if you are incapable of changing your build script.
- calvin 14y agoI can think of a lot of reasons this approach won't work well for most of the sites I work on (other than a few blogs). 1) Combining jQuery with other JavaScript at build time (to reduce HTTP requests). At built-time, we don't know which browser they're using. We'll end up with two assets (the combined version w/ jQuery 1.9 and the combined version w/ jQuery 2.0). 2) Testing costs. For larger sites it's not a trivial thing to test and support two different versions of jQuery. For any site that still needs to support IE8 (and 7 and 6), it will not be feasible to test and support two different versions of jQuery. As such, we'll never get the benefits of using jQuery 2.0 and would not be able to do so for many years. 3) Plugins will be written that only work for one of the two versions (1.9 or 2.0). This will divide the plugin ecosystem. Ideally, plugins should work for both, but many people will only test and support their plugins on one of the versions.
- gnarf 14y agoIt will be very difficult to develop a plugin for 2.0 that won't work on 1.9 - they will be 100% API compatible, and pass the same set of unit tests.