Hating jQuery doesn't make you cool

tylerlwsmith profile image Tyler Smith ・3 min read

When jQuery was released in 2006, there was a seismic shift in web development. Interactive web experiences that were too difficult to build because of browser inconsistencies and JavaScript's limited API were suddenly within the reach of typical web developers.

In the years since then, JavaScript has become a lot more powerful, and modern reactive frameworks like Angular, React, Ember, Vue and Svelte have come to dominate the web application landscape. As a result of this shift, it's become a favorite passtime of some developers to talk trash about jQuery and flex about how much better they are at development for not using it.

jQuery still has a place in web development in 2020. I want to walk through some of the common arguments I hear against jQuery and address them one-by-one:

"jQuery is a bloated dependency"

jQuery is a dependency, but I'm not convinced that it's bloated. A lot of developers like to quibble over kilobytes because they're measurable: they see a small page size as a tangible metric for measuring themselves as a developer. Surely it takes a real professional to get a 40ms page load time! However, just because it's measurable doesn't mean it's important.

Iteration speed and maintainability are much more important to the long term success of a project than fast page loads. The poorly documented helper functions a developer wrote to keep jQuery out of their project will bite them as they onboard new developers later. jQuery has over a decade of answers on Stack Overflow and is incredibly well documented.

Ultra fast web pages are only critical in a few instances like e-commerce and landing pages for lead generation. Saving 30kb of JavaScript will likely have no affect on outcomes for a local non-profit's website.

Don't let the quest for performance derail you from shipping a project: premature optimization is the root of all evil in computer science.

"jQuery leads to spaghetti code"

Vanilla JavaScript has no answer to the spaghetti code problem either: it is equally un-opinionated.

The best way to avoid writing spaghetti code in jQuery is to not write spaghetti code. For advice on how to do that, check out Learning JavaScript Design Patterns by Addy Osmani (that link has the whole book for free). Your code doesn't have to be an endless wall of jQuery event handlers, you can build better primitives on top of it by creating classes or functions that call your jQuery code.

"Vanilla JavaScript can do everything that jQuery can do!"

Can it though? Vanilla JavaScript has no answer for $('.accordion-item').slideToggle(). These kinds of animations are surprisingly difficult to accomplish in a flexible manner with CSS, and complicated to code yourself in JavaScript.

If I need to reach for a library to do this anyway, why not reach for one that has all of the benefits that jQuery provides?

"Just use React"

If you're building an app, React makes a lot of sense, but if you're building a content-driven site with moderate interactivity, you're giving up a lot by switching to React.

Most React apps end up being single page applications, meaning you're giving up server-side rendering and a good amount of your potential SEO juice. You've also introduced a build step, which potentially opens you up to the waking nightmare of having to configure Webpack.

React/Vue/Svelte also don't play nice with the wealth of Vanilla JS and jQuery component libraries like Flickity, Isotope, Slick Carousel, and a hundred others. You can make them work, but it's extra effort when you can just have it for free in jQuery.

Reactive frontend libraries are also a major paradigm shift: if you were using Vanilla JS or jQuery on top of HTML to build your app, you'd likely need to rewrite the whole thing.

Most often, I hear this labor-intensive solution pitched because "jQuery is old."

Closing thoughts

The attitudes many developers show towards jQuery are exclusionary and unhelpful. They drive developers out of the field because they're told they aren't "real developers" because of the tools they use. These attitudes make hobbyists uneasy about participating in our community. And generally, these attitudes are a huge bummer.

You can build amazing experiences in Vanilla JS. You can build amazing experiences in React. And yes, you can build amazing experiences in jQuery. Be kind.

Posted on by:

tylerlwsmith profile

Tyler Smith


I build software. Follow me on Twitter if you want to hear my ramblings! https://twitter.com/tylerlwsmith


markdown guide

Hating on {LIBRARY} and telling people they are not real developers because they use {LIBRARY} = never cool, I agree. That said I personally don't see the need for jQuery anymore if it were up to me to decide on the tech stack (barring specific backwards compatibility requirements).


There's nothing wrong with that. I personally use React for most of my current projects because the kinds of apps I'm building are a bad fit for jQuery.

I think that jQuery has a sweet spot where it's a really good fit: it feels best suited for building interactivity into 5-15 components on an otherwise static site. With less interactivity than that, Vanilla JS may make more sense. When you start having more than 20 interactive components, frameworks like React, Vue and Svelte make a lot of sense.


