Your arguments about compatibility with old browsers is great, but sadly the jQuery team doesn't actually believe that the problem they are solving should include compatibility with those versions of IE: the latest versions of jQuery decided that IE9 is the oldest version they are going to support going forward, as they didn't want to deal with the overhead (both in code and in development effort) of being a library designed to solve the problem of cross-browser JavaScript development... in a world where jQuery is just aiming for "improved syntax for DOM manipulation, compatible only with relatively recent browsers" (something I will argue has always been the case, due to their rather early deprecation of Safari 1.x), those examples cannot be dismissed: jQuery is just being used to avoid the complexity and verbosity of native APIs.
That's not true. There are two latest versions, one of which supports older browsers.
It had sounded from the 2.0 announcement that they are only supporting 1.x for purposes of back-porting bug fixes. If the goal is to do some kind of long-term commitment to the mission of cross-browser compatibility, then forking off "2.0" seems pointless and even harmful. To verify, however: if this article then specifically was comparing jQuery 2.0 to native DOM, would you submit that iamjared's complaint would not apply? ;P
Re:Native equivalents of jQuery functions
by DavidHogue on Monday May 20, 2013 @11:53AM
(#5738273)
In fact there's even a 1.10 beta out now, so they are not dropping support for IE6/7/8 anytime soon. It's true jQuery 2.0 can't be used with old IE, but if that's what you need to support use the 1.x branch.
Re:Native equivalents of jQuery functions
by euroclydon on Monday May 20, 2013 @12:02PM
(#5738315)
What I don't understand is, why did they have to keep <IE9 support in version 1.9 AND break compatibility by removing a bunch of functions as well as create a new version strand, 2.0, that drops support for <IE9. Why not jus break the API in version 2.0 only?
They've specifically mentioned a few times being able to detect browser version and load the appropriate version of jQuery. The 2.0 branch is supposed to get cleaner, faster code by virtue of dropping old workarounds (I imagine in some instances this may be quite a difference, as they may be able to refactor entire code paths if they can make new assumptions).
As such, they need to keep the API standard between versions. Unfortunately, they don't appear to have settled on the best API yet, so are constantly working to improve it.
I doubt the functions you are seeing removed[1] from 1.9 are specific to 1.9 being special or dual released with 2.0. They were more likely just removed because they were at the end of their deprecation cycle.
Question: if jQuery 2.0 only cares about modern browsers, can't they drastically improve performance by using these equivalent native functions behind the scenes?
They do all over the place. Still, there's an abstraction layer to work with in detecting these host methods and in providing a backwards-compatible implementation (polyfill).
Re:Native equivalents of jQuery functions
by jamesaguilar on Monday May 20, 2013 @11:12AM
(#5738069)
What I'm curious about is, if these are equivalent, why doesn't JQuery just delegate to them in browsers where it is supported? Then you can get both the speed and the compatibility.
In the case of querySelectorAll, it does[1] (after performing some checks for easy wins) and if this test[2] is anything to go by, it can actually perform better in some cases.
[1] https://github.com/jquery/sizzle/blob/master/sizzle.js#L237
Personally I use jQuery Desconstructed when examining what's under the hood:
http://www.keyframesandcode.com/resources/javascript/deconst...
If you're building games or working with a team who does, I'm going to guess you're working with fairly edge functionality in browsers where javascript support is great. If you're building sites for clients who are still (sigh) using IE7 internally, you just can't get away with something quite so simple.
As another commenter mentioned: "Even the most avid follower of JS updates can't compete with a team of the standard jQuery draws upon. When a new method gets rolled in to the core of jQuery, something that speeds up selectors for example, your code improves without you doing any work."
This is the same reason I use a library for preprocessing my CSS. I'd rather update a gem and trust a team whose focus is processing CSS than try to rely on myself for keeping up to date with the pace of the CSS WG and browser vendors.
Also, for anyone wanting to dig around the jQuery source, James Padolsey made a great tool for it. I know I was pretty amazed to find out just how much is going on under the hood. http://james.padolsey.com/jquery/#v=git&fn=