Why do many web developers hate jQuery?

11Responses

Write your response…

This answer has received 2 appreciations.

When jQuery was the new thing, people loved it. It made cross-browser JS so much easier, it taught us a few new tricks, it made AJAX and animations dead simple (which was pretty tricky back when most of the world were on IE6!)

It evolved a not-to-be-sniffed at plugin community and immense mind-share. It became the de facto client-side Javascript library for years.

Those were the heady days of jQuery's heyday and it gained a lot of weight as it spent its popularity on better support and more features.

Also it attracted a lot of mediocre developers because it was seemingly 'easy to use'. This resulted in a lot of terrible Javascript being written and much debate between so-called pros (although there's nothing professional about berating newcomers) about the merits of using a library which they saw as being the lightning rod for all this bad code.

Then came The Smartphone Times. This spelled disaster for jQuery: thanks to slower, inferior CPUs, less memory and often less bandwidth, smartphones just weren't cut out for lugging around all the goodness that jQuery provided - especially if you were only using 10% of it.

This meant that a deep analysis of jQuery's internal elements went underway to see how things could be more modularised. And as we headed into the Golden Age of web development, many realised that the browsers have started to agree on some of the crap that jQuery The Negotiator had been helping them with all along. So they actively and rapidly trimmed the fat.

During this modularisation stage, many factions split off from jQuery to create super-tuned, single-purpose libraries that were extremely lightweight. They could still work everywhere (mostly) and they didn't eat up people's 3G/4G data allowances. They also performed better than jQuery in the browser in some cases.

Also in the background, the Javascript Revolution was happening seeing this 'little browser language' become a full-blown, server-side programming language. And this highlighted that jQuery was very much a client-side, DOM manipulation library, skills which weren't so transferrable to the server-side application style of programming.

Besides all of this, jQuery gained some younger, better-looking cousins/distant relatives (Angular, React etc) which tackled similar problems to jQuery in altogether new and intuitive ways. And on top of that, these new relatives started pushing to use the latest Javascript APIs, seeing super increases in performance thanks to newer browser support, while jQuery hung back making sure its feature-set worked in as many browsers as it could consistently for as long as possible.

But don't write jQuery off just yet. It will be 10 years old next year. In internet years that's approx. 1,000 years old. But look, jQuery is still going strong. Sure it's not as slick and fast as some of its younger cousins, but it still got some moves they don't do. And for those of us who remember why jQuery was the shiznit, we still got some deep respect for it and may still use it for convenience.

jQuery made a mark on client-side Javascript like no other and ushered in the Golden Age. But sometimes you gotta walk over the bones of the dead to get to the future...

Write a reply...

jQuery (and GWT actually as well) was created to overcome the big issue we had not too long ago where something that would work in one browser didn't work in another browser - JavaScript was painful to work with and jQuery came to the rescue.

Fast-forward a little bit and you see that browsers are becoming more and more standards compliant which means jQuery is no longer needed to solve that original pain. For probably the same reason GWT was abandoned.

So those who hate jQuery obviously didn't have to deal with JavaScript in its infant stages, those that did will have somewhat more respect for it and thank it for its great service over the years even if they're no longer using it.

Write a reply...

I completely understand the complaint about jQuery being the 'lightening rod' for some really bad code and practices.

All the same, for me it boils down to choosing the right tools for the right job at the right effort/price level. I'd happily use this battle-hardened library (jQuery) for quick traditional web projects.

As far as I'm concerned, people who use jquery are not developers, they are hacks.

Write a reply...

With time, we learn what is good code and what is not. Since Node.js, we have developed promises to something real. jQuery rejects to become Promises/A+ compliant - they say they can break the web when changing its behavior (why do they develop 2.x?) With Node.js and a bit React.js we have understood globals and treat them now a bad thing - hey Browserify users, globals are a BAD thing! :-) Web performance matters and yet jQuery rejects to be a modular library like lodash is. This is a problem. Some people use jQuery just for selecting elements in the DOM or doing Ajax but nothing more what jQuery has to over. 84kb for selecting elements and/or Ajax is anything but smart. jQuery does not help to structure code. Spaghetti and jQuery is a de facto unbreakable word combination.

The so often mentioned browser compatibility is a legend from the past. Why should Chrome and Firefox load jQuery to fix looping behavior when only old IE needs to be fixed? We have shims and polyfills, applied selectively if requested. Nginx can parse HTTP headers and rewrite URLs to load shims for the correct browser only.

For me, jQuery was great back in the times when IE6-8 has terrorized us and Firefox as well as Chrome interpreted JS differently, compared to each other. But things have changed fortunately and I can't find any reason why we have to keep this dinosaur alive.

jquery 2.0 has removed all that cruft to deal with IE.

Write a reply...

Whenever something gains great growth there comes a point where people will decry it simply because they want to use the next new thing. Jquery is still widely used. Its a tool. Javascript has evolved and there are many things that can be done easier than in the past, but there are still times where you can do it with less code in jquery. Every new library or javascript framework goes through this cycle. Right now as popular as Angular has become people are already complaining about its shortcomings or how it clutters and breaks conventions. You also see this with CSS as things like flexbox make people question whether you need a responsive css framework like Bootstrap or Foundation. This is the up and down sometimes manic depressive nature of web development.