I've used jQuery, MooTools, Prototype, Dojo Toolkit and ExtJS in the past. Some of them were, and are still good for different purposes.

The thing about web development though, it moves really fast in the sense that there are new libraries and frameworks coming out literally every day. However, many of these libraries solve the same problem all over again. Instead of extending existing open source libraries, web devs tend to rewrite them, particularly JavaScript libraries. I wonder why.

A lot of web devs I met are young and dynamic, most of them are in their early/mid 20s. They are energetic and always curious to try new technologies. These are all good traits and I prefer such qualities in my team. However, they often forget that the main point of software development is to solve problems. If the tool solves the problems and fulfill the initial requirements, then it is good enough. There might be better tools out there, but you don't need to have the shiniest bleeding-edge tools out there every time, particularly if they don’t solve the initial problems.

What I often hear from web devs I know is that, because library A does one or two things better than library B, library B is automatically out-of-date and that library A is superior to B. That kind of thinking is, well, sad.


This is very true.. as an older developer I enjoy and like that our tools are constantly evolving - and finding new and better ways of doing things is what we do every day

I also know that whatever the current fashionable method, library or framework is they'll be a new one along in a minute that everyone says is much better!


"they often forget that the main point of software development is to solve problems"

This is soo true. Nowdays we are too much biased towards discussing & arguing about tools rather than actually solving the problem.
I'm pretty young in tech industry, i don't have much experience, but i always get frustrated when a person argues/discusses about what tool to use for 2hours rather than solving the actual problem.



Mainly i see it as an "#internet" thing. I never heard anyone in a meeting env. get up and say that he wants this random tech in the project because thats what real programmers do. It would be just silly.

jQuery is a tool, like a shovel. Sure it's an 'old technomology' but it does the job when you want to dig a hole.

Also i love .ajax() to death. Saved my butt so many times


I remember my first project ever doing AJAX: I was still super new as a dev and I had promised some AJAX stuff to client that I didn't actually know how to do. I had blown off the feature until the end, and like an hour before I had to leave for the meeting, I pulled up the jQuery AJAX docs and got everything to work straight away. That was a live saver.


