DEV Community

loading...

jQuery: the king is dead

J.
There is always a monkey.
Updated on ・2 min read

Believe it or not, I see new projects including jQuery in 2021, and, IMHO, it's a shame. Here is a short post to explain why.

jQuery was the king

jQuery has been everywhere for quite a while, and there's a good reason for that: it was handy, and it solved significant compatibility issues between browsers.

There was a time where people had to make websites for IE6 (Internet Explorer 6). It was an era of chaos ^^. Browser compatibility was a big part of the job.

I mean, there are still some minor incompatibilities, but now you can safely use helpful keywords such as querySelector that allow for quick DOM selections.

If you want to grab remote data, axios is your friend. Need some smooth animation? CSS3 animations rock.

Major frameworks and platforms run now without jQuery

See this PR. Bootstrap 5 won't use jQuery anymore!

GitHub said bye-bye to jQuery some times ago too.

They used it, so there's no doubt it was helpful. I'm not questioning that at all. May I add it was super dev-friendly? I mean the syntax and stuff.

However, we have much better tools now, and Vanilla js is an excellent choice in 2021.

You'll be able to use most of the trendy js frameworks and, above all, understand how they work, what are their weaknesses and strengths.

Good reasons to keep using jQuery

  • you use a framework such as WordPress that has jQuery in its core
  • you do maintenance for a legacy project that still uses it
  • your project needs particular plugins
  • you cannot use modern technologies, and ancient browsers are essential for your business

Vanilla js equivalents

Here is a cool gist that shows it's not so challenging to use vanilla js

Wrap up

Please don't waste your time learning jQuery in 2021 unless you need to handle a legacy project that still relies on that or if you have unusual constraints in your project.

Back in the days, it was a mistake to learn jQuery before JavaScript. It's even more hazardous in 2021.

It's best if you don't start new projects with it.

As the world is not black and white, there can be specific cases where jQuery might fit your needs, but don't use it only to make "quicker" DOM selections or essential operations. It's a lot of bytes to load.

Discussion (61)

Collapse
mariocalin profile image
Mario • Edited

I also agree that using jQuery now could make no sense. However, with these kind of articles I always find a lack of explanation of why not to use jQuery. Why not use jQuery?

Modern JS frameworks use its own way of handling DOM without needing jQuery. They even have problems if you try to mix both jQuery and its DOM handling. That could be a reason.

Also, Javascript itself has a lot of functionalities nowadays to make jQuery not needed.

However, if you don't use a modern JS framework tu create a web page. Does the fact of not using jQuery impact anything?

Collapse
jmau111 profile image
J. Author • Edited

As I said in the conclusion of the post, it's a lot of bytes to load. I also mentionned the DOM selections, and sadly, some projects use jQuery only for that.

Collapse
mariocalin profile image
Mario

What bytes, jQuery or the DOM? The current version of jQuery weights 88 KBs.

Thread Thread
jmau111 profile image
J. Author

88 kb seems huge, don't you think? People use preact to avoid loading 30kb of React, for example.

Thread Thread
inhuofficial profile image
InHuOfficial • Edited

88 kb is more than an entire page on my website so it is quite significant (I presume that is before gzipping as I don't remember it being that large).

But it isn't really the page weight where it is an issue (as most sites are 1-2MB so 88kb in the scheme of things isn't massive), it is the CPU time needed to parse and compile 88kb of JavaScript.

Not an issue for a decent laptop or PC, a whole other ball game for a £200 mid-tier phone running at 1.5Ghz!

That is why jQuery is dying....sadly it is being replaced with 100+kb of React for static websites so it isn't like we have learned (React is great for complex applications, but if you are using it on a brochure website you are using a sledge hammer to put in a tack (a tiny nail)!)

If you like jQuery style syntax (as I do), here is 4kb raw, less than 2kb gzipped and compressed of JS I use for common jQuery style selection, event listeners, ajax etc.

It gives you:
.on, .off, .each, .parent, .first, addClass, hasClass, removeClass, toggleClass, .text, .html, .parent, .first, .attr and .ajax.

Can occasionally get upset with complex selectors but it works for 95% of stuff and I just fall back to vanilla when it doesn't like something.

Not to be used in production on large sites, fine for personal / side projects though!