Another factor influencing this trend away from libraries is what I call "the smartphone effect". Smartphone's made the push for minimizing page size as big a deal as it was back when people used modems and isdn. There was a time right before smartphones when bandwidth and browsers were really picking up steam. Suddenly loading larger pages with more features and bytes wasn't that big a deal. We didn't have to worry so much about slower internet connections and bad browsers (well except for all the IE variants). Unfortunately once smartphones grew in popularity that problem cropped up again. Suddenly the world of web development had to take a step backwards because browsers on smartphones were not as robust and we had to deal with slower cellular connections. Keeping your page size to a minimum was always important, but it became more critical again with smartphones. This is one of the reasons there is a push to use native javascript, native css etc because it keeps things lightweight and contributes to a faster loading page. With that said, smartphones and tablets have really improved a lot over the last few years. They are faster, the browsers are improving and connections are getting faster.

Its always good to know how to work with raw js without a library. If all you know is jquery that's not good. There are many times where you may only need raw javascript even though you may be using jquery. Also be aware that you don't need to load the full jquery library. These days its easy to create a package just with the features you need. There is nothing wrong with using jquery or other libraries. Just be mindful of your target audience, your page size and load times. Optimize images and try not to be dependent on too many plugins.

Write a reply...

omg screw jQuery in it's entire $hole!

Write a reply...

I certainly don't hate jQuery. I think it was a very important foundation of JavaScript's history and progress and did an excellent and very necessary job of handling the divergent implementations in different browsers for various features. jQuery offered a uniform API against which people could write their code without having to learn slightly different syntax as expected by each browser.

Having said that, I just have no need for it in my workflow anymore. jQuery comes with a number of different concerns, but we can boil it down to a few categories; DOM selection and manipulation, event handling, functional javascript, animations, and ajax.

I'm a full convert to React.js, and when using React I only ever have to select from the DOM once* to find the element into which we inject the React payload. For this we can use document.getElementById, which is supported across browsers. React also handles pretty much all of the DOM manipulation. It also handles almost all of my event listeners... but if I need to attach something to the document, document.addEventListener is supported across all major browsers. For functional javascript there are better, more targeted libraries, like lodash (lodash.com) or underscore (underscorejs.org). For ajax we use superagent (npmjs.com/package/superagent). And there are a ton of options for animations as well... or you can do much of your animations via css.

So it's not that I hate jQuery, but to me it's a historical artifact. Either I don't need what it offers, or the browsers have now converged on a standard, or there are better, more targeted solutions available via npm (ala browserify or webpack).

* This is mostly true, but in practice there are a few additional cases where you need to reach into the DOM, but React offers an API for this as well.

Write a reply...

jQuery is the king of "quick and dirty" (TM) - both by bringing ease of development to a huge community of young developers (when HTML was the thing that an up and coming geek needed to know and "dynamic HTML" was how they learned software development) and with poor plugin syntax that relegated modular design to a bunch of string handlers and magic functions, and lumping everything under a huge messy namespace.

Today, we know better. Developers have grown up and try to use good modular design with Javascript module loading, strict name spacing and micro libraries that embrace the UNIX way - do one thing and do it well. In such an ecosystem, jQuery is seen as a huge kludge.

Write a reply...

JQuery is bad. Most people (like me) don't like it because the vast majority of people who develop scripts based on JQuery are very poor coders, primarily because they never had a basis in pure Javascript to begin with. They tend to make poor code that needs heavily modifying in order to be fast and responsive. My personal stance is a library based upon an existing language is pretty much WORTHLESS unless you understand the original language.

Learn the base language first, then think about libraries. Sound fair?

Write a reply...

I also wonder why so much hate for the old and reliable jQuery. After read the comments below notice that some of the most experimented devs, have some respect for jQuery besides the bad practices and the poor performance. But trying to catch up with new, shining and shrewdly named frameworks I found some trends that are equaly hateful, from angular, to vue, all of them appears to put all the eggs on performance but little or none on friendlyness.

Thats why (I think) so many novice users are reluctant to change. The old boy stills there doing the job. From my point of view (as a designer who happens to do some web) there are anything close to jquery to solve basic interactions. There are some good libraries like zepto.js that do a great job, so if you are like me trying to make the transition it may be helpful.

Write a reply...

I believe jQuery has ruined simple searching. I used to query something like "JavaScript textarea into array" and would get several useful links on how to solve the problem using JavaScript. Now most of the links show jQuery exclusive solutions [I have to click on them and read them before I find out they are useless to me]. Why assume I am using jQuery? I am seeking to understand how to use JavaScript not jQuery. I also am tired of hearing jQuery pedants insist "but jQuery IS JavaScript." That quibble is only meaningful for those who have already adopted jQuery into their solution--for the rest of us, your solution is useless. Often questions being posted online are for how JavaScript works. Can you imagine posting a question online for "how to crack walnuts" and getting a solution "use your BMW to roll over the walnut?" When you complain "but I don't have a BMW." Then they respond "why the hell not, it's a great car!" ALL jQuery solutions should be labeled as jQuery solutions NOT JavaScript solutions.

Write a reply...

Join a friendly and inclusive Q&A network for coders

  • 🖥Pick the technologies you like & read great content through your feed.
  • 💬Ask a question when you want to learn more about anything.
  • 🚀Share what you know & build your portfolio.
Sign up nowLearn more

loading ...