<!--[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]-->

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.

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.

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.

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.

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

That's a terrible solution.

>unreliable connections and mobile devices with slow processors

Which are not Desktops, so I don't see your point.

>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

You already have to deal with two codebases, IE8 and IE9. One can have bugs that the other doesn't.

Right now, you deal with:

* IE8 + jQuery 1.9 * IE9 + jQuery 1.9

I assume you are testing both? If so, then all you will have to do is instead test:

* IE8 + jQuery 2.0 * IE9 + jQuery 2.0

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.

In other words, it will correctly use jQuery 2.0, like any other browser without conditional comment support.

Yep, it's ancient. Chrome and Firefox are on average about 3 weeks old. IE8 is over 50 times older.

>jQuery's main raison d'être might have gone out the window.

Normalization was just one part. It still provides a much nicer API. There are also events, AJAX, effects, and some useful helpers.

    [].slice.call(document.querySelectorAll('p')).forEach(function (el) {console.log(el);});

     $('p').each(function () {console.log(this);});

I hope you realize that by saving yourself a few characters you've sacrificed an unknown amount of performance from your site. For such a simple query I'd use getElementsByTagName instead.

The point was to demonstrate that the API is somewhat flawed since it doesn't return something usable. The "clever" short version was used to show that you have to write quite a bit more code - even if you make it really ugly.

>For such a simple query I'd use getElementsByTagName instead.

It's a generic example. The selector was kept short and simple for the sake of brevity.

But is that really the best possible use of your time?

BTW that could be written like this:-

  [].forEach.call(document.querySelectorAll('p'), function (el) { console.log(el); });

They're pretty clear that 1.9 and 2.0 will have API compatibility so there is an option for those who still have to support oldIE and one for those who don't have to. Seems like the best possible arrangement.

More the reason I think jQuery could be shooting itself in the foot. Its ubiquity is based on the fact that if you're doing client side javascript, jQuery is the best option. Coupled with what I started this comment with - its possible that jQuery isn't the best option for everyone anymore.

I personally am not a huge fan of frameworks. Too often I see people solving problems by adding frameworks. Maybe I'm just a crusty guy who doesn't use a lot of tools.

That's old!

When JQuery 1.9 is released in 2013 it'll be four years old. Windows XP is eleven years old and will be end of lifed in early 2014. At what point will you pull the pin?

I think this is a good roadmap for phasing out Old IE support. It's not like they're yanking the rug out from under you - 1.9.x will be around for a while yet.

And I didn't demand anyone do anything. I think the proposed jquery plan is totally appropriate.

Firefox and Chrome do automatic updates, and almost never has issues. That's because they stick to standards in an open and transparent manner. Why wouldn't Windows Update be able to do the same thing? Are the Microsoft software developers really that bad that they can't do what the Chrome and Firefox developers can do already?

This looks far more likely to be a political decision to avoid whatever backlash even a single failed update would produce.

Help, i've lost all 93 of my open tabs..

I was, at the time, living with my girlfriend and a friend of hers, both of whom used 10.4 and Safari 1.x: it was honestly quite common among people who couldn't quite afford new computers.

Regardless, when we sent the demo of our product for the local school district I was getting reports that the entire browser was crashing, which I traced down to some sketchy code in jQuery that had been tested so poorly on this version of Safari that no one noticed this highly fatal error.

When I reported the issue to a major jQuery contributor (a friend of mine), all I got was flak that people shouldn't be using that browser and should upgrade to 10.5... obviously I have never used jQuery in a project again.

Which was a perfectly sensible decision from a developer POV considering how bad Safari's JS and DOM support was until 3.x

> despite that being available version of Safari available for Mac OS X 10.4.

10.4 was released with Safari 2.0 and got updates up to 4.1.3. Are you talking about 10.3?

The project I was working on was the kind of thing that probably had just a couple hundred people (if that, maybe even less) visit it during our testing period, and I got multiple reports of that crash.

If you want to popup a dialog box on these devices that says "I'm sorry, you are not supported" that's fine, but if it isn't even being on a browser like that, then no: it becomes entirely correct to point out that it was never actually good at handling cross-browser compatibility issues.

It's a little like saying "the main sole goal of your existence".

Microsoft is the only major browser vendor to believe that a 3-year-old browser is acceptable on a supported OS (XP). Google, Mozilla, Apple, Opera support XP with their latest browsers.

I agree it's too soon to drop support for IE8, but I'd love to see more pressure put on MS for leaving XP+IE users stuck with a second rate browser.