!function (b, c, d, e, f) {

    f = b['add' + e]

    function i(a, d, i) {
        for (d = (a && a.nodeType ? [a] : '' + a === a ? b.querySelectorAll(a) : c), i = d.length; i--; c.unshift.call(this, d[i]))
            ;
    }

    $ = function (a) {
        return /^f/.test(typeof a) ? /in/.test(b.readyState) ? setTimeout(function () {
            $(a);
        }, 9) : a() : new i(a);
    };

    $[d] = i[d] = {
        on: function (a, b) {
            return this.each(function (c) {
                f ? c['add' + e](a, b, false) : c.attachEvent('on' + a, b)
            })
        },
        off: function (a, b) {
            return this.each(function (c) {
                f ? c['remove' + e](a, b) : c.detachEvent('on' + a, b)
            })
        },
        each: function (a, b) {
            for (var c = this, d = 0, e = c.length; d < e; ++d) {
                a.call(b || c[d], c[d], d, c)
            }
            return c
        },
        splice: c.splice
    }
}(document, [], 'prototype', 'EventListener');
$.prototype.find = function (selector) {
    return $(selector, this);
};
$.prototype.parent = function () {
    return (this.length == 1) ? $(this[0].parentNode) : [];
};
$.prototype.first = function () {
    return $(this[0]);
};
$.prototype.focus = function () {
    return this[0].focus();
};
var props = ['add', 'remove', 'toggle', 'has'],
        maps = ['add', 'remove', 'toggle', 'contains'];
props.forEach(function (prop, index) {
    $.prototype[prop + 'Class'] = function (a) {
        return this.each(function (b) {
            if (a) {
                b.classList[maps[index]](a);
            }
        });
    };
});
$.prototype.css = function (a, b) {
    if (typeof (a) === 'object') {
        for (var prop in a) {
            this.each(function (c) {
                c.style[prop] = a[prop];
            });
        }
        return this;
    } else {

        return b === []._ ? this[0].style[a] : this.each(function (c) {
            console.log(a, b, c);
            c.style[a] = b;
        });
    }
};
$.prototype.text = function (a) {
    console.log(a);
    return a === []._ ? this[0].textContent : this.each(function (b) {
        b.textContent = a;
    });
};
$.prototype.html = function (a) {
    return a === []._ ? this[0].innerHTML : this.each(function (b) {
        b.innerHTML = a;
    });
};
$.prototype.attr = function (a, b) {
    return b === []._ ? this[0].getAttribute(a) : this.each(function (c) {
        c.setAttribute(a, b);
    });
};
$.param = function (obj, prefix) {
    var str = [];
    for (var p in obj) {
        var k = prefix ? prefix + "[" + p + "]" : p, v = obj[p];
        str.push(typeof v == "object" ? $.param(v, k) : encodeURIComponent(k) + "=" + encodeURIComponent(v));
    }
    return str.join("&");
};
$.prototype.append = function (a) {
    return this.each(function (b) {
        b.appendChild(a[0]);
    });
};
$.ajax = function (a, b, c, d) {
    var xhr = new XMLHttpRequest();
    // 1 == post, 0 == get
    var type = (typeof (b) === 'object') ? 1 : 0;
    var gp = ['GET', 'POST'];
    xhr.open(gp[type], a, true);
    xhr.responseType = (typeof (c) === 'string') ? c : '';
    var cb = (!type) ? b : c;
    xhr.onerror = function () {
        cb(this, true);
    };
    xhr.onreadystatechange = function () {
        if (this.readyState === 4) {
            if (this.status >= 200 && this.status < 400) {
                cb(this.response, false);
            } else {
                cb(this, true);
            }
        }
    };
    if (type) {
        xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
        xhr.send($.param(b));
    } else {
        xhr.send();
    }
    xhr = null;
};

Enter fullscreen mode Exit fullscreen mode
Thread Thread
jmau111 profile image
J. Author

I would certainly agree with you, jQuery syntax is so convenient, nice minilib by the way, thanks for sharing ;)

It is also why I choose Hugo in 2021, as much as I love React and while it still brings great value for app with many interactions, that's too much for a blog or some small project.

Fewer bytes to process, better perf for sure.

Thread Thread
mariocalin profile image
Mario

I am pretty sure that 88 KB nowadays means nothing in any common device.

Thread Thread
inhuofficial profile image
InHuOfficial

It is nothing in a lot of devices, I would say 75% will parse and execute in under 50ms.

But that other 25%, the phones with little power may take 100+ms just to parse and execute jQuery.

And that is just jQuery without it doing anything.

Come May when the web vitals update rolls out that extra few ms could add up to thousands for a mid sized firm in slight position losses on Google.

Personal project with 0 traffic..jQuery away. E-commerce site doing 500k+ a year, optimise the hell out of it and dropping jQuery is a definite quick win!

Thread Thread
jmau111 profile image
J. Author

Not any.

There are many cheap devices out there as @inhuofficial said, but I also don't like having a "fat footprint", especially when it does not take unreasonable extra time to code it in vanilla js.

This approach often brings me great rewards, especially when you need to scale, but not only.

As I said in the post, the world is not black and white. If you absolutely need a framework to speed up dev, there are much better alternatives in 2021, IMHO.

Thread Thread
Sloan, the sloth mascot
Comment deleted
oenonono profile image
Junk • Edited

Yes, yes, yes. Thank you.

Another important nuance is that the general characteristics of an app using jQuery versus React are likely to be different. Most people using jQuery are server side rendering and progressively enhancing, which makes the comparison of 88kb and 30kb quite different in context. That 88kb may not block rendering or interactivity and it may be 88kb of only 500kb of JS, while that 30kb is most likely a CSR-only SPA and 30kb of 2MB of JS.

Generalizations, yes, but for valid reasons.

Thread Thread
aghost7 profile image
Jonathan Boudreau

What about developing countries? I think it still matters for certain markets.

Thread Thread
Sloan, the sloth mascot
Comment deleted
oenonono profile image
Junk

What do you mean? I guess as the thread gets deeper it loses some specificity in replies, so assuming you're talking to me...

Do you mean does jQuery's size matter in developing countries? Yes, of course, it matters. But you may not understand the details of what I'm saying if you don't know why it doesn't matter as much in the "progressive enhancement" scenario I'm referring to.

In a "progressive enhancement" scenario jQuery doesn't block anything important before it loads. HTML is server-side rendered (SSR) and jQuery doesn't block either rendering or interaction. While jQuery is loading, the end user can view content and click on links and navigate. If jQuery doesn't load, some functionality and some widgets may not be available, but there will be a worthwhile and usable experience.

If someone adopted jQuery today and used it and dozens of direct and hundreds of transitive dependencies to build a single page application (SPA) that was client-side rendered (CSR) only, it would perform just as poorly as a similarly-architected and similarly-implemented React app. But it wouldn't be because it's 88kb compared to React's 30kb (last I checked it's more than that, these must be gzipped sizes which are only relevant to network transfer time, the parse time correlates more with unzipped size where React + React DOM are >120kb, not to mention the CPU and memory intensiveness of a React app).

It's not usually any single library/framework that makes or breaks performance. It's the architecture and the aggregate. Ironically, React wasn't originally designed, implemented, or used by its authors to build CSR-only SPAs. It was used more like progressively-enhanced jQuery and it's my understanding that is still how it's used on critical Facebook properties. (That may have changed since I last checked in.)

But libraries and frameworks often have architectures that are typically associated with them in their ecosystems. There is plenty of diversity, but still. If you guess that any random React app is a CSR-only SPA, you'll probably be right. If you guess that any random jQuery-using site isn't, you'll probably be right. It was a combination of factors that led to the problems we now see. React + npm + bundlers + CSR-only + SPAs + FAANG cargo-culting SaaS monoculture led us here.

But it's not only "old" Android phones in "developing" countries impacted. It impacts me, a well-paid engineer in a "developed" country, when I'm walking around San Francisco on my current-generation Android phone. In which circumstances a React web app is often painful, if begrudgingly possible, to use (if I am patient). It impacts my users in Idaho with their couple-generations-behind, refurbished iPhones driving country roads with spotty internet. It impacts my uncle, who has an old and occasionally used PC for paying bills. It impacts my mother, who is a technophobe and only uses her Kindle that she has become comfortable with.

On the web, not everyone is like us, and there are far more people not like us than most of the engineers I talk to acknowledge. Not everyone has the wealth, the privilege, the leisure, the connectivity, or the new and powerful machine. The people around us at work aren't the average, typical user. The people at the startup a few streets over who our UX researchers interview are conveniently in proximity, but aren't the average, typical user either.

And no one says when interviewed, "I hope this will work when I'm running late and on the train." But they do wish that when the situation arises. We're capable of delivering it technically, we just don't and that's very sad.

xkcd.com/1367/

Thread Thread
jmau111 profile image
J. Author

Thanks for your detailed comments.

But it's not only "old" Android phones in "developing" countries impacted.

Never said "developing countries". Said "a significant part of the world", that would include all people with old phones.

