jQuery considered harmful

Posted on by Lea Verou

Heh, I always wanted to do one of those “X considered harmful” posts*. 😀

Before I start, let me say that I think jQuery has helped tremendously to move the Web forward. It gave developers power to do things that were previously unthinkable, and pushed the browser manufacturers to implement these things natively (without jQuery we probably wouldn’t have document.querySelectorAll now). And jQuery is still needed for those that cannot depend on the goodies we have today and have to support relics of the past like IE8 or worse.

However, as much as I feel for these poor souls, they are the minority. There are tons of developers that don’t need to support old browsers with a tiny market share. And let’s not forget those who aren’t even Web professionals: Students and researchers not only don’t need to support old browsers, but can often get by just supporting a single browser! You would expect that everyone in academia would be having tons of fun using all the modern goodies of the Open Web Platform, right? And yet, I haven’t seen jQuery being so prominent anywhere else as much as it is in academia. Why? Because this is what they know, and they really don’t have the time or interest to follow the news on the Open Web Platform. They don’t know what they need jQuery for, so they just use jQuery anyway. However, being able to do these things natively now is not the only reason I’d rather avoid jQuery.

Yes, you probably don’t really need it…

I’m certainly not the first one to point out how much of jQuery usage is about things you can do natively, so I won’t spend time repeating what others have written. Just visit the following and dive in:

I will also not spend time talking about file size or how much faster native methods are. These have been talked about before. Today, I want to make a point that is not frequently talked about…

…but that’s not even the biggest reason not to use it today

To avoid extending the native element prototypes, jQuery uses its own wrapper objects. Extending native objects in the past was a huge no-no, not only due to potential collisions, but also due to memory leaks in old IE. So, what is returned when you run $("div") is not a reference to an element, or a NodeList, it’s a jQuery object. This means that a jQuery object has completely different methods available to it than a reference to a DOM element, an array with elements or any type of NodeList. However, these native objects come up all the time in real code — as much as jQuery tries to abstract them away, you always have to deal with them, even if it’s just wrapping them in $(). For example, the context when a callback is called via jQuery’s .bind() method is a reference to an HTML element, not a jQuery collection. Not to mention that often you use code from multiple sources — some of them assume jQuery, some don’t. Therefore, you always end up with code that mixes jQuery objects, native elements and NodeLists. And this is where the hell begins.

If the developer has followed a naming convention for which variables contain jQuery objects (prepending the variable names with a dollar sign is the common one I believe) and which contain native elements, this is less of a problem (humans often end up forgetting to follow such conventions, but let’s assume a perfect world here). However, in most cases no such convention is followed, which results in the code being incredibly hard to understand by anyone unfamiliar with it. Every edit entails a lot of trial and error now (“Oh, it’s not a jQuery object, I have to wrap it with $()!” or “Oh, it’s not an element, I have to use [0] to get an element!”). To avoid such confusion, developers making edits often end up wrapping anything in $() defensively, so throughout the code, the same variable will have gone through $() multiple times. For the same reason, it also becomes especially hard to refactor jQuery out of said code. You are essentially locked in.

Even if naming conventions have been followed, you can’t just deal only with jQuery objects. You often need to use a native DOM method or call a function from a script that doesn’t depend on jQuery. Soon, conversions to and from jQuery objects are all over the place, cluttering your code.

In addition, when you add code to said codebase, you usually end up wrapping every element or nodelist reference with $() as well, because you don’t know what input you’re getting. So, not only you’re locked in, but all future code you write for the same codebase is also locked in.

Get any random script with a jQuery dependency that you didn’t write yourself and try to refactor it so that it doesn’t need jQuery. I dare you. You will see that your main issue will not be how to convert the functionality to use native APIs, but understanding what the hell is going on.

A pragmatic path to JS nudity

Sure, many libraries today require jQuery, and like I recently tweeted, avoiding it entirely can feel like you’re some sort of digital vegan. However, this doesn’t mean you have to use it yourself. Libraries can always be replaced in the future, when good non-jQuery alternatives become available.

Also, most libraries are written in such a way that they do not require the $ variable to be aliased to jQuery. Just call jQuery.noConflict() to reclaim the $ variable and be able to assign it to whatever you see fit. For example, I often define these helper functions, inspired from the Command Line API:

// Returns first element that matches CSS selector {expr}.
// Querying can optionally be restricted to {container}’s descendants
function $(expr, container) {
	return typeof expr === "string"? (container || document).querySelector(expr) : expr || null;
}

// Returns all elements that match CSS selector {expr} as an array.
// Querying can optionally be restricted to {container}’s descendants
function $$(expr, container) {
	return [].slice.call((container || document).querySelectorAll(expr));
}

In addition, I think that having to type jQuery instead of $ every time you use it somehow makes you think twice about superfluously using it without really needing to, but I could be wrong :)

Also, if you actually like the jQuery API, but want to avoid the bloat, consider using Zepto.

* I thought it was brutally obvious that the title was tongue-in-cheek, but hey, it’s the Internet, and nothing is obvious. So there: The title is tongue-in-cheek and I’m very well aware of Eric’s classic essay against such titles.

  • rbrtsmith84

    You put some very good points forward Lea,what I find useful with jQuery (Aside from the DOM manipultion which you addressed) are the utility functions such as .map(), .each() and so on. But I guess we can use underscore or lodash as a replacement. However what I find most useful with jQuery are the AJAX helpers. Maybe it’s improved in recent browsers. What would you recommend we use for cross-browser AJAX, a particular utility or write our own? Thanks.

    • http://lea.verou.me/ Lea Verou

      Nope, you can use Array#map and Array#forEach. There’s a bunch of ES5+ array methods that are relatively unknown and cover all these gaps.
      Did you look at the first website I linked to? There are several AJAX examples too.

      • http://jonathan.garbee.me/ Jonathan Garbee

        One problem with forEach I hit the other day… Doesn’t work on NodeLists. So I had found a function that just abstracted a while loop to go over them. Array’s and NodeLists should probably become more aligned in the future.

        • http://lea.verou.me/ Lea Verou

          Just convert the NodeList to an array by using [].slice.call(nodelist); (or just make a function for this, cause I agree it’s horrible ugly syntax. Array generics will fix this, but still not supported in Chrome :( )

        • http://jonathan.garbee.me/ Jonathan Garbee

          ah, I read an article about that method. All it mentioned was “not cross-browser method”. Looks like after some deeper searching that was only due to IE8 support… yea. I’ll probably switch around to doing this then since it is much cleaner.

      • rbrtsmith84

        Please correct me if I am wrong, but the native forEach and map don’t work on objects, unlike the versions from jQuery/Underscore? I will check out the website you have linked too. Thanks for your response Lea.

    • http://twitter.com/teddyzetterlund Teddy Zetterlund

      You should use Fetch and Promises. They’re already implemented in Google Chrome Canary and Firefox Developer Edition. GitHub maintains a polyfill: https://github.com/github/fetch

      • Arthur Stolyar

        Hah, you really should not. XHR is enough and fetch is not even in alpha state. For example, you cannot cancel fetch request, etc. Promises also is not a panacea for all and should not be used for all, however, it might be used in some places.

    • lozandier

      That’s a good perspective to share since it’s fairly common. In modern browsers, you can write trivial equivalents of jQuery’s AJAX functions from scratch, but your mileage *will* vary when it comes to IE8 & IE9.

      This is particularly true when it comes to CORS-related AJAX calls. IE has something else called XDomainRequest to consider for CORS requests and the source of pain for developers that must consider CORS with their asynchronous calls to get data from other places on the web beyond their site.

      That’s what made jQuery AJAX helpers even more well loved I’d imagine besides its intuitive API that hid all the details of having to deal w/ XDomainRequest & XMLHttpRequest.

      I’d be amiss to not mention jQuery’s handling of JSONP which is ideal for devs who need to deal with that & the two obejcts I mentioned.

      Regarding existing libraries, until Lea Verou replies to you about that, definitely check out the fetch polyfill ( https://github.com/github/fetch ). Even though it’s *highly* likely Promises will be replaced with something like an Observable to make it easier for requests to be canceled & traversable, I recommend the fetch polyfill.

  • Pingback: 1p – JQuery considered harmful | Profit Goals

  • Pingback: 1p – JQuery considered harmful | Exploding Ads

  • Pingback: RT @LeaVerou: New blog post: jQuery considered har... | visaap.nl

  • http://michal.paluchowski.com/ Michał Paluchowski

    I think the best group to address this issue are the folks behind jQuery. If you read the intro on jquery.com, they still position the library as something that makes a developer’s life easier, particularly when working with different browsers. Which as you wrote was correct a few years ago, but nowadays is dated.

    They could and should rewrite that portion to say that jQuery is still valid when supporting older browsers, but for newer ones plain vanilla JavaScript will often be better.

    When coding larger applications there’s still a lot of scaffolding and supporting code that’s helpful to rely on some ready framework for, but even in this case we have a number of more comprehensive alternatives these days, which also allow the core code to stay relatively independent from the framework used—where, as Uncle Bob likes to say, the framework used becomes a detail.

  • http://sampotts.me Sam Potts

    For me it’s the plugins. I’d move away from it if it wasn’t for having to rewrite external plugins that depend on jQuery. Also, that and IE9 numbers. Everything remotely useful in vanilla JS seems to be IE10+ or you need a polyfill which I guess is not the end of the world but something to consider.

    I recently wrote a media player (http://plyr.io) in vanilla JS and it was pretty refreshing working without jQuery but again because IE9 doesn’t support the element (without your polyfill) or I’ve not bothered with IE9 support on that.

    I’m looking forward to IE9’s death now. Previously it was IE6 :)

    • Dino

      Version 8 of IE is important to support because it’s the last version available on XP and it’s the version that comes with Windows 7. IE users who cannot upgrade OS and those who don’t upgrade their browsers are still using IE8

      On the other hand version 9 is one that users had to install themselves; if they can install IE9, they can install IE10 or IE11; they had 3 years to upgrade.

      If you can drop support for IE8, you might as well drop support for IE9 too.

      • http://sampotts.me Sam Potts

        All very well in theory but if your users are still using IE9, you’d be a fool not to support it.

        • http://lea.verou.me/ Lea Verou

          In the case of plyr, how do you have this information? Your users are essentially the users of the websites this is installed on, so you can only gauge based on global statistics. According to StatCounter, IE9 is 2.92%, lower than IE8, which is 4.65%.
          Personally, I try to support IE9 if it’s not too much effort, but I won’t burst a kidney over it.

        • http://sampotts.me Sam Potts

          With plyr, I checked the global stats and weighed it up vs implementing the necessary polyfills (or checking for their presence) for those two elements and decided it wasn’t worth the effort. I’ve not had anyone complaining about supporting the older browsers. That said I’ve been pretty clear that it’s just for modern browsers and the whole point was to keep it lightweight as a wrapper around the native functionality (no flash etc).

          I use Evaporate JS for AWS CORS uploads here at work and that only supports IE10 also due to no file api in IE9.

        • http://lea.verou.me/ Lea Verou

          Yes, exactly, that’s pretty much what I do too. Check stats and counterbalance it with extra effort/weight. Development includes a lot of tradeoffs and decisions, and it frustrates me how many people are trying to pass blanket statements as suitable for every project.

    • Nikki Strømsnes

      IE8 was the last version of Explorer without auto-update. Users that have Windows 7 or newer have Explorer automatically update with the OS. That means, that the IE9 numbers are really low (much lower than IE8!).

      There is no reason to support IE9.

      • http://sampotts.me Sam Potts

        There is a big reason to support IE9; if you’re users are using it, as shown by stats. Corporate users are the main problem when it comes to old versions, often being stuck on a version for years and no control to upgrade. I’ve been on the other end of it, I was stuck on IE6 for years :(

    • http://lea.verou.me/ Lea Verou

      That media player looks slick! Thumbs up!

      • http://sampotts.me Sam Potts

        Cheers Lea! Let me know if you think of any ideas/suggestions :)

  • MaxArt

    I’ve *always* considered jQuery “harmful”, especially when *learning* Javascript. Newbies don’t learn what’s beneath it, the strong and weak points, what jQuery implies in terms of performances and code organization. They just use it.

    The point is that, for industry projects jQuery *just works*, because it fixes browers’ descrepancies, reduces development time – in the near term, at least – and sets a common framework to work with among team mates. Those are *huge* advantages.
    CSS frameworks like Bootstrap are built on top of jQuery.
    And don’t get me wrong, I’ve used and still use jQuery with satisfaction. jQuery will live a long life still, and for many it’s better so.

    But we’re indeed approaching to an era when jQuery feels less necessary, and you’re right to point it out. User agents try to adhere to standards as much as possible. New full-front frameworks like Angular replaces some of jQuery’s most appreciated features, and we’re moving towards new development methods.
    Web components, modules, packages is what new developers are looking for nowadays. Can’t blame them.

    • Adam

      *fascinating*

      • Rj

        You added *nothing* to the conversion.

        Better luck next time, Adam.

        • ntstatic

          maybe he was adding sarcasm !

  • Mike

    I think this highlights the problem with jQuery 2.0 and its ditching of older IEs. jQuery is IMHO only needed to (better) support those, esp. IE8 which does not even has addEventListener.
    But it is certainly not needed if you support modern browsers only.
    So I think jQuery 2.0 is an anachronism in itself and should not be there at all.

    BUT – the notion of “support a single browser only” is a very dangerous path, sadly being done a lot these days. And worse not by using defined standards but again (like in the old days) by using proprietary stuff esp with Chrome/Webkit/Blink only sites. That is exactly how we ended up with IE6 living that long but younger developers do the same crazy thing again.
    Even and maybe especially in academics people should not do “works in Webkit only” (or “works only on iOS”) when doing webwork. This is NOT the web as the environment may change soon again (maybe with another browser coming up or whatever) and than again we have to cope with proprietary but longliving sh*t again.

  • boutell

    Things I come back to jquery for:

    Functional programming without an opinionated MVC framework attached.

    ui autocomplete, which is keyboard accessible and flexible.

    ui datepicker, same reasons.

    ui sortable.

    And yes, IE8. One percent is millions of people. Including a lot of corporate installs. We can’t tell our clients they can’t talk to their customers just because their browsers are icky.

    • http://lea.verou.me/ Lea Verou

      UI autocomplete: http://leaverou.github.io/awesomplete

      UI sortable: I recently used https://github.com/RubaXa/Sortable and it was fantastic.

      UI datepicker: with a polyfill

      jQuery offers no more functional programming capabilities than plain JavaScript. If you disagree, I dare you to give me specific examples :)

      Regarding IE8, I myself said that if you need to support IE8 jQuery can be immensely helpful, so not sure what your argument is. Are you claiming that everybody should support IE8 because you have to? Um, sorry bro, some people really don‘t have to, for a variety of reasons. E.g. sites targeting developers have negligible IE8 numbers.

      • qwdwqdwqdwqd

        Sorry, but UI autocomplete is almost unusable on my android phone. If i click inside the field the magnifiying overlay opens and blocks the suggestions. I also have to zoom a ot into the page in order to have a readable font size and big enough links for touch.

        Fail.

        • http://lea.verou.me/ Lea Verou

          LOL, I love your logic. “There’s a bug in this on Android, so it’s a piece of crap.” How about being helpful instead of sounding like a sour old fart, and reporting the bug? Here you go: https://github.com/LeaVerou/awesomplete/issues
          There are many lovely contributors that might have time to fix it, even though I currently don’t.

        • Guest

          Wow, you are one of the rudest front end developers I have ever encountered in the open source community, Lea. It really is a shame, because I respect your work. I presume I’m not the only one who’s slowly losing respect for the way you respond to people who comment on your blog. Belittling people and being defensive seems to have become more frequent with you. I don’t understand why you have to be this way most of the time. Not everyone is as talented and brilliant as you are and you can’t seem to want us to forget that! Pity..

        • http://lea.verou.me/ Lea Verou

          At least I say what I have to say with my name instead of being a coward.

        • Guest

          I rest my case :)

        • Guest

          Perhaps one day, Lea, you will realize that humility and compassion are as important as the tremendous skill and talent that you have :)

        • http://lea.verou.me/ Lea Verou

          If someone is rude to me, they can expect that I will be rude to them and I have zero remorse about it, nor do I think that it demonstrates a lack of humility. Perhaps you need to look up what humility means. In addition, I tend to not take criticism seriously from people who do not exhibit the basic decency to stand behind their opinion, without hiding behind anonymity, like I always have done. If I had followed your own example and posted the comment you responded to anonymously, we wouldn’t even be having this discussion and you would think I’m the nicest person ever. It’s super easy to be liked by everyone when you only selectively post under your name, isn’t it?

  • Esteban

    I think you make a bunch of great points and I agree with basically everything you’ve said in this article, but I’m really disappointed with the title. Maybe this is just a personal thing on my part, or maybe you *are* making fun of it based on the first sentence of this article, but perpetuating the “X considered harmful” thing is just miserable in my opinion because while you are absolutely in a position to make this argument given your skills and reputation in the community, and you make many more or less objective points here, to say that something is “considered harmful” just comes off like you’re deciding this for everyone rather than this being an opinion/rant. It comes off as though you and a group of others have done a ton of research as if you’re doctors researching smoking, when in fact that’s not the case at all. Again, you make a lot of great points that can probably be backed up, but the title ruins them because it almost implies that you solely get to make the decision of what’s objectively “harmful.”

    • http://lea.verou.me/ Lea Verou

      “When the wise man points at the Moon, only the idiot looks at the finger.”

      (and yes, it was tongue-in-cheek)

      • Guest

        Disappointing to see you call one of your followers an idiot for a completely valid point.

        “If one person calls you a donkey, ignore them. If two people call you a donkey, think about it. If three people call you a donkey, buy a saddle”

        • http://lea.verou.me/ Lea Verou

          I did not call you an idiot, I quoted Confucius. :)

      • Esteban

        Actually Guest below was not me, the one who posted the original comment. I can understand that you think it’s dumb that I focused on the title, but I thought I was pretty clear that I thought the content itself was solid. I was just trying to make the point that in my opinion, these “X considered harmful” titles are really problematic in our field and can set some readers up either to be belligerent w/o even reading the content or to mindlessly and wholly accept the content w/o thinking for themselves, especially when it’s written by someone as well-respected as you. I was just frustrated to see someone I really respect (not that you do or should care about that) write one of them (and obviously you’re free to write whatever you want).

        I’m glad to hear it was tongue-in-cheek though.

  • drhowarddrfine

    “… jQuery is still needed for those that cannot depend on the goodies we have today and have to support relics of the past like IE8 or worse.”

    I hate these implications that jQuery can do things no one else can on their own. It makes noobs feel jQuery has magic fairy dust unattainable by mere mortals. Please don’t write like that.

    • Peter

      Well then you probably have much time to deal with those solutions in your company. Working for big institutional clients wont allow me to do this because we got enough work with structuring, styling and optimizing for different devices. And yes we got some clients with shitty browsers (IE8 / IE9) which are not willing/allowed to switch because of their “high security restrictions” lol. Quick & dirty jQuery fixes is what those folks deserve :)

    • http://lea.verou.me/ Lea Verou

      Haha, this is funny. I get shit both from people using jQuery AND from people not using it now. This implication is in your head, I never implied that jQuery has magic fairy dust or anything. Just that in those cases, it’s convenient enough for someone to ignore its drawbacks.

  • Jiří Petruželka

    I would dare to disagree – at least from a standpoint of not-completely-hardcore-frontendist.

    Even the basic articles saying we don’t need jQuery then have to list exceptions and version restrictions and alternatives in its snippets. One of the fundamental reasons for jQuery is IMHO lowering the necessary knowledge for differences across browsers, various quirks and bugs.

    Another reason is much simpler and more intuitive API. The linked webpage http://youmightnotneedjquery.com ironically shows how much better jQuery’s API is, and I haven’t even checked if the native codes are actually cross-browser and cover all that jQuery does. If I should choose between making one Ajax call with 1 line or with 10 lines each time (if I use even their simple example), it’s a no-brainer for me.

    Then there are some useful functions which you then do not need to supply from elsewhere. You may not want them, but they often come handy. I acknowledge the jQuery’s downsides, but I still don’t see working without any middle-layer as viable. Maybe at some point in future.

    • Augustus Yuan

      It’s true what she says in regards to academia though — I know a lot of teachers blaze through JavaScript and jump straight into jQuery because it’s easier to teach. However, this ends up leading to students not really understanding how JavaScript works in general and being heavily reliant on jQuery.

      • Jiří Petruželka

        Indeed, I agree with that. I would also add that using jQuery should not prevent one from keeping up with the new features that new versions of JS bring.

        • Robert Jackson

          I would use new features if they were properly supported. I cant wait for the day when HTML5, CSS3 and EMCA6 are implemented fully and properly. Other than that I dont even waste my time reading about new things, why waste time on things that are not fully supported? Then we get mobile device browsers thrown into the mix and it is 1994 all F***ing over again.

    • http://lea.verou.me/ Lea Verou

      I did list exceptions: I said if you need to support older browsers, then I totally get it.

      Regarding browser quirks and bugs, that’s the point we’re all making: That modern browsers don’t really have many in the kind of basic DOM handling that jQuery helps with.

      Regarding sites like youmightnotneedjquery, they show how to do things with the native methods, but that doesn’t mean you can’t make your own tiny wrapper functions around them. Arguing that not using jQuery means not using any abstraction at all is textbook strawman fallacy.

      In fact, I’ve been pondering lately to clean up & release my own set of tiny abstractions that have saved me from the need to use jQuery in many projects. :)

      • Jiří Petruželka

        Please notice I did mention a middle layer in general, so not necessarily jQuery.
        Also such websites suggest that it’s ok to write in pure JS (some more explicitely than others, e.g. VanillaJS), so sidestepping and saying that we would not use jQuery (hurray!) but another-abstraction-that-does-what-jQuery-does instead and call it a revolution in not-using-jQuery makes little sense.

        If I were to make my own, I wonder how much it would end up as jQuery in time anyway, which also has the benefit of being massively tested by countless users through a long time. Of course if there’s a lighter and faster alternative then why not consider that (Zepto maybe? Is it still alive?). Or our own and do everything from scratch, perhaphs for a very performance heavy site or if one really hates the wrapping objects…

        • http://lea.verou.me/ Lea Verou

          My reply to Sven above applies here too. jQuery is way more than what I’m describing. I’m saying that you don’t need a chainsaw to cut a slice of bread and you guys are replying “So you’re against using knives???”

      • Sven Slootweg

        > Regarding sites like youmightnotneedjquery, they show how to do things with the native methods, but that doesn’t mean you can’t make your own tiny wrapper functions around them. Arguing that not using jQuery means not using any abstraction at all is textbook strawman fallacy.

        So how is reimplementing that functionality any better than using an already existing known-good abstraction?

        • http://lea.verou.me/ Lea Verou

          So to you, a few tiny functions is the same as tens of thousands of lines of code because both are an abstraction? Logic fail.

        • Sven Slootweg

          No, and I’m not really sure where the hostility is coming from.

          The reality is that you’re going to need abstractions, and that rolling your own is very unlikely to have as much “browser and edgecase coverage” as the jQuery version does.

          At that point, the only difference is the size of the library -and while I would be very happy with a more modular distribution of jQuery, I haven’t seen a compelling argument as to why the library size even *matters*. We’re talking about tens of kilobytes here.

          If you’re developing embeddables – widgets, ads, analytics, whatever – then I can see an argument for reducing library size. But for web development in general? Absolutely not, it’s premature optimization at best.

          EDIT: And in my original post that you replied to, I specifically asked “how”. That was an actual question. No snark is required to answer it.

        • Keith Humm

          I agree with Sven here – even at a scale of 10:1 in terms of code size (jQuery vs homegrown), the advantages of having a stable support base in jQuery outweigh any advantages you get from rolling your own functions.

          If you don’t need to use jQuery for its browser normalisation (which I would still argue is actually a current, persistent issue for most developers, especially those that need to target mobile platforms – Android 2.3 is a popular, prime example), you can use something much slimmer like Zepto.

          Both of which are infinitely better for both yourself, and anyone you might happen to hand your code on to, than Yet Another Homegrown Alternative.

        • http://lea.verou.me/ Lea Verou

          At scale of 10:1 I would definitely agree! The real scale however is more like 100:1.
          And yes, Zepto is a nice alternative for those who actually like the jQuery API. Personally, I don’t, for the reasons I described in the article.
          IMO there is a benefit to the homegrown alternative, when it’s really small. If you find yourself adding and adding stuff to it, then sure, switch to an established library. With experience, you can tell if you will get past that threshold before you even start coding something. I wouldn’t advise anyone to maintain 500+ lines of homegrown DOM helpers!!! But if it’s < 100 sloc, I do see a benefit in code you’re familiar with, over using a well-maintained black box. (numbers of sloc are not based on anything precise — just wanted to avoid vague terms like “small” and “large”)

        • Keith Humm

          Ultimately it’s a design call one way or another I guess. One thing I certainly would never advocate is using native APIs without some sort of abstraction, which is what some of the proposed linked sites do.

          100 lines of homegrown code (assuming not-too-complex “lines” :), and no scope for long term codebase growth and you’re probably going to be fine. KISS, and you can even proxy through your homegrown lib into jQuery/Zepto/Whatever.js when you grow.

          But I’ve seen all too many cases where homegrown libraries get baked in hard, with heavy coupling.

          I think it’s a good discussion to have, and anyone who immediately just pulls in jQuery/Zepto/whatever.js as a baseline should think twice about their needs before doing so, but IMO we are still a long, long way from jQ being anything but a net negative in most situations.

        • Robert Jackson

          I took a hybrid approach for http://www.enterfan.com due to the many plugins I used to save time, like the calender, accordion and some others. I still created my own objects to create a Dialog box, an overlay, character counter etc. each uses jQuery inside to make my code 100 times easier.

          But the F***ing bloat man, even compressed jQuery and its UI code are MASSIVE 284,182 kb and 469,790 kb and some of the UI plugins are very invasive and destructive to the DOM and some Explode the size of the DOM adding crap all over, before you know it your page is run amuck and you are playing Who done it.

          In the world of Web Development you can’t win, especially if you have to support desktop and mobile browsers. I want to kill mobile browser makers.

        • https://github.com/kupriyanenko Alexey Kupriyanenko

          If you like jQuery API, maybe better solution for modern browsers is jBone, it has much better performance then jQuery/Zepto, smaller size and pushes you to use native APIs as much as possible.

          @LeaVerou:disqus what do you think about alternatives like this instead of jQuery/Zepto?

        • http://lea.verou.me/ Lea Verou

          I have no opinion about jBone as I have never heard about it before. If it’s like you describe, then sure, it’s probably better! :)

        • Robert Jackson

          Dont worry 5 more JS API’s will come out next week, all claiming to fix something or be better somehow.

        • Robert Jackson

          A new damn API is born every single day. I do not jump to the newest, latest, greatest and most likely to be not supported API junk.

        • Robert Jackson

          Rolling your own means doing thousands of hours or research and scratching your head and saying WTF??? And digging and googling and wondering WTF???

          Also jquery is 284,182Kb and the UI is 469,790Kb add your sites code size to that. Even with compression I the file is quite large. The larger the file the longer it takes to download.

        • Robert Jackson

          The best JS book I have found is “Professional Javascript for web developers by Nicholas C. Zakas” He digs deep into JS and Browsers.

        • Robert Jackson

          So how is reimplementing that functionality any better than using an already existing known-good abstraction

          Code bloat. It worries me. jQuery plus all the UI is a ton of code. I use it because I need quick development and to not worry about browser quirks . I am not sure what is better including jQuery from Google CDN or minifying and compressing it into my own code.

          I saw that it was taking a long time for Google CDN to respond compared to compiling jQuery with my own JS. The results of minifying with jQuery suck too, it makes a huge file, plus i found another issue the different UI scripts refer to different CSS files and images, and before you know it you have to start digging into code to see what the hell is going on.

          I like to minify my code and put it on my own CDN.

          It is nearly impossible to choose only the UI parts you need since so many rely on each other.

          The worst thing in the world about Web Development are the CONSTANT, NEVER ENDING BS INCONSISTENCIES EVERYWHERE.

          I am surprised I have not punched my monitor after all these years, the old ones were super hard though. LOL

        • Sven Slootweg

          I wouldn’t generally recommend jQuery UI (and, for all practical purposes, it’s an entirely separate library). It’s very messy, very hard to style, way too bloated for what it does, and very hard to integrate with the rest of an application.

          jQuery is a different story entirely. Especially with the 2.x branch, it’s of an entirely reasonable size for what it does.

        • Robert Jackson

          Yeah, but one thing I have to do is use it now to save time, then go back later and roll my own. My website has no traffic anyways. It will be launched next year.

          But god YOU ARE CORRECT the UI is HORRIBLE, way bloated, way invasive and way to coupled.

        • Robert Jackson

          I mean like now I am looking to add a suggestive text feature. I will have to decide do I want to use the jQuery UI or do I want to roll my own? I am sure I can easily roll my own and was planning to, but i have to do reading first and trials.

          I hate Javascript and CSS but I have no option but to use it. LOL

        • Sven Slootweg

          Perhaps have a look at https://twitter.github.io/typeahead.js/? It should be sufficiently customizable that it doesn’t become a jQuery UI.

        • Robert Jackson

          Not sure what that link was supposed to lead to? What I mean by suggestive text is that text list you see as you type something into google search. Basically all a script would need to do is use Ajax and send a string to a PHP server side script, which then creates an SQL statement using LIKE keyword, then have it send the results back.

          My worry is how slow it would be, bandwidth back and fourth and use of System resources. Imagine an SQL statement searching a table with 1,000,000+ rows while searching for text in a 45 varchar column.

          I plan on moving most of the website to NoSql in the future, actually a hybrid form of NoSql and MySql.

        • Sven Slootweg

          Yeah. Typeahead is a library that should let you do that – if I recall correctly, you can make it use AJAX as well. It’s also a lot easier to integrate (visually) than jQuery UI’s stuff.

          “NoSQL” is a bit of a stupid buzzword, frankly – the only thing it tells you is that it isn’t SQL, which in and of itself isn’t a useful datapoint, because SQL is *just a language*. You might be thinking of document stores, or schemaless databases, various other things, or any combination of the aforementioned.

          If you’re thinking of schemaless document stores like MongoDB, then you probably shouldn’t bother. Aside from the technical issues with MongoDB specifically (http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/ ), both schemaless storage and document storage just aren’t suitable to most applications.

          There *are* some cases where you may need a document store or schemaless storage. For everything else, PostgreSQL is a good choice. And even schemaless storage is something that PostgreSQL can do (through its JSON/JSONB column types).

          If you’re concerned about performance, then *definitely* don’t bother. It’s extremely unlikely that any ‘real’ database is going to outperform PostgreSQL, whether “NoSQL” or not. What you want is a cacheing and/or full-text indexing/search layer, and those are typically provided by separate tools (eg. Redis for cacheing, Sphinx for indexing, …)

      • Brian Mock

        > In fact, I’ve been pondering lately to clean up & release my own
        set of tiny abstractions that have saved me from the need to use jQuery in many projects. :)

        That would be cool to see!

      • Robert Jackson

        What if you need to support mobile browsers and regular ones too? I have not seen anyone talk much about that. Mobile device browsers added into the mix make Web Development seem like the 90’s again. I hate browsers, which is why I hate CSS, HTML and Javascript, I hate inconsistencies and browsers are the most inconsistent thing on the planet.

        One problem with trying to support mobile browsers is many people are still using and buying older phones with old browsers. The device makers changed so much over such a short time it is insane.

        I like the ease of jQuery so I don’t have to worry and do not have to reinvent the wheel over and over, slowly discovering all the browser quirks etc. I still find myself looking up support for “xyz” often though, mostly for CSS.

    • Robert Jackson

      I am starting to veer away from jQuery because it totally screws my DOM up, some plugins are VERY invasive to CSS adding classes willy nilly, restructuring the DOM, it adds stupid bugs. I spent a large part of the other day “Working around” the Accordian plugin. I had to dig into the CSS file and play around to figure out what the “custom template” css was doing, I also had to adjust my CSS and even how I wanted things to look due to the invasiveness of the UI plugins. That is when I discovered it was jacking up my DOM.
      jQuery is handy for many things and I have used it extensively on https://www.enterfan.com however I have a growing hate for 3rd party code the more I use 3rd party code. Random bugs, slow loading due to including API’s from all over, but having to write all the code and reinvent the wheel for each little thing I need is not an option so I deal with things. Lazy loading etc.

      I have created my own API for things like Creating dialogs, overlays, loading status, character counters etc. However many use jQuery. I am creating some objects now for fetching object sizes and locations and placing elements over elements.

      I looked at contributing my code to some jQuery plugins, however it would take me entirely too long to go through and redo my code and restructure everything to jQuery standards espcially documenting and commenting. I highly prefer having documentation comments directly in my code, it makes it easier to know what is happening later, so I’ll just keep my code to myself. LOL Plus I have entirely too much to do on my website.

  • http://joottle.com Starkadh

    But there is a jQuery into this page 😉

    • http://lea.verou.me/ Lea Verou

      Heh, good point! There are a lot of things on this page I’m not proud of — just no time to recode/redesign it. I believe jQuery was automatically included by WordPress though. If not WP, by some WP plugin.

      • http://joottle.com Starkadh

        Yep, or maybe by Disqus himself. not a time to check too :)

  • Sven Slootweg

    > Every edit entails a lot of trial and error now (“Oh, it’s not a jQuery object, I have to wrap it with $()!” or “Oh, it’s not an element, I have to use [0] to get an element!”).

    It really doesn’t. You can safely ‘normalize’ elements by *always* wrapping them in a $() at the start of a function. $-ing an already $-ified element doesn’t change anything, and is safe to do.

    EDIT: An example: $($(“div”)) is perfectly valid.

    • http://lea.verou.me/ Lea Verou

      This is exactly what I’m saying, that to be safe you end up wrapping everything with $(), essentially causing MORE lock-in. I.e. it’s difficult to just use jQuery in specific isolated parts of your code, it spreads like a plague.

      Also, re:extending native objects, my point was that in the past there were more reasons than potential collisions (also, on that matter, see my blog post posted today)

  • http://hellofellow.com David Heidrich

    I totally agree, the only thing that I experienced with my latest (bigger) project (http://bowlingx.github.io/flexcss/, totally $-Free components) is that you build your own micro utilities and wrappers for things like parents(selector), custom-event handling, promises and/or need to checkout the right polyfills to support the experimental stuff (https://cdn.polyfill.io/v1/docs/ helped me for a nice user-agent-based polyfill).

  • Ult_Combo

    jQuery = nice API.

    People would use the DOM APIs more if they didn’t suck so much. I dare you to iterate over a NodeList and not feel bad afterwards.

    Many of your points about complexity, organization and good/bad practices apply to pretty much all JavaScript libraries and frameworks — do you also mean to say we shouldn’t use abstractions such as React, Angular, Durandal, Aurelia, Knockout, Backbone, Ember etc. because “humans forget to follow conventions” and “don’t know what they need library X for”?

    Story time: last month, my company was working on a web interface targeting only the latest browsers, hence I thought “Hey, let’s use more of the awesome Web Platform!”. Guess what? It came back from QA because IE11 does not support the `selectedOptions` property of the `HTMLSelectElement` interface. Would not have happened if I had used `$(‘select option:selected’)` from the start.

    I agree with your point of abstractions getting in the way of people experimenting with the new Open Web Platform goodness, but jQuery is only the tip of the iceberg. jQuery provides a tiny layer of abstractions that still leaves you in control to make use of the native Web Platform, the same cannot be said about many other libraries and frameworks.

    Also, don’t get me wrong, but I would recommend avoiding “considered harmful” titles. IMHO, articles which use that title pattern instantly lose all credibility, or in other words, it just demonstrates the author is lazy to come up with a good title and is butthurt about something (note: this is just my generalized opinion about this title pattern). Also see ““Considered Harmful” Essays Considered Harmful” http://meyerweb.com/eric/comment/chech.html

    But yes, even then, I still dragged myself to read the entire article because you are a respectable Web Platform member and writer.

    • http://www.voyagers.io Greg Bowen

      this. Libraries serve an important role. Yes, you should know how to write raw JavaScript, but unless you are writing an online paint program, or other intensive app, frameworks are more than helpful, they are part of the webs DNA for a reason.

    • http://lea.verou.me/ Lea Verou

      Re:iterating over a NodeList, you can use Array generics and just do: Array.forEach(nodelist, function(node) { … })
      (sure, Array generics aren’t yet available everywhere, you can use a polyfill)

      Abstractions like Angular, React and the like are mainly for large projects. I wouldn’t argue using vanilla JS for those. My point is that in small client projects or in academia (research prototypes and class projects), jQuery is superfluous and the added complexity does not outweigh the benefits.
      When a project is large enough to warrant using a framework, then sure, there is added complexity, but the benefits it gives you outweigh it. It’s a tradeoff.

      • Ult_Combo

        Fair point, array generics are an elegant solution and easy to polyfill. The only issue is that they are not part of any standard (yet). Well, in ECMAScript 2015 (ES6) we can use Array.from (which can also be easily polyfilled):


        Array.from(nodelist).forEach(function(node) { ... })

        Thanks for the explanation, now I see your point more clearly. I fully agree that if you are working on a very small project or learning, then you most likely needn’t jQuery.

        One issue, though, is when the project starts to grow and the developer spends too much time writing abstractions that already exist. Reinventing the wheel is usually a waste of time — unless you’re in a learning environment, then it is great to really get the grasp of what is going on in those abstractions.

        Another point, as already commented somewhere in this thread, is that jQuery is so ubiquitous in the industry. If you completely ignore jQuery while learning, then you will be a bit lost when you join the industry. But I agree jQuery is not a replacement for the native Web Platform (all abstractions leak, and jQuery is no exception). Balance is good.

        About the title, I was mostly sure you already knew it, it is just that those titles really, really get on my nerves. Sorry for the nuisance.

        • lozandier

          I wonder if Lea & I have been referring to the same thing when it comes to Array generics (something I never heard about) & iterables

          In ES6, NodeLists as well as other collection objects have an iterator defined through Symbols (Symbol.iterator or @@itreator) that allows them to be traversed by a variety of methods we as devs are probably familiar with in addition to new ways of traversing collections such as a for…of loop.

          This is because, by having an @@iterator defined, such objects are seen as being as an *iteratable*. This is duck-typing: “If it walks like a duck, and quacks like a duck, as far as I care it’s a duck”.

          If an object has a @@iterator defined (a generator or a special thing like a generator, I don’t remember how it’s specified in ES6/ES7), it’s a consumable object by methods that iteratively walk an object.

          In the case of a primitive such as a String, the temporary primitive object that is created whenever we want to call a method on a string but is immediately disposed of now has a @@iterator defined.

          This also allows us to create our own objects and define what things within that object to yield to whatever method that wants to iteratively traverse a collection that includes that object (or itself) at any time.

        • http://lea.verou.me/ Lea Verou

          Array generics: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array and search for “generics”. Hadn’t realized they were non-standard tho. Shame.

        • lozandier

          Hmm, thanks for really quick reply! From what I’ve read of it so far, it seems to overlaps with the purpose of @@iterator and the concepts of a iterable in ES6 & its potential low level refinement in ES7…

  • le717

    First off, very good post. Enjoyed it, and you make some good points. :)

    I’ve been using jQuery less lately (especially in homework, AFAIK my college has never taught jQuery) in favor of native methods. While I’ve mostly enjoy it, there’s always something that makes me want to load jQuery even though I don’t really need it. Usually, it is

    * Event handling (.on() and .off() just seem more elegant than .addEventListener() and .removeEventListener())
    * Class manipulation. I know the classList methods exist, but as I usually have very basic support for IE9, I stay away from them until I can safely switch to classList.
    * Animations tricky to duplicate in CSS (`$(“html, body”).animate({scrollTop: 0}, 500);`, anyone?)
    * Larger projects. When I have lots of DOM elements or code to manage, I prefer jQuery. I probably won’t load jQuery for the first two points, but I almost always will for this. I feel it just helps my development progress more than native methods, even though native would probably work.

    Yes, jQuery has pushed web development (and their adopted polyfills don’t negate that fact), and yes it still has a place, but it is slowly becoming _less_ relevant (not completely irrelevant) in web development.

    Just my two cents. :)

    • http://lea.verou.me/ Lea Verou

      * I agree that some DOM methods have terrible names. Wrapping them with a function that has a shorter name is a matter of 2 lines of code.
      * There are many classList polyfills, that you can load conditionally, if classList is not supported (e.g. via yepnope)
      * Yeah, that’s a valid point: CSS animations don’t work with scroll position. :( There are standalone scripts for this though, which are much smaller and don’t cause the lockin of jQuery (and even coding your own can be fun, if you have the time/energy)
      * On huge projects, jQuery probably isn’t enough anyway. This is why frameworks like Angular, Backbone, React, Meteor etc exist, for those large projects. I believe jQuery these days is targeted to smaller to medium size projects.

      • http://andymerskin.com/ Andy Merskin

        On your note about Angular and other frameworks, you’re totally right. The frustrating part is jQLite (Angular’s tiny implementation of jQuery) can sometimes be lacking. Including jQuery before Angular in a project will cause Angular to swap out its DOM manip. library for jQuery when working with directives.

        Problem is, jQuery duplicates some of Angular’s functionality, so it’s way too much to add if you need just a few more traversal methods handy.

        • lozandier

          The thing is, it’s a simple matter of using [0] to utilize the native dom in that case, especially with Angular directives.

          At least Angular makes jQuery optional; Ember required jQuery as a dependency for a while, which was annoying to say the least to me—particularly the requirement you have to shim and provide an event delegation library in order to so (unless that changed recently).

    • WebReflection

      about classList and other goodies, everything fixed in dom4, for IE9 Mobile and Desktop too, including iOS5 and others: https://github.com/WebReflection/dom4#features

    • paulcpederson

      Here is a snippet I’ve been using for smooth scroll lately:

      https://gist.github.com/paulcpederson/7f9375b5d66120e5c7b3

      (Sorry for the ES6)

      jQuery animations are actually pretty janky next to css3 transitions IMO.

    • http://qgustavor.tk/ Gustavo Rodrigues

      Hello, your comment is two months old now! Your animation example is curious: I have a website which animates scroll using CSS but it’s jQuery that adds the transition and transform styles to the elements.

      Why? First because it was using jQuery for years, so I can’t simple remove it ( although I’m working on it ). Second and last, because without it’s difficult to use exactly the same transitions from the CSS in the scroll animation.

  • mitchel wassler

    When I was in school I was a huge purist about javaScript. I would avoid dependencies at all cost. It was great for learning it, but then I started working and all the code I came across already used jquery. It really is everywhere. I remember putting [0] after everything until I figured it out.

    Co workers will even criticize me for not using it. Even in places it has no business being (animation). Many old hat people think of it as an end all be all solution. You almost get forced into using it. People I work with tell me they don’t want to have to maintain none jquery code, because its all they know.

  • Deniss Borisov

    jQuery is a dependancy for so many popular libraries that it’s just too hard to get away from, especially if it’s allready there in the project.

    • lozandier

      Deferreds is *not* a good reason to use JQuery. It’s actually not A+ promise compliant until jQuery 3.0, & it’s often better to use abstractions such as an Observable for its use cases—*especially* UI components related to user input.

      The same applies for AJAX & Event handling; you can even use Observabhles for that as well that’s more valuable towards leveraging reactive functional programming concepts to both better provide to users & be likely more convenient for developers in a project in the long run.

  • Miles

    The jQuery API is concise and consistent between browsers. Let’s not forget that the DOM is not either of those. Then there are the thousand optimizations in jQuery that make it faster/more consistent than the raw JavaScript on browser.

    Of all the hundreds of JS frameworks in the mix today, jQuery seems to me the least worthy of the “harmful” stamp. Since not everyone is not at the level of a Verou, surely not everyone should be expected to write at her level. I like bare JS/DOM, but I shudder when I think of codebases where a junior dev used bare JS/DOM; it’s not just a jQuery thing.

  • Pingback: Дайджест интересных материалов из мира веб-разработки и IT за последнюю неделю №156 (13 — 19 апреля 2015) | Новости

  • Pingback: Idea: Extending native prototypes without collisions | Lea Verou

  • Ramses Reyes

    Don’t blame jQuery for the bad naming convention or lack of it on the vast majority of people who use it, what is harmful is the lack of clear thinking and the copy & paste way of “programing”

  • David

    Whilst it’s good that we now have native methods to replace jQuery ones, in almost every case they’re inferior. Take querySelectorAll. We’ve replaced $(‘.foo’).addClass(‘bar’) with Array.prototype.forEach.call(document.querySelectorAll(‘.foo’), function (elem) { elem.classList.add(‘bar’); }); Yuck!

    • lozandier

      Hi, David. In 2015, specifically ES2015 (known more as ES6), this is no longer a problem.

      You don’t have this problem with ES6 since NodeLists have iterators defined. .You can just do the following with a ES6 transpiler such as BabelJS:

      var articles= document.getElementsByTagName("article");

      for (let article of articles) {
      article.classList.add('read');
      }

      • David

        That still lacks the elegance and simplicity of $(‘article’).addClass(‘read’).

        • lozandier

          More simple, yes; more elegant, no. The jQuery way isn’t live & not as fast.

          jQuery documentation makes sure newcomers know off the bat that jQuery objects aren’t live (https://learn.jquery.com/using-jquery-core/jquery-object/) while this method (theoretically) allows that to happen depending on the nuances of the NodeList iterator introduced w/ ES6 for NodeList (findable via Symbol.iterator or the placeholder equivalent via a Transpiler that wouldn’t)

        • http://lea.verou.me/ Lea Verou

          I usually define a $$ function like this https://github.com/LeaVerou/awesomplete/blob/gh-pages/awesomplete.js#L299-301

          Then it’s just a matter of doing:
          $$("article").forEach(function(article){ article.classList.add("read");
          });

          jQuery’s addClass is simple because it’s canned, not due to some inherent elegance of the API. Just John or a contributor at some point realized that people need to toggle classes a lot and added shortcuts to it. If you try to do anything less common, it would involve a call to $(article).each() with a function, so basically the same as the above.

        • Glenn

          Right. And I would argue that explicitly iterating through each element has a big advantage – you know you are iterating through a list. It often reminds you that there is a better way (i.e. setting a class on a parent element instead of each child).

      • Marian Kostadinov

        This could be also written as:
        [… document.getElementsByTagName(‘article’)].forEach ((item) => item.classList.add (‘read’));

        • lozandier

          Ah, clever use of the spread operator.

        • lozandier

          I didn’t know the spread operator also implicitly leverages the iterator/iterable defined for NodeLists in ES6 (or the forEach now leveraging that as well).

          On JSBin, your way works on Traceur, but not BabelJS for some strange reason; it’s probably because JSBin may be running an outdated version of BabelJS given my way failing I know that doesn’t on recent version of BabelJS (and the fact JSBin still refers to BabelJS as 6to5).

          Here’s my bin: http://jsbin.com/sexugopulu/2/edit

        • Marian Kostadinov

          That should be the reason. I use this solution exactly with BabelJS and it works without any problems.

    • Brook Monroe

      Well, no, you didn’t replace anything with anything. The long expression is still down there, buried. You just added an extra layer to your call stack to get to it. That you didn’t have to type it doesn’t mean that it’s not happening.

      • David

        I was referring solely to the source code. You know, the stuff we actually have to write and maintain.

        Everything is computer programming is an abstraction. You might as well argue we should all be programming in machine code since it’s “still down there, buried”.

        • Brook Monroe

          You know, as annoying as it is to have to admit it, I think I might have read your post backwards a bit. For some reason I read that as a defense of jQuery, not a defense of native methods. (Note to self: caffeine first, responding on the web, second.)

          The querySelectorAll call is a distinct improvement over writing all that other script, and the working guts are (supposed to be, at least) in a language that executes more quickly than JS. One of the arguments I’ve read regarding the retention of jQuery has been that methods like QSA didn’t always work identically across all browsers in the early days, and jQuery smoothed that out. (See “The Problem with Native Javascript APIs” by Nick Zakas–it’s free for Kindle owners on Amazon.) It might be an act of faith to assume the browsers work identically even today. I don’t know if I buy that argument, though. One would think by now they’d have all gotten it according to the specification. (Famous last words, yeah–I know.)

  • Luke Whitehouse

    You make some good points, but I’d like to pick on a couple:

    1) People supporting IE8 and below are in the minority. I’d say it’s the exact opposite, and if you talk to 99% of agencies they’ll say that they at least support IE8, maybe even 7 if they’re really unlucky. At my workplace we’re supporting IE8 as we have a number of clients in the public sector who are locked into using IE8. Hopefully soon that’ll change, but I’d be very surprised to hear we’re in the minority. Do you have any figures to back this up?

    2) Converting jQuery objects. Would there ever be a reason why you would need to do this? If jQuery is ready present on a page, then you might as well use it because the bloat is already there. You’re always going to have problems when trying to refactor old code into new code, so why would this be any different?

    In general I agree with what your posts trying to get at, like all the others you citied – you don’t need jQuery. Cheers :)

    • http://lea.verou.me/ Lea Verou

      1. I think it’s hard to gauge whether it’s a minority or majority. It’s like everything else, our impressions of whether something is a majority or not are shaped by our experiences, our environment etc. Without any actual statistics, it‘s hard to say. However, keep in mind that these technologies are not only being used by professionals. And non-professionals (learners, hobbyists, students, researchers etc) have no set agenda of which browsers they need to support.

      2. Sometimes I use jQuery-dependent libraries, and then have to include jQuery, then I find something better and lose both the jQuery dependency and the library that depended on it. Our code is there to stay, but libraries come and go. I’d rather avoid locking myself into jQuery on my own code, even if it happens to be present on the page at the time.

      • Luke Whitehouse

        I appreciate what you’re saying and I agree that jQuery for the most part isn’t needed on 99% of the projects it is on … However, I feel like you’re approaching this with rose-tinted glasses.

        A lot of things would be great, the majority of us know that, but it doesn’t change the fact that people need to support old browsers or go onto a project that is already heavily engrained into jQuery.

        As you say, perhaps this is based purely on experience, and a lot of people aren’t professionals so don’t need the level of support that jQuery can sometimes provide. This is something that will slowly die out as ES5/6 becomes more widely adopted.

        • http://lea.verou.me/ Lea Verou

          I’m saying that IF you don’t need to support older browsers, THEN you don’t need jQuery. If you do, then I’m not making any points, simply this article does not apply to you. Whether these people who don’t need to support older browsers are a majority or a minority is irrelevant: They exist and it’s a group sizeable enough that I meet them every day.
          Going into a project that already uses jQuery is also out of scope here, unless you own the project, in which case it’s still too much effort to refactor jQuery out of it (like I wrote).

        • Luke Whitehouse

          Very true, I’m fixating too much on something that’s for the most part irrelevant to the main topic of the post: ditch jQuery if possible. Thanks for sharing Lea!

  • Seriously

    When you have nothing new to say, just don’t write a blog post

  • http://www.goodbytes.be/ Joris

    Thanks for the post Lea, you have a good point. I teach web development in college (my 9th year already, time flies!) and we have also made this evolution in our courses, but it all happened pretty naturally, simply because browsers and standard evolve.

    I wouldn’t go as far as calling jQuery harmful, many job positions will require some knowledge of jQuery so whenever I teach a web course, I will build up from scratch and slowly move from vanilla javascript to building our own mini-framework with helper functions like the ones you mentioned. After that, showing jQuery for an hour or so is a really natural move and students need to know about it, even just so that they can make a choice to use it or not.

    Whoever is teaching web development should definitely stay on top of current best practices so I’m not sure what schools you are talking about but as a student I’d want to avoid those. jQuery will become less and less necessary, but at this point in time I’d still say that it won’t hurt to know about its existence and how or when to use it, the same goes for Angular, but that’s a whole other story.

    • http://lea.verou.me/ Lea Verou

      I’m talking about my university, MIT. Hardly a school one should avoid, haha :) Web development isn’t really taught here, it’s assumed that whoever needs it, can pick it up, although jQuery has been suggested in a class whose projects were very web-focused. Also, open web technologies are seen as a tool, and people want to be done with them as quickly as possible. Coming from an industry background, it can be frustrating at times (you don’t want to see what kind of code somebody churns out when they have zero respect for the language).

      • http://www.goodbytes.be/ Joris

        I sure wouldn’t avoid MIT, visited only once and it felt like a very inspirational place to study :). Do you mean that in the specific class you mention, web development is underestimated? Where I teach, we take web development pretty seriously – in a good and fun way – but I know the things you learn in college are very different from what they teach in university. Maybe it’s not their goal to train web developers, but more to give them an insight in specific tools that exist on the web? Seems pretty difficult to train someone to become a decent web developer in only two or three labs.

        • http://lea.verou.me/ Lea Verou

          Yup, it is pretty inspirational. :)

          Maybe it’s not their goal to train web developers, but more to give them an insight in specific tools that exist on the web?

          Neither of the two is the goal of that course, or any course here. Web development is seen as a tool students use to do the assignments (which are about teaching them some higher-level concept, such as UI design), so of course the course wouldn’t be focused on that. However, the fact that web dev is glossed over results in quick fixes being recommended, such as jQuery. Not sure how it could be different though, it would really be out of scope to teach web development in depth (there’s an IAP course, but it’s student-organized).

  • Marian Kostadinov

    Lea, it is good that a (tech) famous person like you dared to say this.
    Thank you!

    My opinion is very close to what you say so there is no need to repeat everything.
    – The animations can be now easily done with CSS3 transitions and animations with graceful degradation for IE < 10;
    – The DOM API (eg. querySelector(All), nextElementSibling, classList) is now good enough and there are plenty of polyfills.
    – AJAX could be just a 7-8 row Vanilla JS function.
    – ECMAScript is already good enough (eg. Array.forEach, map, etc.) and again there are plenty of polyfills.
    – It is an overkill to use jQuery for simple web pages where you have 5-10 simple functions. No need to load it even if gzipped and minified.

    I could define a few excuses for people on why they keep using jQuery (no offend intended)
    1. The lazy guy – It is easy for me so I don't want to learn how really the browser + DOM + JS + CSS stack works.
    2. The traditionalist – I've been using jQuery in my projects for 3/5/10 years so why should I consider alternatives?
    3. The backend guy – I mostly write backend code by now my boss forced me to write some nasty frontend things so I just want to make it somehow an I don't care how. It just has to work.
    4. The librarian – I use many libraries (e.g. my favourite fancy gallery slider) but they all require jQuery so I have to use it anyway.
    5. The legacy victim – I have to support/extend this project but it uses jQuery so there is no chance that I can get rid of it.
    6. The cool guy – Everybody uses jQuery so this is the best it. I should definitely use that and not anything else.

    As a summary, it could be actually a matter of choice between:
    1. Quickly write a code that works (jQuery)
    2. Write a code that works quickly (no jQuery)

    • DL

      You make good points. I’d also like to add that you have to prioritize where you spend your time. A choice to get something done quicker, even though it may not be optimal, is a choice we make all the time. No need to cast aspersions on that, it’s a completely valid choice.

    • Michael Dobekidis

      So only the hipster/I-write-code-for-hobby guy doesn’t need it, because I see pretty much everyone else in your list…
      Don’t mean to sound rude but real life (paying) projects (with deadlines) don’t offer the luxury to experiment, things need to be done fast and cross browser/platform…

      • Marian Kostadinov

        If you talk about the 6 excuses, than I stand on my point that especially the people described in points 1, 2 and 6 could do something about it.
        As for the “I have not time” problem, this is just a convenient excuse. If somebody does not know how to do something quickly using or not using jQuery or any other library, then this could be a point of improvement for him/her. The web technologies are developing so quickly that we should constantly spend additional time to learn. Unfortunately, many people do not even try to stay up-to-date with the new technologies and trends and that is not nice for the overall quality of what we produce as developers.

      • http://lea.verou.me/ Lea Verou

        Oh give me a break with the “real life” excuse. Almost everyone here has worked in the real world and most still do. Implying that everyone who disagrees with you is writing code for hobby is bad form.
        There are many companies with “paying projects and deadlines” that do care about code quality, speed, standards. Not everyone, and probably not the one you’re working at, but don’t generalize your own experiences (especially if you work in Greece — the situation there is pretty shitty. I’m Greek and I know it well).

        • Michael Dobekidis

          From what I gather disagreeing with the jquery-is-the-devil movement automatically implies that I don’t write (good? efficient? tabbed code?). Also that disagreeing implies that also my company doesn’t care about quality… and that projects from Greece lack quality standards, and yet I am assuming stuff.
          More to the point I still don’t see valid points (at least in my opinion if I am allowed to have one) why we should stop using jQuery, I agree that it has some very inefficient parts like animation or ajax calls that don’t apply to every project. So instead of dropping it I would suggest a more modular approach where we can include the parts that we want and build that into a production ready script. A good example is what Phaser.io (a popular game framework) is doing with custom builds. view more here: http://phaser.io/tutorials/creating-custom-phaser-builds

        • http://lea.verou.me/ Lea Verou

          From what I gather disagreeing with the jquery-is-the-devil movement automatically implies that I don’t write (good? efficient? tabbed code?). Also that disagreeing implies that also my company doesn’t care about quality… and that projects from Greece lack quality standards, and yet I am assuming stuff.

          Decide, is there time for all these things in “real world projects with deadlines” or not? On one hand you’re talking as if everything is frantic and crazy and there’s no time to experiment, but suddenly there is time for code quality and efficiency and everything.
          Regarding Greece, it’s my home country and I’ve lived there for 27 years. I’m sorry, but I have my own opinion about how things work there (which of course you don’t have to share).

        • Michael Dobekidis

          Balance is the key, one has to be able to write code that he is proud of, but the reality is that we have all written code that we are not proud of (but bills have to be paid). From an academic point of view I tottaly agree with you and I can name very popular frameworks that are sub-optimal. We should always push forward and try out things but not all projects leave space for that, so we have to pick our tools carefully. VanillaJS has its merits but it is not panacea.

  • Samuel Imolorhe

    Ok so I have been following your tweets about not using jQuery, especially when you built the awesomplete tool, and I kinda agree with it. But I would like to know if this still holds true when you’re developing for IE8? And yeah I know..DEATH TO IE8! But for me it’s really not an option. Apparently in Nigeria where I work, IE8 still has a considerable amount of our users so we can’t afford to just forget about them. I would really love to do without jQuery but this is what is currently holding me back. Thanks.

    • http://lea.verou.me/ Lea Verou

      No, like I wrote in the post, if you have to support IE8, jQuery *really* helps and I wouldn’t recommend avoiding it… I hope the situation improves soon!

    • Daniel Manji Chikaka

      same here in Tanzania. So many people are still using IE8, i tried to avoid jQuery and got a punch on my face so i decided to use it 100% and throw away vanilla Js

  • Sylvain Pollet

    I’m not saying that your arguments are invalid, but it seems to me that there are more important things to settle now in web development that prevent people from using a library that does the job. jQuery has evolved to use new native methods when possible, the library size is decreasing and wrappers are not such a big deal. jQuery will progressively refine and die by itself, without the need to take out the torches and shouting “Au bûcher !”

  • A
    • Just some aged web guy…

      How much of these bugs really matter? Whipe out all of those concerning old browser version and you’ll have wiped out much more than half of them. Now have a closer look at those remaining bugs and realise that many of them only matter because of the general purpose a framework like jQuery has. Most of these edge cases have no impact in daily use. See node type checks and so on, you do not need it if you know which kind of nodes occur, because you’re writing them.

      In the end there will only a few bugs remain where you have to deal with. So if you do not have to support old browsers, this bug argument is nothing I’m concerned about.

    • http://lea.verou.me/ Lea Verou

      Most of these are of the form {Browser} < {Version} reiterating my point that if you need to support older browsers, sure, jQuery is your friend, but otherwise you might not need it.

  • Phillip Parr

    Not really related (sorry), but I had to swap your font-face choice of ‘Palatino Linotype’ to Verdana so that I could actually read the article.

  • Vlad

    You have a client on the phone. They say “I’d love if we could hide that and slide it in on hover”. You say “Ok. Just a second.” You type a few lines of code, refresh, and say “Ok, how’s this?” Try that with vanilla JS. Also imagine telling that client “Ok. This works, but I’d like to redo this from scratch anyway for an esoteric reason I will not go into, and it will take about 15 minutes and probably won’t work on browser X, etc”.

    • http://lea.verou.me/ Lea Verou

      Why would you do this with JS at all?! CSS animations/transitions are much faster and more elegant for doing this, and super quick to use!

  • MaxArt

    May be worth reporting John Resig’s (indirect) recent comments on the matter:
    https://twitter.com/jeresig/status/590199945174634497
    https://twitter.com/jeresig/status/590206003309891584

  • Thiago Lagden Magalhães

    Disagree!!
    jQuery born to help us with cross browser problems!
    That’s your mission and always will be until exist only way!!

  • Daan Biesterbos

    Nice article. There is just one thing I can’t agree on. I don’t think jquery is responsible for poor code practices. That would be the developers fault. It is easy to write poor code in any language using any tool on the market.

  • xavier

    I just love your idea, and nothing else :-{)

    x = $(‘.col’); // querySelector()

  • WebReflection

    well written post, if I can just share my own little $ shortcut that fits in a tweet:

    `function $(C,P){P=P||document;return/:first$/.test(C)?(P=P.querySelector(C.slice(0,-6)))?[P]:[]:[].slice.call(P.querySelectorAll(C))}`

    You want all elements ? `$(‘.all’)` … you want just one/first found, like querySelector would do? `$(‘.all:first’)`

    If I remember correctly it’s 134 chars of overhead :-)

  • Krik Batner

    As someone who works in Higher Education as a Web Developer, we don’t use jQuery because it’s what we know, we use jQuery because we JUST dropped IE7 support last year (as a web development organization) but our IT department STILL SUPPORTS ALL THE WAY BACK TO IE6.

    I want nothing more to nuke everything from IE9 back, but the problem is that you have tenured professors who have been here for 40 years and know trustees and board members and they go “well I’ve always done it this way and I won’t change.” and so we end up having to work around them.

    • lozandier

      Yeah, that happens all the time in colleges. I had to deal with tenured professors who thought the exact way in the last college I attended including unwarranted stubbornness like teaching MYSQL instead of MySQLi or PDO because “I’ve always done it that way & it’s still in use by a lot of companies”.

  • brandonrozek

    Thanks for the post! I started dying off from jQuery over the past few months. Javascript and jQuery almost look like a different language and you’re right, it is confusing to know what’s really going on under the hood. I’ve just been using it as a magical black box that gives me everything i want.

    I do believe however that jQuery has an audience. Just like how I believe bootstrap has an audience. It’s API is more easier to understand than the native DOM one which helps hobbyists who need to throw a site up do so easily. So in summary, for most people who reads your blog, yeah I think you’re right. You provide excellent reasons as to why to go native. But for hobbyists who don’t feel like wrapping their heads around then native DOM, I think I’ll still recommend jQuery

  • http://jenkov.com/ Jakob Jenkov

    I can understand the criticism of jQuery, but I still like jQuery for its fluent API. Native APIs are very verbose (names + no method chaining). And frankly, many of the problems you can run into with jQuery are not that hard to avoid (in my opinion).

  • cherouvim

    I think that this is a good post if you are in the academia or you are a js hipster/ninja/samurai or you are building js libraries and js tools.

    If, on the other hand, you are a regular (not mediocre, but regular) web developer in the real world doing actual paid work, then jQuery is almost mandatory for 99% of situations. Solving real world problems quickly should be possible without requiring PPK level javascript and browser compatibility knowledge and jQuery makes that possible. I’m quite certain that anyone who works in the industry today will agree with this statement, and everyone else (students, hipsters, experts, lib authors etc) will probably disagree.

  • Pingback: Article Roundup - Tvenge Design

  • Pingback: Tweet Parade (no.17-2015) - Best Articles of Last Week | gonzoblog

  • Pingback: 【翻译】jQuery是有害的 – 剑客|关注科技互联网

  • Pingback: Week of April the 20th | Web Design Blog

  • Ольга

    You say that it is a two-liner wrapping up say querySelector API so it looks nice and is easy to use. But is it really that simple?

    Consider doc.get, d.g, d.getElement – almost all are real life examples of document.getElementById wrapper that I have seen in the past.

    Now I would much rather see familiar things in code like $() or document.getElementById, I would write it every time just for transparency – we are not all great API architects =)

    And now consider XMLHttpRequest – now that I would be to lazy to write every time. Every single setting. I would be condemned to write my own wrapper. Imagine how many variaties of names and uses it could bring.

    And then maybe I abandon my project. And another developer comes along and says – wtf, who thought of those horrid method names. Refactor, I must refactor.

    TL;DR – jQuery code is familiar to almost all and makes project code transparent and easy to read. Alternatively VanillaJS without any “make it better wrappers” is also familiar or googlable.

    Oh, btw what if I do not write documentation on my two liner wrappers =)

  • namenemailpassword

    You should keep doing your whimsical border radius figures rather than trying to tell us how to do our job. Will cancel my preorder for your book.

  • Pingback: 1p – Lea Verou thinks jQuery may be harmful | Profit Goals

  • Pingback: 1p – Lea Verou thinks jQuery may be harmful | blog.offeryour.com

  • Pingback: 1p – Lea Verou thinks jQuery may be harmful | Exploding Ads

  • Pingback: Revision 216 – Working Draft considered harmful | Working Draft

  • jose

    I was convinced jQuery was unnecessary because we’ve delivered two large projects with no jQuery (though we kind of cheated by using the Angular lite version). But these arguments will come in handy to counter the inevitable “it wouldn’t hurt” comments for next project.

  • Harold Modesto

    I started web development when IE6 was still the bane of every developer’s life. I have always preferred using plain old javascript (slowly building up a collection of utility scripts) but everyone else it seemed was using jQuery (or prototype or library x) that it behooves you not to learn them.

    For those who think the title is too much I guess you haven’t read these circa 2009: https://groups.google.com/forum/#!topic/comp.lang.javascript/PZDouKgwFGI1-25. And that’s just one of many. Solid points but he does have a way of pissing people off. Lots of gems in that newsgroup some of which may not be as compelling now but the ideas behind them still apply.

  • Pingback: jQuery是有害的 | 知园

  • bfredit

    I’m not sure about Zepto! jQuery 2 is faster
    http://zurb.com/article/1293/why-we-dropped-zepto

  • algalon

    What about JQuery and rails ? You have to use it anyway there

  • somonflex

    Using jQuery is as convenient as it is using Disqus (wink wink).

    You drop it, it’s easy and it works everywhere.

    • lozandier

      That’s actually not a good analogy. It’s not as convenient as Disquis, provides convenience in a way that’s different than the convenience Disqus provides, & so on.

      This is moot if you know something about jQuery that it automatically generates code to automatically do DOM manipulation on multiple pages for us or something; if so, I’m sure everyone here would like to know about this. 😉

  • dapinitial

    I’m not a developer; however, thank you for this gentle hand-rapping. I think I can begin taking it from here.

  • Chathura

    There are two types of people in this field. One type of people needs to make it technically perfect and know about everything that happens underneath what they do. The other type of people just use what is useful and deliver the things monetizing it. But, which type of people are the winners ultimately?

    Even if we could think that the people who start with jQuery would miss the basics of javascripts and get less knowledge about what’s happening underneath; neither javascripts developers get the knowledge about the most lower levels such as the things about the interpreters and the knowledge relevant to the assembly level. Which means, everybody starts at some higher level. Then does it really matter how it works, if it works without causing any noticeable overhead?

    Personally I prefer to use native javascripts to get rid of dependencies. However, I do not see any disadvantage in using clean and nicely defined jQuery stuff; especially, in the industry, nobody cares about the expertise of the developer; other than the outcome and delivery. For a developer—with the very fist sight— $(“#myDiv”) looks more clean and easier to manage than document.getElementById(“myDiv”).

    • lozandier

      Developers who are serious about realizing the business intent of their business clients while simultaneously advocating for end users would stress things like performance, reliability, & lower leaky abstractions when comparing one tool with another.

      If a developer chooses jQuery because it “looks” better than vanilla JS— IMO, a truly subjective claim—they’re probably making a lazy evaluation of whether they need it & are daresay selfish, not making decisions with the users & client’s best interest at heart.

      • lozandier

        To be deliberately hasty, it’s 2015:

        You can literally do
        `const $ = document.querySelector;`

        And totally have the first sight example you are worried about be moot.

        On top of that w/ dom4 (https://github.com/WebReflection/dom4)created by a former jQuery contributor, there’s even less reasons to *necessitate* jQuery.

        You can even just do things like
        `const $$ = document.queryAll`

        and be set.

        Overall, I think Lea’s viewpoint and others are accurate to not mindlessly use jQuery—especially for reasons like you’ve used related to “looking better”.

        We as developers owe our clients, end users, and ultimately oursselves better than that.

    • lozandier

      Finally, jQuery doesn’t excuse front-end developers nowing the native implementation as much as they can.

      That’s knowledge that will always stay relevant throughout their career, while jQuery will deprecate & change—often with things very questionable to native/standard implementations.

      A good example is their non-A+ compliant Promises that only changed to the much more sensical standard w/ jQuery 3.0 that’s in alpha.

  • Pingback: 5 redenen waarom ik geen bootstrap meer gebruik - Now Digital

  • groovenectar

    If you use:

    jQuery(function($) { });

    As your “document ready,” you don’t really have to worry so much about noConflict and everything inside should run as expected for jQuery…

    “jQuery has helped tremendously to move the Web forward.” Totally agreed, but I also don’t think we’re quite to the point where something like jQuery is harmful. I think it’s still a good idea. Let’s face it — If you’re going to be a “purist” and use only native JavaScript, it might work in your environment but it’s going to break elsewhere. And it might not be you who will be noticing it. So we use an abstraction with a core focus on handling the inconsistencies, while itself remaining as consistent as possible. If a particular browser is discovered to be behaving a little differently, update the abstraction, and the code that depends on it continues to work consistently. It might be slightly bold to consider IE8 something that we should all be ignoring *entirely* as a rule, I think its market share is still notable. 7, almost certainly, 6, yes.

    I agree that it can sometimes be confusing between a jQuery object and HTML Element object, and like you mentioned it’s a matter of $() or [0] to switch them around. But using any technology in a particular toolset, you have to learn how those tools work. And with jQuery objects, we get the added functionality and cross-browser consistency. Zepto is a good lightweight call as well. And with that you get a Zepto collection object. I’d imagine it’s a similar case with Prototype and MooTools…

    Bottom line is, I think that in trying to avoid the problems with an abstraction layer, more problems are created. And problems that one might not be experiencing locally. By using an abstraction layer, you are preemptively *solving problems that you didn’t even know existed*. See this from the jQuery 2.0 release notes:

    The final 2.0.0 file is 12 percent smaller than the 1.9.1 file, thanks to the elimination of patches that were only needed for IE 6, 7, and 8. We had hoped to remove even more code and increase performance, but older Android/WebKit 2.x browsers are now the weakest link[…]

    So we’re also forgetting about legacy Android/WebKit…

  • Pingback: Copying properties, the robust way | Lea Verou

  • Pingback: Your Programming Language Sucks - Vegibit

  • Pingback: Here's my million dollar question.