Prahlad Yeri

Posted on Jun 28, 2019 • Originally published at prahladyeri.com

Why is there such profound and intense hatred towards jQuery in the WebDev world?

#javascript #webdev #productivity

(Originally published on prahladyeri.com)

In most webdev or javascript forums I've visited, one theme is quite common: Many devs there have a unilateral, profound and intense hatred towards the jquery library and this is totally beyond my understanding.

The most commonly cited reason is its size which is about 95kb in most minified versions. But considering the power & flexibility it gives to the developer (terse and simplified way to access selectors, events, ajax, etc.), is 95kb really that much of a huge deal in the digital age of 2019?

Remember, we are living in an era where news and social media sites easily download tens of megabytes of data in adware alone!

As much as some devs would like jquery to vanish from the face of this world, its not going to happen any time soon and the reason is simple: jquery is ubiquitous in use and some of its ways have no other alternatives. Consider the following oft used jquery snippet for instance:

$(document).ready( function () {
    console.log('Do Something');
} );

The $(document).ready() is one of the most common jquery constructs which many webdevs have grown up hearing. Now, consider the pure JS way of doing this exact same thing (hint: most webdevs won't even know this unless they googled for "pure js way of document load" or something first!):

document.addEventListener("DOMContentLoaded", function(event) {
    // Your code to run since DOM is loaded and ready
});

It shouldn't take a genius to tell you which is more readable, terse and preferable. Another quite common use of jquery is DOM selection. Anyone who tells you that document.querySelectorAll("div.foo") is more preferable to $("div.foo") need to have their head examined.

Another baseless allegation against jquery is that it is "old and outdated". Granted that its old, but its also rock solid in stability and doesn't need tweaks and updates every now and then like so many other libraries in the npm galaxy ecosystem. Considering that the usual shelf life of a shiny new library or framework in JS world is hardly a couple years, devs should be proud of jquery, not trash it as something old and outdated.

The ajax syntax of jquery is so powerful that it has become second nature to many JS devs:

$.get("/foo", function(data){
    //handle data
});

$.post("/foo", {x:100, y:200, z:300}, function(data){
    //handle data
});

The pure JS alternatives to these are so unpleasant that most devs won't even try to recall it, trust me!

Now, the question that naturally arises is how can someone dislike something so useful in daily programming! Is it basically the psychological impostor syndrome that sits deep within our subconscious minds and tells us to dislike all good things in life? What do you think? Please let me know in comments.

Top comments (7)

Mike • Jun 28 '19

The pure JS alternatives to these are so unpleasant that most devs won't even try to recall it, trust me!

// GET
const response = await fetch('/foo')

// POST
const response = await fetch('/foo', {method:'POST', body:JSON.stringify({x:100, y:200, z:300})}

Prahlad Yeri • Jun 29 '19 • Edited

While fetch is wonderful, it isn't a drop in replacement for jQuery's $.get and $.post! It has very different behavior - it doesn't save cookies in a get/post request for example, so it won't work in cases where authentication is required.

fetch also lacks compatibility with older browser versions (such as IE9 and earlier). The compatible way of doing AJAX in pure JS is this (which is relatively less elegant):

var xmlHttp = new XMLHttpRequest();
xmlHttp.onreadystatechange = function()
{
    if(xmlHttp.readyState == 4 && xmlHttp.status == 200)
    {
        alert(xmlHttp.responseText);
    }
}
xmlHttp.open("post", "server.php"); 
xmlHttp.send(formData);

rhymes • Jun 28 '19 • Edited

The most commonly cited reason is its size which is about 95kb in most minified versions. But considering the power & flexibility it gives to the developer (terse and simplified way to access selectors, events, ajax, etc.), is 95kb really that much of a huge deal in the digital age of 2019?

I don't think it's baseless, yeah, we send a lot of data, but if you only need a subset of jQuery that's covered by ES6 and the DOM API, why use it at all?

It shouldn't take a genius to tell you which is more readable, terse and preferable. Another quite common use of jquery is DOM selection. Anyone who tells you that document.querySelectorAll("div.foo") is more preferable to $("div.foo") need to have their head examined.

I think you're being too harsh. Personal preference aside, if the issue is the the fact that you have to type more, you can just alias:

var $ = document.querySelectorAll.bind(document);
$("div.foo")

Granted that its old, but its also rock solid in stability and doesn't need tweaks and updates every now and then like so many other libraries in the npm galaxy ecosystem

That is true, it's feature complete. But it's not easily compatible with the fact that most JS frameworks are moving away from directly updating the DOM, which jQuery does.

The ajax syntax of jquery is so powerful that it has become second nature to many JS devs

"Second nature"... it's just a matter of learning a new API :D and window.fetch has been around for years now, though I admit its API isn't great :D

It has its uses but we still have to recognize that ES6 and the DOM API provide a lot of the features jQuery brought to the table, builtin. Either way, there's no right or wrong choice in absolute terms :D

Prahlad Yeri • Jun 29 '19

Thanks for mentioning document.querySelectorAll.bind, I didn't knew about that!

And window.fetch isn't a drop-in replacement for jquery's $.post() or $.get(), it has slightly different behaviors - it doesn't store cookies, so can't work with authentication for example. There is also the fact that it won't on some older browsers like pre IE9.

rhymes • Jun 29 '19 • Edited

And window.fetch isn't a drop-in replacement for jquery's $.post() or $.get(), it has slightly different behaviors

But who said it should be a "drop in replacement" ? I don't like fetch that much but there should be no assumption that its API should be like jQuery, for what reason? They are different projects.

it doesn't store cookies, so can't work with authentication for example.

This isn't true, by default fetch sends auth headers and cookies for the same origin, if you're looking for cross origin support, just specify credentials: include

There is also the fact that it won't on some older browsers like pre IE9.

If what you're after is support for older browsers jQuery might make sense, it's just that your argument is as one sided as the one of the people you're citing in your post :)

Heiker • Jun 28 '19

95kb really that much of a huge deal in the digital age of 2019?

Yes. Or at least draw the line somewhere. What is too much for you 1MB, 2MB 5MB?

Remember, we are living in an era where news and social media sites easily download tens of megabytes of data in adware alone!

What are you doing? You don't think jquery is bad and yet you're trying to justify yourself by saying others are doing worse?

jquery is ubiquitous in use and some of its ways have no other alternatives.

Okay. You really like jquery's syntax. I get it. To be fair there are some libraries that try to be an alternative (like this one: cash).

Anyone who tells you that document.querySelectorAll("div.foo") is more preferable to $("div.foo") need to have their head examined.

So your opinion is now a fact and everyone else is stupid. Nice.

The pure JS alternatives to these are so unpleasant that most devs won't even try to recall it, trust me!

You can't be serious? That's it? That's all you have to say in defense of jquery? You didn't even mention the plugin ecosystem.

Let's do a recap: you like jquery's "syntax" and you like the utility functions.

If you ask me those 95kb are not worth it. I would prefer to make my own utility functions. If i need some heavy DOM manipulation then i would go for Preact.