An interesting post, Tyler, thank you for it. While I agree that there's a tool for every job, I can't help but wonder why reach for jQuery when libraries like zepto and cash are a tenfold smaller and also more performant? they give you almost all the features and allow you to plug in all the same plug-ins. Also there are other great behavior and interaction targeted libs like alpine.js that I'd recommend checking out. I feel like fighting for jQuery in 2020 is more of a novelty thing and people not willing to let go. At this point, I'd feel safe to say that if you can support evergreen users, you should never reach for jQuery (even if you check all your listed criteria), simply because there are more lightweight options available that fit the bill.. And while you can still argue that the couple tens of kilobytes are irrelevant, adding a few plug-ins of the same size really adds up (and I feel $ plugin developers are notorious for bloated code that you can't treeshake nor import dynamically with ESM etc).

Would love to hear your thoughts on my take 🙏

Edit: just re-read my reply and I wanted to emphasize that I agree with you in the larger sense, just not specifically on the jQuery bit itself 100% 😅


WordPress powers 35% of sites on the Internet, and the majority of those sites are already using the copy of jQuery that's bundled with WordPress on the front end. This is even true with custom built themes: almost all of the popular WordPress form plugins use jQuery. That means almost 1/3 of sites on the Internet have already paid the jQuery penalty. If you do development on a WordPress site, you're almost certainly sending down extra bytes by including Alpine or friends.

Except it's not just WordPress. W3Techs estimates jQuery to be used on about 75% of sites on the internet.

These newer, more performant libraries are pretty cool. But most of them are developed largely by sole maintainers who could walk away at any time. jQuery–for better or worse–will outlive us.

Every time I hear talk about jQuery's performance and "right tool for the job," I'm reminded that there are a decade of "Ruby on Rails is Dead" posts floating around the Internet. Surely with Elixir, Rust, and Go, there's no reason to write Ruby on Rails in 2020!

Except there's enormous business in boring tools. Airbnb, Groupon, Github, Couchsurfing and Shopify use Rails, and they know that the future of the framework is secure. If their entire engineering department was hit by an astroid, they'd be able to find more Rails developers and the framework would still be around. Mega companies still use jQuery in their stack for the same reason: the best technology available isn't always the best technology for the business.

jQuery isn't the right tool for every job. It's not what I use the majority of the time in my day job. But it's still relevant in 2020, and it will likely still be relevant for at least another decade.


Everybody always mentions bytes sent over the network, and that's great to keep in mind, but your gzip number only tells half the story. That prepaid ~30kB network cost that you save is still 86kB of raw JavaScript for the browser to parse, every time.

And as you bring up enormous tools like GitHub etc, note that almost all of them opt for vanilla JavaScript that gets sprinkled in sparsely, and not an outdated library that costs a user a tenth of a MB to parse 🤷‍♂️

But I obviously can't dispute that this little conversation could change anything and that we'll of course see jQuery and friends stick around, and that's okay.


There are still plenty of enterprise level websites on Drupal and Wordpress or other like frameworks (or using Bootstrap.js) where jQuery is just part and parcel. If you have jQuery available already, minified and cached, rolling out your own custom vanilla javascript may not be the best option. Like you said in the article:

"The poorly documented helper functions a developer wrote ... will bite them as they onboard new developers later."

Of course a counter to that is to write well-documented helper functions, but still, there it beauty in the speed and elegance of well-maintained, cross-browser supported, chainable, utility functions and classes.

That being said, that doesn't mean I don't like writing my own functions and using modern libraries. But my feelings about such things isn't the most relevant factor in most cases.


Bootstrap is dropping jQuery dependency in the next version FYI. Source: blog.getbootstrap.com/2020/06/16/b...


While I am very happy about my conversion to Stimulus - which is actually by the creator of Prototype, which inspired jQuery - I am regularly frustrated by how some things that are easy in jQuery are still difficult and wildly non-standard in vanilla JS.

One of the best examples is the .parents() method, which returns an array of the ancestor chain. It's not even mentioned on You Might Not Need jQuery.

I have legitimate beef with jQuery's fake event system, and even wrote a Stimulus controller to map them to real events.

However, the main reason I had to move beyond jQuery is that it is stuck in the 1:1 page load/screen world that made sense when it came out, but not in an era when people use Turbolinks and other tools to make things fast. One load event just doesn't work in 2020 and that's why so many jQuery plugins are just broken, now. I wrote about this issue extensively, if you're interested.

Stimulus is a really warm pool to get into. If you love working with jQuery, Stimulus provides lifecycle events but otherwise lets you do your thing. You can even use jQuery inside Stimulus, but I suggest you just bite the bullet.


I've looked at Stimulus before, but I haven't had a good use case to try it out yet. Maybe someday when I do a Rails project!

I like Turbolinks a lot. What a silly and wonderful idea that was.


Right on. Please let me know if you have any questions.

In the meantime, it does seem important to stress that Stimulus is not a Rails thing, at all.


There's a difference between hating on JQuery, and knowing when it's simply not worth adding the dependency for something simple.
I am by no means a fan of JQuery, but when a client requests compatibility with IE6 (Oh yeah, enterprise sure loves their "if it ain't broke") being able to drop in JQuery sure makes things a lot easier.

generally though, JQuery used to solve the problem of compatibility which is (largely) not a problem anymore (see youmightnotneedjquery.com/).
As with all tools, it's useful for it's designed use cases


I agree that knowing when it's not worth it to add a dependency for something simple is valuable. I think that jQuery's usefulness is more than just compatibility though.

jQuery is really good at DOM manipulation and has an easy-to-learn API. It's possible to write a site's back-end code in C, but most developers prefer to use something a little easier to learn and less verbose like PHP, Python or JS.

jQuery can make development a lot faster on some projects. It's not the right tool for every project, but it is for some.


jQuery definitely has a very neat API, but a lot of that API has been ported into the standard runtime (think sizzle etc), I haven't really found myself reaching back for jQuery when dealing with DOM modifications rather than the standard API (though I have to admit that adding a bunch of DOM elements can be cumbersome, that's usually the sign you're in need of something more template-like like Vue, Svelte etc when you don't need a full SPA)


Learning JavaScript Design Patterns by Addy Osmani, the link to this text seems to be broken.


Thanks for telling me, I sure messed that up. It's fixed now!