We 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.
> Download and runtime speed are not a problem on the Desktop.
When I'm stuck in the wilderness with nothing but an atom based netbook tethered to a patchy and expensive GPRS connection, I beg to differ.
Anyway, it isn't just about your bandwidth to your desktop - if each user is transferring less it can be significant for the server-side.
If they make proper efforts to maintain 1.9.x for a goodly amount of time the "hitting a bug in one version but not the other" issue shouldn't be more significant than the current "hitting a bug in a third party library (jQuery) which I don't have the expertise to locate+fix" issue that we already have to consider. Of course the "if" at the start of that sentence could be cause for concern but I think the jQuery project has done well enough at QA in the past for me to give them the benefit of the doubt (or at least to reserve judgment) at this point.
>When I'm stuck in the wilderness with nothing but an atom based netbook tethered to a patchy and expensive GPRS connection, I beg to differ.
Who cares about outliers like that? How many people using your webpage are connecting like that? 1%? 0.1%? Less? Are you really going to make major decisions based on 0.1% of your users?
And what's more, if you're building a website for that kind of usage, you probably shouldn't be using a big javascript library in the first place. And the people on those connections should experiment with scriptblocking and selective script whitelisting so they're in control of their poor connection.
Know your audience, I think, is the most important factor when deciding how to go forward.
>When I'm stuck in the wilderness with nothing but an atom based netbook tethered to a patchy and expensive GPRS connection, I beg to differ.
That's not a Desktop. That's a cellphone conection and processing power that, by todays standards, reassembles a phone more than a laptop.
But even on mobible, latency is a much bigger problem than file size.
>"hitting a bug in one version but not the other" issue shouldn't be more significant than the current "hitting a bug in a third party library (jQuery) which I don't have the expertise to locate+fix" issue that we already have to consider.
All things being equal, you have twice as many chances of hitting a bug with two code bases than with one.
If 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
Why 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
I 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.
It'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/
