Hacker News new | comments | show | ask | jobs | submit login

Sorry, but this is a disaster. Dropping support for IE6 may be OK, IE7 is a bit too soon, but IE8?

I haven't tested my stuff on IE6 and IE7 for a long time, but I still do it on IE8 everyday. It was released in 2009! And it's decent enough, PNG transparencies, etc.

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




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.


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.


Download and runtime speed are definitely a problem on desktop OSes -- mobile broadband, slow DSL, netbooks, that sort of thing.


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


>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.


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


> We'll have to deal with two codebases.

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


Will running functional tests help?


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 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.


You do realize that IE 10 dropped conditional comments, right?


If 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.


It's a conditional conditional comment. I feel ill.


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/


You do realize that IE 10 will be supported by jQuery 2.0, right?


You do realize that saying "you do realize, right" is about the rudest and most condescending way to pass on information, right?


Elegant solution, but it's not possible if you bundle/minify all your scripts in one giant file, as more and more do.


It is only not possible if you are incapable of changing your build script.


>[IE8] was released in 2009!

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);});
vs

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


Agreed, [].slice.call is show-offy and pointless. Array.prototype.slice.call is the way to go.

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.


>Array.prototype.slice.call is the way to go.

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.


Um, when did we forget how to write our own abstractions? It’s not black and white, either jQuery or vanilla JS with no helpers.


Yes, we can of course reinvent our own untested and undocumented triangular wheels.

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


Good point.

BTW that could be written like this:-

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


Array.prototype.forEach didn't arrive in IE until 9, so if the point is that you can do anything that jquery can do, this won't work.


huh? Might want to check the comment I was replying to.


"jQuery's main raison d'être might have gone out the window." - my thoughts, exactly!


I'm not sure I see the issue here. If someone convinced me that jQuery 2.1+ will get great new features (not available for those forced to use 1.9) then maybe I'd feel differently. What's more likely is that innovation on 2.+ versions will be specific to modern browser features not supported by IE <= 8 anyway. If feature envy hit critical mass, I'm sure there'll be a new OSS project to port these features anyway. Also, months/years from now when Chrome 30 is released (for example), these 1.9ers will still have a library that supports both Chrome 30 and IE6! Maybe jQuery is a lib that has hit its API and performance limits for IE <= 8.


The app I work on dropped IE7 a year ago, and is dropping IE8 in January 2013. Therefore this is the opposite of a disaster, pretty timely actually.

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.


API comparability does not ensure functional comparability. Two code bases too.


Unless users of oldIE versions contribute more revenue than it takes to support them (which is obviously app/site-specific), screw them. It's simple economics.


I don't disagree with you one bit. This will vary for each company depending on industry, the average browser of the target market, and the price-point for the product.

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.


> IE7 is a bit too soon, but IE8?... It was released in 2009!

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.


You realize IE8 is the default browser that shipped with Windows 7, right?


I fail to see your reasoning. IE6 was (I believe) the default in Windows XP, which people are still using. Should we demand that JQuery support every default browser on every default OS until they're all end-of-lifed?


My point is that it isn't just the browser for an ancient os that's about to be EOL. It's also the browser for the current OS. Some people seem to mistakenly think Win 7 shipped with IE9

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


Yes.


What, nobody uses Windows update?


yes, a lot of people (generally the people who don't know what a browser is) don't. Also IE8 is the last available browser on winXP.


Except for Chrome, Opera and Firefox, you mean?


That's hardly the point - the original poster was complaining about the default browser on Windows 7.


Oh come on - this is voted down?

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 grates me.. I'm sure the MS devs are more than capable of doing what Chrome / Firefox "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..


Sure most people do


It makes more sense to use the dates they were superseded, than to use the dates when they came out. Most new computers were still shipping Windows XP until Windows Vista came out in 2007. That's just over five years ago.


jQuery was never good at this. When I first used it on a project they had already drooped support for Safari 1.x, despite that being available version of Safari available for Mac OS X 10.4.

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.


> When I first used it on a project they had already drooped support for Safari 1.x

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?


I simply cannot agree with you on this one; in my book, it is not in any way a perfectly sensible decision to make a browser that a ton of people were still using entirely crash when webpages using the library were opened.

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.


10.4 shipped with Safari 2.x and could be upgraded up to 4.x. You mean 10.3?


I'll happily accept that (it was a while ago).


What have you been using instead?


Just FYI saying "main raison d'être" is redundant.

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


IE8... released in 2009

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.


Yea, MS has in general never released new versions of IE for a version of Windows that entered extended support, and the extended support phase lasts for five years!


How is this "dropping support" for old IE? They've said the 1.9 branch will still receive bug fixes for a while. I doubt they'll leave the 1.9 branch behind (in regards to new API features) until IE8 gets close to IE6's current market share.


What do you mean dropping IE8 support? The jQuery Core team still supports IE 6, 7, and 8, and has not announced that they are dropping it. That's what jQuery 1.9 is about.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: