7 ms·

Why It's Time to Sunset jQuery

64 points by jasoncrawford 14y ago

evadne 14y ago
It might make sense to cherry pick jQuery features and build your own jQuery — if you absolutely need it, and absolutely can’t carry the whole library. In other cases I think it’s mostly just bikeshedding. jQuery is there to minimize surprises. Native API is magnitudes faster — yes. It is also divergent across browser runtimes. Then you code for special cases and test by hand, now you’re building your own jQuery. Maybe we have better things to do.
- recusancy 14y ago
  IIRC jQuery 2.0 will have the option for custom builds.
  - jugglinmike 14y ago
    jQuery supports custom builds today: https://github.com/jquery/jquery/blob/e80117adb49eff8f82140b01d755bdeefe7eb089/README.md#modules https://github.com/jquery/jquery/blob/e80117adb49eff8f82140b...
    - evadne 14y ago
      This is good. Thanks :D I’m thinking along the line of what jQuery UI did — offering ability to customize a version of jQuery you can download from the site.
- Turing_Machine 14y ago
  "yes. It is also divergent across browser runtimes." And likely to get more so, now that Google has forked WebKit. Losing support for IE 6 (or whatever) is no big deal, but support for both Android and Mobile Safari is critical.
neya 14y ago
Is this a joke? A huge percentage of the web is running with Jquery. Jquery targets a different set of audience - Ones that want to do more stuff with less code. This type of audience doesn't care about performance (mostly) because it helps them get things done. Think of it this way - Everyone loves Ruby on Rails. But Rails IS slow. But that doesn't mean I should re-write my code in just plain C, just because it is fast and Rails is no longer needed according to a bunch of bloggers. I think this argument is not about Jquery and is about frameworks in general. In my humble opinion, I think [1] $.ajax({ url: "test.html", context: document.body }).done(function() { $(this).addClass("done"); }); is better than: function ajaxFunction() { var ajaxRequest; // The variable that makes Ajax possible! try { // Opera 8.0+, Firefox, Safari ajaxRequest = new XMLHttpRequest(); } catch (e) { // Internet Explorer Browsers try { ajaxRequest = new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { try { ajaxRequest = new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) { // Something went wrong alert("Your browser broke!"); return false; } } } // Create a function that will receive data sent from the server ajaxRequest.onreadystatechange = function () { if (ajaxRequest.readyState == 4) { var ajaxDisplay = document.getElementById('ajaxDiv'); ajaxDisplay.innerHTML = ajaxRequest.responseText; } } var age = document.getElementById('age').value; var wpm = document.getElementById('wpm').value; var sex = document.getElementById('sex').value; var queryString = "?age=" + age + "&wpm=" + wpm + "&sex=" + sex; ajaxRequest.open("GET", "ajax-example.php" + queryString, true); ajaxRequest.send(null); } [1]http://www.tizag.com/ajaxTutorial/ajax-javascript.php http://www.tizag.com/ajaxTutorial/ajax-javascript.php
- johnbender 14y ago
  I agree with your general point about the value of abstractions, but jQuery is rarely the bottleneck where DOM manipulation is concerned. Most of the execution time in browser applications is spent rendering/reflowing content. It's only sane to use the DOM API once you've shown that the jQuery JavaScript execution is a significant portion of total execution time relative to reflows. An interesting side note here is that the Rails analogy remains somewhat apt, in that much of the execution time in web applications is spent in the data store.
ben336 14y ago
I felt like the article did a good job of explaining the potential replacements, but failed to make a convincing case for why the perfomance benefits outweigh the simplicity of jQuery. There's a conversation to be had about balancing those two, but this post makes the implicit assumption that performance is king and never really addresses the tradeoffs between performance and simplicity/familiarity.
- evadne 14y ago
  One of the many starters: http://www.greensock.com/jquery/ http://www.greensock.com/jquery/ (Enjoy.)
  - dirtyaura 14y ago
    Wow, I've never heard of GSAP before but it looks really promising, if you want to have a detailed control of animations for your app. I'd love to hear both plusses and minuses from someone who is using it production code.
    - mddw 14y ago
      It's awesome, but only useful on very specific animation-heavy projects. Otherwise it's quite overkill.
ebbv 14y ago
This is hilariously wrong-headed. - If you use the standard jQuery hosted off Google's CDN, most users won't have to load it in the first place. So that overhead doesn't count. Only if you do some boneheaded thing like rolling your own version and hosting it on your server are you going to guarantee every visitor has to download jQuery. - Parsing jQuery is trivial for most modern browsers. If your web app has performance issues, it's not jQuery's fault, it's your fault. - querySelectorAll is not a replacement for jQuery. If you think it is you haven't been making good use of jQuery. This article seems like a post by someone who didn't even know how to do basic things against the DOM, finally learned how to do them and now thinks there's no use for jQuery. It's absurd. jQuery still has plenty of uses. I'm not saying you have to use it, or are making a mistake if you don't, but the assertion that it should be abandoned is ludicrous. Ugh.
- slig 14y ago
  > - If you use the standard jQuery hosted off Google's CDN, most users won't have to load it in the first place. So that overhead doesn't count. Only if you do some boneheaded thing like rolling your own version and hosting it on your server are you going to guarantee every visitor has to download jQuery. Well, it depends. [1] [1]: http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...
  - SoftwareMaven 14y ago
    Those statistics weren't very helpful. It doesn't matter how many sites are using the CDN, it matters how may people visit those sites. If only 0.05% of sites used it, but 80% of people visited those sites, it would be worth using.
- Offler 14y ago
  I've found memory leaks in long running single pages apps that were down to jQuery UI components so I wouldn't dismiss jQuery performance doubts so quickly.
  - ebbv 14y ago
hsmyers 14y ago
I fear the OP conflates his usage with the rest of the world. Had he presented it as more of a 'this works for me' I'd have paid more attention. My own usage involves things I don't even want to re-invent wheel or no.
varunkho 14y ago
Everything moves in cycle. Yesterday I started coding and found fragmentation to be the biggest issue so I thought I needed a framework to do anything reasonable. That issue got solved and I have got used to it. So today I am finding that performance is the issue. I again decide to dich the framework and start hacking it by hand. Tomorrow I find ... I focus more on tools rather than building things that matter in the end.
ashray 14y ago
You know what I love about jQuery ? It's readable. Every time I have to look at plain ol' javascript it feels like my eyes are going to bleed. Regardless of whether I wrote it myself or whether another developer wrote it. On the other hand, jQuery (still not the Miss World of programming languages..) is far easier on the eyes. Also, for most apps, the performance impact isn't all that noticeable since most of the performance hit happens due to reflows and not because of jQuery. Plus, the Google CDN jQuery is pretty well cached in most browsers.
- beatgammit 14y ago
  I don't think so, for example: var list = querySelectorAll(selector); var i; for (i = 0; i < list.length; i++) list[i].value = value; Is just as readable as: $(selector).val(value); Except that the jQuery example requires you to be familiar with jQuery. The first, however, just requires you to be familiar with a for loop, which is a common construct in many languages. Being faster is just a happy by-product. I, personally, am starting to use Dart instead, because it is a nice middleground between jQuery and raw DOM manipulation; it doesn't hide the details like jQuery does and it's still fast. Ihe best argument I can see is with XMLHttpRequest, which is still a pain because it doesn't have a nice API.
  - jarcoal 14y ago
    Chain a few more commands onto that example and then we can talk about how readable the pure JS version is.
    - beatgammit 14y ago
      I've never liked chaining, and I hardly ever find a time when it's needed now: * animations: CSS3 * templating: I don't do it, I prefer static pages and toggle sections with classes * element filtering: better selectors (nth-child, nth-of-type, [data-stuff=''], etc) * form serialization: either use event handlers and build it as you go or just use regular browser form handling Currently, I use reqwest [1] for my HTTP requests. It's very small and is cross browser. In Dart, I just use the built-in libraries. [1] - https://github.com/ded/reqwest https://github.com/ded/reqwest
eknkc 14y ago
DOM manipulation and querying is a small subset of what jQuery does. There's ajax, event handling, dom creation from html fragments, animations, utility functions, size / position / offset calculators etc. And there are messy cross browser stuff in there. Yeah, let's get rid of it.
deleted 14y ago
[deleted]
mddw 14y ago
"I encourage you to give it a shot. Write your next application, library or just code for fun without jQuery. " Been there, done that. And it's a pain in the * You'll find yourself needing a method to add or remove classes eficiently. So you'll rewrite .addClass() and .removeClass() Then you'll need a clean way to make Ajax and callbacks. You'll rewrite .ajax() and .when() Then you'll need to fade something in all browser. So you'll rewrite .animate() Ad lib. JQuery Minified and GZipped is 35k (not 90 as the op said, ignoring the gziping.) JQuery is cached in most browsers. The performance hit is not worth the pain of re-inventing the wheel. The problem is not JQuery, it's bad code. Bad code won't magically disappear in vanilla JS.
- neya 14y ago
  Well said!
- gildas 14y ago
  > You'll find yourself needing a method to add or remove classes eficiently. So you'll rewrite .addClass() and .removeClass() You don't need to rewrite it, cf. this shim [1] for example. > Then you'll need a clean way to make Ajax and callbacks. You'll rewrite .ajax() and .when() They are plenty of good Ajax implementations, for example this one [2]. If you need promises, there are good libraries too [3]. > Then you'll need to fade something in all browser. So you'll rewrite .animate() Applying a fading effect on an element shouldn't be a mandatory feature. You can just use CSS3. [1] https://developer.mozilla.org/en-US/docs/DOM/element.classList https://developer.mozilla.org/en-US/docs/DOM/element.classLi... [2] http://jibbering.com/2002/4/httprequest.html http://jibbering.com/2002/4/httprequest.html [3] https://github.com/kriskowal/q https://github.com/kriskowal/q
  - nasmorn 14y ago
    Client: I want this element to fade out. Me: No problem but only on browsers with CSS3 support. Client: What is CSS3? Me: Let me say it differently, it wont work on some browsers. Client: Why, is it hard to do? Me: Not really, but I would need to use an open source library to do it. Client: But don't you usually tell me that that's a good thing. Me: Yes but see yesterday I someone on the Internet said it should not be a mandatory feature. Client: You are fired.
wildgift 14y ago
JS performance isn't that important for most tiny apps. It's client side code and distributed. If JS performance were important, someone would write a jQuery -> js compiler and produced compiled js as output. But they don't do that, because once you benchmark the code, you find out that DOM is very slow, as johnbender mentioned. I'm still used to hacking in vanilla JS, but when I want to write something longer than a hundred lines, I load jQuery. It's the only sane tool to reduce code size. It does it in a pretty disciplined, lisp-y way, too. It's liberal use of the $(selector).f(x).g(y).h(z) style, which applies the function to the previous result, which is a collection, helps you code at a higher level of abstraction. No more loop structures! It's not time to sunset jQuery: it's time to put more support for jQuery style functions into ECMAScript, so you can get better performance though parallelization, lazy evaluation, etc.
mistercow 14y ago
I've seen a couple of people talking this way lately, and while we might be able to start talking about this in five years, the idea that after IE8 (or even IE9), we're past the point of needing a library to abstract away the differences between browsers is pure fantasy. As is the idea that now that we have querySelectorAll, the DOM suddenly isn't a complete nightmare of an API.
mvasilkov 14y ago
True, jQuery is still kind of nice niche tool for when you have to do lots of DOM manipulation, but it's no longer required. As an IE compatibility layer it did well, but I won't miss the $.unreadable($.mess()).
SeanDav 14y ago
Considering that the highest version of IE that Windows XP can support is IE 8 and the large number of XP machines still out there - it will be fairly silly to not support IE 8 for at least a couple more years.
tete 14y ago
jQuery is used a lot, because it describes a set of features and an interface that many other libraries build upon.
tete 14y ago
For people that worry about jQuery being to big, there is a lighter replacement for more modern browsers, doing (mostly) the same as jQuery: http://zeptojs.com/ http://zeptojs.com/
- zalew 14y ago
  if I understand correctly, the selling point of zeptojs is that it saves an enormous 20kb while breaking compatibility with half of everything out there?
eupharis 14y ago
Well, in the specific case of using native selectors (document.querySelector), I'm sold. It's supported very widely: http://dev.w3.org/2006/webapi/selectors-api-testsuite/level1-baseline-report.html http://dev.w3.org/2006/webapi/selectors-api-testsuite/level1... Wish I'd known about this before. I've been using $('#main').get(0) when I didn't want a jQuery object. Which is all kinds of silly.
camus 14y ago
So now say "death to jQuery" and it makes you look cool trendy right ? or what ? because saying "death to flash" is so 2010 ? I hope you test your code like in 5 desktop browsers with different versions + 4 mobile browers with different versions , what , you dont ? well jQuery devs do ... you dont care ? oh yeah your one of these mobile first , desktop last devs , then good luck with old versions of android browsers ... I'm always amused by all these "death to this" , "death to that" , like it gives anyone any credibility... So you get it folks , dont use jquery , reinvent the wheel like a true purist ,and remember to tell everyone "jQuery must die" , while professionals have code to ship.
- cosmez 14y ago
  so you're saying that just by using jquery i dont have to test on every possible browser version and mobile too? i dont know what kind of jquery i been using but i do that everyday.
mosselman 14y ago
Have fun doing things like $('div').animate({opacity: '0.4', left: '10px', background-color: '#44444'}); in native js. Of course you CAN do it... but do you want to?
- gildas 14y ago
  You're right, it's better to write it with a CSS3 transition.
  - mosselman 14y ago
    True, +1 for the nativeness. But we are still a short bit away from being able to reliably use CSS3.
    - rjett0 14y ago
      That's IE's fault. CSS3 transitions really should've been in IE9.
sourc3 14y ago
The author's point is valid for selectors, but he is not considering the plethora of plug-ins that are built on top of jQuery and just work. Until browsers can support all of that, I think we are a LONG way from saying goodbye to jQuery. For all I know jQuery is saving me a ton of time when working on my prototype for the new side project. Last thing I want to do is to re-invent the wheel at my own expense :)
hcarvalhoalves 14y ago
jQuery exists because the native APIs available in browsers are not cross-compatible and suck at the same time. jQuery can be left alone once browsers revert the historical decision of just shipping a small core language.
conover 14y ago
Why not build a tool that takes in a set of JavaScript files, analyzes them, and outputs a stripped down, compressed version of jQuery with only the features used in the input?
- cosmez 14y ago
  thats the exact reason i used to love mootools, but too many companies demand for jquery even if they arent going to do any coding. before the library war started (prototype, jquery and mootools) i picked mootools for that exact reason, after so many lines written against that library i cant understand why jquery won in the end.
idan 14y ago
Not knowing the details of jQuery 2.0's cruft removal, I wonder how much the performance gap is closed by a jQuery that doesn't need to deal with Really Old Browsers™.
mmmelissa 14y ago
"first you need to make the assumption of a browser baseline. For me it is at least IE8, however that is quickly moving to IE 9 as most should upgrade to at least IE9, even stodgy old enterprises" BAD ASSUMPTION Just because they should doesnt mean they have or will anytime soon!!! Have fun convincing my "stodgy old enterprise" to upgrade to IE9. They JUST upgraded to IE8! Yes, ideally no one should be using these crappy old browsers, and I champion this idea and all of the reasons why at work all the time. Rational arguments dont work in the kool-aid world of government. (Does it need to be said that I am looking for a new job?) A lot of people browse the web from work, and so I dont think it is safe to ignore all of those crappy browsers yet.

64 points by jasoncrawford 14y ago

It might make sense to cherry pick jQuery features and build your own jQuery — if you absolutely need it, and absolutely can’t carry the whole library. In other cases I think it’s mostly just bikeshedding. jQuery is there to minimize surprises. Native API is magnitudes faster — yes. It is also divergent across browser runtimes. Then you code for special cases and test by hand, now you’re building your own jQuery. Maybe we have better things to do.

recusancy 14y ago
IIRC jQuery 2.0 will have the option for custom builds.
- jugglinmike 14y ago
  jQuery supports custom builds today: https://github.com/jquery/jquery/blob/e80117adb49eff8f82140b01d755bdeefe7eb089/README.md#modules https://github.com/jquery/jquery/blob/e80117adb49eff8f82140b...
  - evadne 14y ago
    This is good. Thanks :D I’m thinking along the line of what jQuery UI did — offering ability to customize a version of jQuery you can download from the site.
Turing_Machine 14y ago
"yes. It is also divergent across browser runtimes." And likely to get more so, now that Google has forked WebKit. Losing support for IE 6 (or whatever) is no big deal, but support for both Android and Mobile Safari is critical.

neya 14y ago

Is this a joke? A huge percentage of the web is running with Jquery. Jquery targets a different set of audience - Ones that want to do more stuff with less code. This type of audience doesn't care about performance (mostly) because it helps them get things done. Think of it this way - Everyone loves Ruby on Rails. But Rails IS slow. But that doesn't mean I should re-write my code in just plain C, just because it is fast and Rails is no longer needed according to a bunch of bloggers. I think this argument is not about Jquery and is about frameworks in general. In my humble opinion, I think [1] $.ajax({ url: "test.html", context: document.body }).done(function() { $(this).addClass("done"); }); is better than: function ajaxFunction() { var ajaxRequest; // The variable that makes Ajax possible! try { // Opera 8.0+, Firefox, Safari ajaxRequest = new XMLHttpRequest(); } catch (e) { // Internet Explorer Browsers try { ajaxRequest = new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { try { ajaxRequest = new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) { // Something went wrong alert("Your browser broke!"); return false; } } } // Create a function that will receive data sent from the server ajaxRequest.onreadystatechange = function () { if (ajaxRequest.readyState == 4) { var ajaxDisplay = document.getElementById('ajaxDiv'); ajaxDisplay.innerHTML = ajaxRequest.responseText; } } var age = document.getElementById('age').value; var wpm = document.getElementById('wpm').value; var sex = document.getElementById('sex').value; var queryString = "?age=" + age + "&wpm=" + wpm + "&sex=" + sex; ajaxRequest.open("GET", "ajax-example.php" + queryString, true); ajaxRequest.send(null); } [1]http://www.tizag.com/ajaxTutorial/ajax-javascript.php http://www.tizag.com/ajaxTutorial/ajax-javascript.php

johnbender 14y ago
I agree with your general point about the value of abstractions, but jQuery is rarely the bottleneck where DOM manipulation is concerned. Most of the execution time in browser applications is spent rendering/reflowing content. It's only sane to use the DOM API once you've shown that the jQuery JavaScript execution is a significant portion of total execution time relative to reflows. An interesting side note here is that the Rails analogy remains somewhat apt, in that much of the execution time in web applications is spent in the data store.

ben336 14y ago

I felt like the article did a good job of explaining the potential replacements, but failed to make a convincing case for why the perfomance benefits outweigh the simplicity of jQuery. There's a conversation to be had about balancing those two, but this post makes the implicit assumption that performance is king and never really addresses the tradeoffs between performance and simplicity/familiarity.

evadne 14y ago
One of the many starters: http://www.greensock.com/jquery/ http://www.greensock.com/jquery/ (Enjoy.)
- dirtyaura 14y ago
  Wow, I've never heard of GSAP before but it looks really promising, if you want to have a detailed control of animations for your app. I'd love to hear both plusses and minuses from someone who is using it production code.
  - mddw 14y ago
    It's awesome, but only useful on very specific animation-heavy projects. Otherwise it's quite overkill.

ebbv 14y ago

This is hilariously wrong-headed. - If you use the standard jQuery hosted off Google's CDN, most users won't have to load it in the first place. So that overhead doesn't count. Only if you do some boneheaded thing like rolling your own version and hosting it on your server are you going to guarantee every visitor has to download jQuery. - Parsing jQuery is trivial for most modern browsers. If your web app has performance issues, it's not jQuery's fault, it's your fault. - querySelectorAll is not a replacement for jQuery. If you think it is you haven't been making good use of jQuery. This article seems like a post by someone who didn't even know how to do basic things against the DOM, finally learned how to do them and now thinks there's no use for jQuery. It's absurd. jQuery still has plenty of uses. I'm not saying you have to use it, or are making a mistake if you don't, but the assertion that it should be abandoned is ludicrous. Ugh.

slig 14y ago
> - If you use the standard jQuery hosted off Google's CDN, most users won't have to load it in the first place. So that overhead doesn't count. Only if you do some boneheaded thing like rolling your own version and hosting it on your server are you going to guarantee every visitor has to download jQuery. Well, it depends. [1] [1]: http://www.stevesouders.com/blog/2013/03/18/http-archive-jquery/ http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...
- SoftwareMaven 14y ago
  Those statistics weren't very helpful. It doesn't matter how many sites are using the CDN, it matters how may people visit those sites. If only 0.05% of sites used it, but 80% of people visited those sites, it would be worth using.
Offler 14y ago
I've found memory leaks in long running single pages apps that were down to jQuery UI components so I wouldn't dismiss jQuery performance doubts so quickly.
- ebbv 14y ago

hsmyers 14y ago

I fear the OP conflates his usage with the rest of the world. Had he presented it as more of a 'this works for me' I'd have paid more attention. My own usage involves things I don't even want to re-invent wheel or no.

varunkho 14y ago

Everything moves in cycle. Yesterday I started coding and found fragmentation to be the biggest issue so I thought I needed a framework to do anything reasonable. That issue got solved and I have got used to it. So today I am finding that performance is the issue. I again decide to dich the framework and start hacking it by hand. Tomorrow I find ... I focus more on tools rather than building things that matter in the end.

ashray 14y ago

You know what I love about jQuery ? It's readable. Every time I have to look at plain ol' javascript it feels like my eyes are going to bleed. Regardless of whether I wrote it myself or whether another developer wrote it. On the other hand, jQuery (still not the Miss World of programming languages..) is far easier on the eyes. Also, for most apps, the performance impact isn't all that noticeable since most of the performance hit happens due to reflows and not because of jQuery. Plus, the Google CDN jQuery is pretty well cached in most browsers.

beatgammit 14y ago
I don't think so, for example: var list = querySelectorAll(selector); var i; for (i = 0; i < list.length; i++) list[i].value = value; Is just as readable as: $(selector).val(value); Except that the jQuery example requires you to be familiar with jQuery. The first, however, just requires you to be familiar with a for loop, which is a common construct in many languages. Being faster is just a happy by-product. I, personally, am starting to use Dart instead, because it is a nice middleground between jQuery and raw DOM manipulation; it doesn't hide the details like jQuery does and it's still fast. Ihe best argument I can see is with XMLHttpRequest, which is still a pain because it doesn't have a nice API.
- jarcoal 14y ago
  Chain a few more commands onto that example and then we can talk about how readable the pure JS version is.
  - beatgammit 14y ago
    I've never liked chaining, and I hardly ever find a time when it's needed now: * animations: CSS3 * templating: I don't do it, I prefer static pages and toggle sections with classes * element filtering: better selectors (nth-child, nth-of-type, [data-stuff=''], etc) * form serialization: either use event handlers and build it as you go or just use regular browser form handling Currently, I use reqwest [1] for my HTTP requests. It's very small and is cross browser. In Dart, I just use the built-in libraries. [1] - https://github.com/ded/reqwest https://github.com/ded/reqwest

eknkc 14y ago

DOM manipulation and querying is a small subset of what jQuery does. There's ajax, event handling, dom creation from html fragments, animations, utility functions, size / position / offset calculators etc. And there are messy cross browser stuff in there. Yeah, let's get rid of it.

deleted 14y ago

[deleted]

mddw 14y ago

"I encourage you to give it a shot. Write your next application, library or just code for fun without jQuery. " Been there, done that. And it's a pain in the * You'll find yourself needing a method to add or remove classes eficiently. So you'll rewrite .addClass() and .removeClass() Then you'll need a clean way to make Ajax and callbacks. You'll rewrite .ajax() and .when() Then you'll need to fade something in all browser. So you'll rewrite .animate() Ad lib. JQuery Minified and GZipped is 35k (not 90 as the op said, ignoring the gziping.) JQuery is cached in most browsers. The performance hit is not worth the pain of re-inventing the wheel. The problem is not JQuery, it's bad code. Bad code won't magically disappear in vanilla JS.

neya 14y ago
Well said!
gildas 14y ago
> You'll find yourself needing a method to add or remove classes eficiently. So you'll rewrite .addClass() and .removeClass() You don't need to rewrite it, cf. this shim [1] for example. > Then you'll need a clean way to make Ajax and callbacks. You'll rewrite .ajax() and .when() They are plenty of good Ajax implementations, for example this one [2]. If you need promises, there are good libraries too [3]. > Then you'll need to fade something in all browser. So you'll rewrite .animate() Applying a fading effect on an element shouldn't be a mandatory feature. You can just use CSS3. [1] https://developer.mozilla.org/en-US/docs/DOM/element.classList https://developer.mozilla.org/en-US/docs/DOM/element.classLi... [2] http://jibbering.com/2002/4/httprequest.html http://jibbering.com/2002/4/httprequest.html [3] https://github.com/kriskowal/q https://github.com/kriskowal/q
- nasmorn 14y ago
  Client: I want this element to fade out. Me: No problem but only on browsers with CSS3 support. Client: What is CSS3? Me: Let me say it differently, it wont work on some browsers. Client: Why, is it hard to do? Me: Not really, but I would need to use an open source library to do it. Client: But don't you usually tell me that that's a good thing. Me: Yes but see yesterday I someone on the Internet said it should not be a mandatory feature. Client: You are fired.

wildgift 14y ago

JS performance isn't that important for most tiny apps. It's client side code and distributed. If JS performance were important, someone would write a jQuery -> js compiler and produced compiled js as output. But they don't do that, because once you benchmark the code, you find out that DOM is very slow, as johnbender mentioned. I'm still used to hacking in vanilla JS, but when I want to write something longer than a hundred lines, I load jQuery. It's the only sane tool to reduce code size. It does it in a pretty disciplined, lisp-y way, too. It's liberal use of the $(selector).f(x).g(y).h(z) style, which applies the function to the previous result, which is a collection, helps you code at a higher level of abstraction. No more loop structures! It's not time to sunset jQuery: it's time to put more support for jQuery style functions into ECMAScript, so you can get better performance though parallelization, lazy evaluation, etc.

mistercow 14y ago

I've seen a couple of people talking this way lately, and while we might be able to start talking about this in five years, the idea that after IE8 (or even IE9), we're past the point of needing a library to abstract away the differences between browsers is pure fantasy. As is the idea that now that we have querySelectorAll, the DOM suddenly isn't a complete nightmare of an API.

mvasilkov 14y ago

True, jQuery is still kind of nice niche tool for when you have to do lots of DOM manipulation, but it's no longer required. As an IE compatibility layer it did well, but I won't miss the $.unreadable($.mess()).

SeanDav 14y ago

Considering that the highest version of IE that Windows XP can support is IE 8 and the large number of XP machines still out there - it will be fairly silly to not support IE 8 for at least a couple more years.

tete 14y ago

jQuery is used a lot, because it describes a set of features and an interface that many other libraries build upon.

tete 14y ago

For people that worry about jQuery being to big, there is a lighter replacement for more modern browsers, doing (mostly) the same as jQuery: http://zeptojs.com/ http://zeptojs.com/

zalew 14y ago
if I understand correctly, the selling point of zeptojs is that it saves an enormous 20kb while breaking compatibility with half of everything out there?

eupharis 14y ago

Well, in the specific case of using native selectors (document.querySelector), I'm sold. It's supported very widely: http://dev.w3.org/2006/webapi/selectors-api-testsuite/level1-baseline-report.html http://dev.w3.org/2006/webapi/selectors-api-testsuite/level1... Wish I'd known about this before. I've been using $('#main').get(0) when I didn't want a jQuery object. Which is all kinds of silly.

camus 14y ago

So now say "death to jQuery" and it makes you look cool trendy right ? or what ? because saying "death to flash" is so 2010 ? I hope you test your code like in 5 desktop browsers with different versions + 4 mobile browers with different versions , what , you dont ? well jQuery devs do ... you dont care ? oh yeah your one of these mobile first , desktop last devs , then good luck with old versions of android browsers ... I'm always amused by all these "death to this" , "death to that" , like it gives anyone any credibility... So you get it folks , dont use jquery , reinvent the wheel like a true purist ,and remember to tell everyone "jQuery must die" , while professionals have code to ship.

cosmez 14y ago
so you're saying that just by using jquery i dont have to test on every possible browser version and mobile too? i dont know what kind of jquery i been using but i do that everyday.

mosselman 14y ago

Have fun doing things like $('div').animate({opacity: '0.4', left: '10px', background-color: '#44444'}); in native js. Of course you CAN do it... but do you want to?

gildas 14y ago
You're right, it's better to write it with a CSS3 transition.
- mosselman 14y ago
  True, +1 for the nativeness. But we are still a short bit away from being able to reliably use CSS3.
  - rjett0 14y ago
    That's IE's fault. CSS3 transitions really should've been in IE9.

sourc3 14y ago

The author's point is valid for selectors, but he is not considering the plethora of plug-ins that are built on top of jQuery and just work. Until browsers can support all of that, I think we are a LONG way from saying goodbye to jQuery. For all I know jQuery is saving me a ton of time when working on my prototype for the new side project. Last thing I want to do is to re-invent the wheel at my own expense :)

hcarvalhoalves 14y ago

jQuery exists because the native APIs available in browsers are not cross-compatible and suck at the same time. jQuery can be left alone once browsers revert the historical decision of just shipping a small core language.

conover 14y ago

Why not build a tool that takes in a set of JavaScript files, analyzes them, and outputs a stripped down, compressed version of jQuery with only the features used in the input?

cosmez 14y ago
thats the exact reason i used to love mootools, but too many companies demand for jquery even if they arent going to do any coding. before the library war started (prototype, jquery and mootools) i picked mootools for that exact reason, after so many lines written against that library i cant understand why jquery won in the end.

idan 14y ago

Not knowing the details of jQuery 2.0's cruft removal, I wonder how much the performance gap is closed by a jQuery that doesn't need to deal with Really Old Browsers™.

mmmelissa 14y ago

"first you need to make the assumption of a browser baseline. For me it is at least IE8, however that is quickly moving to IE 9 as most should upgrade to at least IE9, even stodgy old enterprises" BAD ASSUMPTION Just because they should doesnt mean they have or will anytime soon!!! Have fun convincing my "stodgy old enterprise" to upgrade to IE9. They JUST upgraded to IE8! Yes, ideally no one should be using these crappy old browsers, and I champion this idea and all of the reasons why at work all the time. Rational arguments dont work in the kool-aid world of government. (Does it need to be said that I am looking for a new job?) A lot of people browse the web from work, and so I dont think it is safe to ignore all of those crappy browsers yet.