However, if you want to take that example, some countries have very poor networks, limited bandwidth. The internet is reaaally expensive. Loading external libraries can have a high cost.

I'm not comfortable with the idea of loading all those bytes for nothing, and I remember that web vitals have a significant impact now on SEO.

PS: I like this read. I don't read it at face value, it's just interesting IMHO.

Thread Thread
aghost7 profile image
Jonathan Boudreau

From what I've read its actually even worse than that. In developing countries some phones can have a hard time parsing the libraries. This is why browsers such as UC browser are popular in places like Africa.

Thread Thread
oenonono profile image
Junk

That's a great article, yep!

Much as I am always ready to be on one about using less JS, sometimes it's not entirely for nothing. PWA app shells are an example of optimizing for first time UX in a scenario where offline support is needed. Building an offline app and/or something like an image editor does have different requirements and trade-offs and a good reason to go heavier on script and care less about startup cost.

Thread Thread
jmau111 profile image
J. Author

I agree with you, and it is something that I've discovered at work. The implementation must sometimes be different, and using CDN for example is not a good solution, especially in countries that do not have the infrastructure for that.

Collapse
lawrencejohnson profile image
Lawrence

It's not just bytes it's performance. Core web vitals and lighthouse scores tank with jquery

Thread Thread
jmau111 profile image
J. Author

Yes, it's not uncommon to get significantly different results with and without jQuery.

I'm surprised nobody mentioned in the comments you can build your own jQuery, which allows for excluding parts of jQuery are not being used.

However, that rarely happens. I don't see so many websites using custom builds.

Collapse
oenonono profile image
Junk

Yep, if you're choosing between a JS framework and jQuery and jQuery works for you, there's no reason at all not to use it. You're just trading off between different JS files, there's no objective reason that jQuery shouldn't be your JS file of choice. Every reason not to use is contextual and subjective, so make your choices based on your circumstances.

Collapse
ranjankumar666 profile image
Ranjankumar666

I think the main reason to ignore jquery is that vanilla js can do most things that jquery used to do for it.

Collapse
pratiksharm profile image
Pratik sharma

I saw a interview of the creator of JQuery. He also mentioned the most possible reason JQuery succeeded was that at that time JQuery website was very good and JQuery had a whole documentation with examples.
Now, for sure with the development in css and JS, JQuery is not that much needed anymore. Size is not the issue, it's the usability and accessibility.

Collapse
jmau111 profile image
J. Author • Edited

Interesting point, documentation is vital for any tools. Modern frameworks such as Svelte have such incredible documentation with practical examples and even interactive playgrounds. It makes the difference for sure, I agree with you.

About the size, I don't know if it is not the issue, maybe it is, at least indirectly. If you take any web vitals test, it can improve your perf score significantly, because some key metrics are related to that.

Loading jQuery to make classic sliders, basic animations has a cost. I did not measure that precisely, though.

Collapse
pratiksharm profile image
Pratik sharma

JQuery is of size 30kb minified as per the website and momentjs (66kb) which is also a widely used library in frontend development. ( i know don't use moment js thing)

I don't think size is really that big issue to kill JQuery. JQuery can't Provide with more accessibility or code easiness that it use to.

Collapse
pratiksharm profile image
Pratik sharma

JQuery is of size 30kb minified as per the website and momentjs (66kb) which is also a widely used library in frontend development. ( i know don't use moment js thing)

I don't think size is really that big issue to kill JQuery. JQuery can't proved with more accessibility or code easiness that it use to.

Collapse
oenonono profile image
Junk

What do you mean by "size is not the issue"? Size is not THE issue. But is AN issue. What do you mean by usability and accessibility? Do you mean the usability and accessibility of jQuery? Or of the UIs built with jQuery? Nothing about jQuery necessarily hurts usability or accessibility. It's all in how you use it.

Collapse
pratiksharm profile image
Pratik sharma

yeah, size is important, but the size of JQuery is not killing it. When JQuery came its usability and accessibility was huge. JQuery was the king of DOM manipulation, animation and enabled developers to create plugins.
Now, with the updates in Js and css. I can create great single page sites without using JQuery.
It's just that size is not killing JQuery.

Thread Thread
jmau111 profile image
J. Author

I think there might be a misunderstanding. My point is not that size is the number one reason to drop jQuery. I'm saying that I don't need jQuery like I needed at that time, so why would I load it on every single page of my websites and apps?

I just don't need it and I've seen poor usages :

don't use it only to make "quicker" DOM selections or essential operations.

When I said 88 kb is huge, it's because it's for nothing, and the impact is everything but insignificant. I prefer investing those kilobytes elsewhere, or best-case scenario, not investing them at all.

I find it's too expensive for the "performance budget".

Collapse
lexlohr profile image
Alex Lohr

A lot of pages still use it though, and if they're not web apps, it's perfectly fine that way. For a mostly static, content-heavy page without a lot a state, using jQuery (or even vanilla JS) instead of a modern MVC framework is still a valid choice.

It's best to remember now and then that there's no silver bullet in development. Otherwise you'll soon have modern solutions in search of an actual issue to solve.

Collapse
jmau111 profile image
J. Author • Edited

It's best to remember now and then that there's no silver bullet in development

Indeed, that's what I mean when I say the world is not black and white. I don't blame an app or a website just because it uses jQuery. There could be good reasons. Actually, I list some of them in the post.

For a mostly static, content-heavy page without a lot a state, using jQuery (or even vanilla JS) instead of a modern MVC framework is still a valid choice

I see the idea, and I won't say you're wrong, but is it a valid choice just because there are worse choices? I don't know.

I think I would stick with the following:

It's best if you don't start new projects with it.

Collapse
lexlohr profile image
Alex Lohr

I would probably amend a caveat: "It's best if you don't start new projects with it (except if you really know what you're doing and that using jQuery will actually be worth the network traffic it causes)".

Collapse
luiscaro3 profile image
luiscaro3

I was a little disappointed with the article, I thought it would carry a little more substance. That being said, I'm a software architect (specifically UI), have been working with react for years now mostly and I have to say that depending on the project, if you need to do a quick PoC like a landing page in a couple of hours, you can get it done with jquery. With a framework you'd spend that time only setting up the environment, boilerplate code and component structure. It comes down to the use, but certainly there are less and less cases now a days where jquery will be the right choice for a project, specially at enterprise level (I'm looking at you Telerik). As with everything in life, it's always somewhere in between of shades.

Collapse
matthewbdaly profile image
Matthew Daly

There are better options these days for that, though.

Alpine.js gives you a Vue-like experience in terms of enabling a more declarative API for manipulating the DOM. But it doesn't require any sort of build chain, and has a footprint a fraction the size of jQuery's, so you can just load it from a CDN and start working. It doesn't handle things like AJAX requests, but then that's often a non-issue because fetch() is a strong native option these days, or you can use Axios, and the production build will still be smaller than with jQuery.

Collapse
luiscaro3 profile image
luiscaro3

I apologize if I wasn't clear enough, what I meant to say is that projects have different needs, some have footprint priorities while for others the footprint is not relevant. Getting a PoC up and running in 1-2 hours without having to involve node etc for instance and avoiding an additional layer of complications is a good example, where you want to either go with vanilla js or if you need a little extra power for more complex stuff jQuery is still a great fit. Again it comes down to the case and it's certainly not something to use in enterprise anymore, (if you are considering jquery over a robust framework the footprint is the least of your concerns in my opinion)

Collapse
jmau111 profile image
J. Author

Too bad, still, this is what I wanted to share. While I understand that getting the job done is the most important part in the IT business, I do believe there are better tools now to do the same in this case.

There are various ways to build a landing page in minutes without jQuery, in fact it's probably one of the best examples where it's not needed IMHO.

Collapse
cescquintero profile image
Francisco Quintero 🇨🇴 • Edited

I now there are better tools out there but how is this a good example of not using jQuery?

// jQuery
$.post('//example.com', { username: username }, function (data) {
  // code
})

// Vanilla
var httpRequest = new XMLHttpRequest()
httpRequest.onreadystatechange = function (data) {
  // code
}
httpRequest.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded')
httpRequest.open('POST', url)
httpRequest.send('username=' + encodeURIComponent(username))
Enter fullscreen mode Exit fullscreen mode

The thing with jQuery is that its API is very clean and easy to remember. Go try traversing some DOM nodes without knowing the property names.

I can't see why people can't use jQuery today. It works, many bugs solved, lots of useful libraries (sadly abandoned), powerful and simple API. jQuery, for DOM traversing, IMO, it's way more powerful and expressive than the vanilla counterpart. Hey, IMO.

Of course not ideal for a SPA but you just can't discard it. More if sites like "You don't need jQuery anymore" use examples like the one for the vanilla POST request.

I say this as a backend that coded jQuery in the past and not much today but have got experience with React and Ember and know they're not for the same thing.

Don't compare them, enjoy them :D

Collapse
taufik_nurrohman profile image
Taufik Nurrohman

Who killed jQuery?

  1. document.querySelector(All)?
  2. CSS transition
  3. CSS animation.
Collapse
cmuralisree profile image
Chittoji Murali Sree Krishna

Many people in my college doesn't even know about jQuery, most of people have forgotten it,

Bcz of improving vanilla js, and the three major javascript libraries, { React, Angular, Vue }, after these frameworks and libraries started to grow the older frameworks started getting lost,

But still jQuery is used in most of the sites, and wordpress uses jQuery.

I might be wrong, But these points were upto my knowledge.

Collapse
jmau111 profile image
J. Author

Yes, it's a core dependency of WordPress, especially in the backend part. Note that you don't have to use it on the frontend, in a custom theme. Most modern WP websites don't load jQuery on the front.

Collapse
codemouse92 profile image
Jason C. McDonald • Edited

In as far as "X is dead" posts, which I generally disagree with, yours is very thorough and well-balanced. Thanks for taking the time to do it right!

Collapse
jmau111 profile image
J. Author

Thanks for saying that. Really appreciate it, because I always try to go beyond good and bad, especially in tech.

Collapse
tominoff profile image
Tominov Sergey • Edited

Yeah yeah, it's 2021 and we are still on jQuery funerals. I don't know why people keep using it — modern vanilla is'nt so bad it was back in time when we all loved jQuery. It has all the stuff jQuery had, there are tons of vanilla libraries that often works better than old-school JQ plugins.

Collapse
kalashin1 profile image
Kinanee Samson

I think using jQurey for very simple projects is still a great idea, jQuery still makes writing and managing JavaScript code quite short.

Collapse
vreezyde profile image
Lars Eschweiler

It makes no sense to use jquery in public Websites. But be Sure there are so many Intranets that use ie11. Last week i had to code for ie10. So pls Do Not fuck up some Technologie thats needed for reasons u dont understand.

Collapse
jmau111 profile image
J. Author

I don't like your tone at all. Did you actually read the post? I give good reasons to use jQuery in the post, and ancient browsers is mentioned.

Collapse
ajozz13 profile image
Alberto Ochoa

I still use jQuery. I can't get away from typing less in jquery to typing more in vanilla is

Granted I don't use jQuery in the back end only on front end single page apps

Collapse
rangercoder99 profile image
RangerCoder99

JQuery will keep on living because new web devs follow old tuts, and refuse to learn javascript and css, Same like WordPress keeps php alive 😖

Collapse
jmau111 profile image
J. Author

That happens a lot, which is why I want to write about this, even if that's a little bit controversial.

Collapse
hugekontrast profile image
Ashish Khare😎 • Edited

However, we have much better tools now, and Vanilla js is an excellent choice in 2021.
Amen!

Collapse
ggenya132 profile image
Eugene Vedensky

I think some folks are just comfortable with using tech they know they'll be productive in with minimal bugs. Can't fault them for that rationale, but I agree that modern tech has no need for it.

Collapse
jmau111 profile image
J. Author

you're right, and of course I would prefer that by far instead of someone trying to use the trendy tech just for the hype.

I agree that modern tech has no need for it

That's exactly the point.

Collapse
atabak profile image
atabak

I use jQuery even for my next project, I know jQuery, it's good for fast development.

Collapse
hxgf profile image
j youngblood

looks like you and me are the only ones, haha. i've tried to stop using it so many times but i always keep coming back...i'm just able to work so much faster and easier with jquery!

Collapse
xortype profile image
xorType

In 2001 i developed async apps without jquery. Ashes to ashes

Collapse
matheusrich profile image
Matheus Richard

Vanilla JS became good enough for simple things. If I need some sprinkles of JS my go-to tool is Stimulus.js

Collapse
lawrencejohnson profile image
Lawrence

Using wordpress is not a good reason to use jquery. It's easily removed from the frontend assuming you don't rely on plugins for your ux.

Collapse
jmau111 profile image
J. Author

Many people rely on plugins. Whether it's a good thing or not is another debate. Fortunately, most modern WP sites don't load jQuery on the front, but that's not rare, though.

Collapse
adnjoo profile image
Andrew Njoo

ok thanks for the tip :)

Collapse
snickdx profile image
Nicholas Mendez

The obsolescence of jquery shows how far the web ecosystem has come (vanilla JS or frameworks). I think this is a transition that can be celebrated.

Some comments have been hidden by the post's author - find out more