For the record, JQuery is NOT to blame for the so called spaghetti code. Most people seem to blame JQuery for their own short coming. Most people also do not seem to understand the genius that was contained in JQuery. See "http://eyeandtea.com/crxcmp" for an example of what could already be done with JQuery in the IE8 era. A lot of the things later invented in the browser were to mask these shortcomings instead of admitting to them. The shadow DOM is one example. JQuery already had a feature that rendered the shadow DOM unnecessary, but it would require discipline that most developers did not have nor understand.
Having said that, after JQuery 1.x, and in particular, the changing, the deprecating, and the dropping of things here and there, JQuery no longer made sense. Somewhat similar to the SDL situation in the C/C++ word. An important role of JQuery, similar to SDL, was a strong code contract before anything else, and if the developer now has to account for JQuery's version differences like having to account for browser differences, what is the point.
Dont get me wrong - I really like and appreciate your comment.
However, and adding to other replies, by SDL I assume you mean the Simple Directmedia Layer?
SDL looks rather strong from my perspective and still my typical goto when having fun making a game. You could argue SDL lost some customers in favour of other libraries like RayLib - or moving away from making things from scratch to Unreal, Unity, etc.
SDL still seems popular - as SDL version 3 was officially released less than a year ago (or it feels like it)
However, I guess it depends what you need to do.
> JQuery already had a feature that rendered the shadow DOM unnecessary, but it would require discipline that most developers did not have nor understand.
Congrats to everyone involved in the jQuery 4.0 release.
For what it’s worth, if you’re looking for a more structured approach on top of jQuery, JsViews (https://jsviews.com) provides a reactive templating and data-binding system that’s been around and stable for many years.
It hasn’t seen the same level of adoption as newer frameworks, but it may still be of interest to people who prefer the jQuery ecosystem.
That looks interesting, I'm not likely to write any jQuery any time soon, but I'll check out the source code to see if I can learn anything from it.
Regarding adoption levels, the JsViews website made me think I had accidentally toggled the "Desktop Site" option in my Iceweasel browser, I wonder if that scared people off. Or perhaps it's because, as others mentioned, most jQuery development these days is in legacy codebases where the devs are not allowed to add any new libraries, reducing the adoption rates of any new jQuery libraries even more than you'd expect based on the raw nrs of jQuery users.
(the website does work though, and it loads fast. Which is something I've always appreciated about jQuery based sites still alive today. The only thing I'm missing is any indication of how big it is when minified + gzipped. EDIT: jsrender.js is 33.74 kB, jsrender.min.js a mere 12.82 kB)
I’ve found similar quality in the more recent Storybook upgrade tools - clean CLI wizard, clear error messages, and it does a good job of examining your setup and letting you know what it can and can’t upgrade automatically, with clear instructions on the parts you need to handle yourself.
I love tech hype cycles haha, I remember when you got laughed at for using jquery and now it seems everyone’s burned out and happy to go back to a simpler time
Someone should just hook up a virtual dom to jQuery, it's got a whole plugin ecosystem that AI could really re-use. Jquery + Jquery UI + Jquery Plugins + AI is probably a super power we're all overlooking.
20 Years! I remember when jQuery first release I thought in 5 to 10 years time we wont need jQuery because everything jQuery has will be built into the browser or becomes part of HTML Spec.
But then Google, Chrome, iPhone, PWA or JS for everything took over and took a completely different path to what I imagine webpage would be.
Everything I ever used jquery for 15 years ago, I found myself able to do with the CSS and the JS standard library maybe 10 years ago. I honestly am confused when I see jquery used today for anything.
Is there still anything jquery does you cannot easily do with a couple lines of stdlib?
The terse and chainable jQuery syntax is more readable, easier to remember, and thus more pleasant to maintain. Rewriting for stdlib is easy, but bloats out the code by forcing you to pepper in redundant boilerplate on nearly every line.
which I found while doing some performance work at one point. intercooler.js started as a custom function that hooked .load() in based on custom attributes (a trick I learned from angular 1.x)
The problem with jQuery is that, being imperative, it quickly becomes complex when you need to handle more than one thing because you need to cover imperatively all cases.
Related: This is a nice write-up of how to write reactive jQuery. It's presented as an alternative to jQuery spaghetti code, in the context of being in a legacy codebase where you might not have access to newer frameworks.
This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related. In retrospect, over-engineered React code can be worse than decently organized jQuery code, but some jQuery mess was worse than any React code. So I guess I'm saying, React did raise the bar and standard of quality - but it can get to be too much, sometimes a judicious use of old familiar tool gets the job done.
I used this approach before and it indeed works better than the 2010-style jQuery mess. A good fit for userscripts too, where the problem you attempt to solve is fairly limited and having dependencies, especially with a build steps, is a pain. Note that you don't need jQuery for this at all, unless you are somehow stuck with ancient browser support as a requirement - querySelector, addEventListener, innerHtml - the basic building blocks of the approach - have been available and stable for a long time.
In ol'times people used BackboneJS[1] for that purpose. And surprisingly enough, it is still being actively supported[2].
If someone is still using jQuery for legacy reasons, BackboneJS might be a good intermediate step before going for a modern framework. Backbone is pretty light and pretty easy to grasp
That's a very nice pattern indeed. If you add signals, the update function even gets called automatically. That's basically what we do in [Reactive Mastro](https://mastrojs.github.io/reactive/) ;-)
The last major jquery app I wrote ended up using a similar reactive pattern. I had to shoehorn a custom search engine frontend into a Joomla CMS where I wasn’t allowed to change much. Good times!
But if you do that, you'll also find it easy to write plain JS without any libraries or frameworks. document.querySelectorAll is just slightly more verbose than $(). I have personally done this: for simple web pages, I just eschew all dependencies and write plain JS.
This is still the way - jQuery or not - for UI where you can't/don't want to use a component library. I use the same approach for my browser extensions, both for page scripts and options pages. Writing features so you update state then re-render also means you get things like automatically applying option changes live in page scripts, rather than having to reload the page, for free. Just receive the updated options and re-run everything.
Browser extension options pages are mostly a form mapped to what you have stored in the Storage API, so implementing them by handling the change event on a <form> wrapping all the options (no manual event listener boilerplate) then calling a render() function which applies classes to relevant elements (<body> classes are so good for conditionally showing/hiding things without manually touching the DOM), updates all form fields via named form.elements and re-generates any unique UI elements makes it so un-painful to change things without worrying you're missing a manual DOM update somewhere.
My options pages are Zen Garden-ing 5 different browser-specific UI themes from the same markup to match their host browsers, which is a brittle nightmare to maintain in an app which needs to change over time rather than static demo HTML, but once you've tamed the CSS, the state handling and re-rendering is so painless I'm sticking with it for a while yet, even though it would be long-term easier if I used Preact+htm for no-build option components which know what the active theme is and can generate specific UI for it.
My favourite dirty old-school knowledge is still the named global created for an element with an id, why bother selecting an element when it's right there (once you know you need to avoid global name collisions)?. I use those suckers all the time for quick fun stuff and one-off tool pages.
jQuery made a messy ecosystem slightly less fragmented. Combined with CKEditor it effectively tamed a lot of web-developer chaos until nodejs dropped. =3
jQuery was very useful when many features were missing or not consistent/standardized between browsers. Nowadays, JS / DOM API is very rich, mature and standardized. So, jQuery is not as necessary as it was before.
Yes, sometimes the vanilla JS analogs are not the most elegant, but the vast majority are not terribly complicated either.
IMHO, another advantage of vanilla JS (aside from saving ~30KB) is potentially easier debugging. For example, I could find / debug the event listeners using the dev tools more easily when they were implemented via vanilla JS, since for complicated event listeners I had to step through a lot of jQuery code.
It looks like it was done to not delay the 4.0 release. Since they follow semvar, that means it won't get the axe until 5.0 [1]. Pretty wild considering that 3.0 was released 10 years ago.
But maybe they will scope this one better: they were talking about getting 4.0 released in 2020 back in 2019!
Backwards compatibility. Apparently there are still some people stuck on IE11. It's nice that jQuery still supports those users and the products that they are still running.
JQuery is cool because it does not try to replace the HTML. Progressive_Enhancement / Graceful Degradation is possible with jQuery, something which the new Frameworks, Svelte, React, etc., have forgotten / never learned.
It's amazing how much jQuery is still used today. Even on modern websites you can often find it included (browser devtools -> jQuery in the console, and see). And not just on hobbyist sites, but on serious company websites and their web tools as well.
That changelog is wild; it closes out dozens of issues that have been open on Github for 5+ years. I assume that's related to this being the first new major version in years.
Has anyone done any benchmarks yet to see how jQuery 4 compares to jQuery 3.7?
Much like I am sure anyone else who started doing web dev in the 2000s and 2010s before SPA frameworks were as prevalent I learned web development scripting with jQuery and I am happy to see its still around. Theres so many things I built on top of jQuery in those early years that likely still work. Kudos to the team.
I was surprised that for most of my smaller use cases, Zepto.js was a drop-in replacement that worked well. I do need to try the jQuery slim builds, I've never explored that.
Most of the changes are completely reasonable - a lot are internal cleanup that would require no code changes on the user side, dropping older browsers, etc.
But the fact that there are breaking API changes is the most surprising thing to me. Projects that still use jQuery are going to be mostly legacy projects (I myself have several lying around). Breaking changes means more of an upgrade hassle on something that's already not worth much of an upgrade hassle to begin with. Removing things like `jQuery.isArray` serve only to make the upgrade path harder - the internal jQuery function code could literally just be `Array.isArray`, but at least then you wouldn't be breaking jQuery users' existing code.
At some point in the life of projects like these, I feel like they should accept their place in history and stop themselves breaking compatibility with any of the countless thousands (millions!) of their users' projects. Just be a good clean library that one can keep using without having to think about it forever and ever.
I don’t understand your use case. If you’ve got legacy projects that you don’t want to touch, why upgrade a dependency to a new major version?
You can keep using jquery without having to think about it. Just keep using version 3.7 and don’t even think about version 4.
Prototype was great when it first landed but I found jQuery to be so much more elegant and fluid. For example, the overloaded $(...) which I'm pretty certain we have to thank for querySelectorAll.
I used jQuery for the past ~ 10 years on smaller apps and I had no problems with it. Then I slowly replaced it with modern JS wherever possible and I found that today I am using jQuery only because Datatables.js depends on it.
It was a nice ride, many thanks to the people that worked and still work on it. Not sure we'll ever see a jQuery 5, but that's life.
Wow, this is interesting to see. I thought jQuery was dead.
My next question would be, is this something that OpenAI and Anthropic would train their data on? If I ask Claude Code to write an app and utilize jQuery, would it resolve to the previous version until it's retrained in a newer model?
Congrats on shipping!!!! It's been a long time since I've written any jQuery but I remember how wonderful it was to work with in the age of browser inconstancies. Thank you EJohn and the team for continuing the project.
I thought this would include more drastic changes, but it seems that this is more house cleaning stuff, like, "nobody should really be using this in 2026". They are providing a library for someone who really likes jQuery and wants to use it over something like React. (Which is completely fine and reasonable.)
> This syntax is simple to write, but to our standards, doesn’t communicate intent really well. Did the author expect one or more js-widget elements on this page? Also, if we update our page markup and accidentally leave out the js-widget classname, will an exception in the browser inform us that something went wrong? By default, jQuery silently skips the whole expresion when nothing matched the initial selector; but to us, such behavior was a bug rather than a feature.
I completely agree with this, because I have been bitten so many times by this from subtle bugs. However I can see some other people not caring about any of it.
I already know that I am definitely not going to use jQuery in my personal projects, and there is no chance that my workspace does. (I much prefer letting a framework handle rendering for me based on data binding.) So none of that concerns me. But good luck to jQuery and anyone who sticks with it.
I remember the first time I tried jQuery -- which was 2009.
Before jQuery, I had vanilla JS code that factored in Safari, Firefox, Opera... and... IE6, IE7, and then IE8 which was (from memory) recent at the time.
Trying to design a visual drag n' drop editing interface on the web was a chore at the time especially with the differences in IE browsers! It was suprising how many customers were still using IE6!
A lot of this is purely by memory, now. I even have shivering memories reminding myself I was using VB.NET with ASP.NET Web forms. I really HATED it!
I remember ASP.NET provided dynamic web pages with things like Placeholder tag, etc. Again, It felt bloated even back then but I made it work. It was a balance of using what was recommended by other developers, and trying to ensure performance is good.
By around end of 2009, I tried jQuery as an experimental branch and very impressed with its capabilities. Despite being a decent Javascript developer at the time I was inexperienced with AJAX (Technically I was a Junior dev in ways) but jQuery shows me the way. It was not long before I ditched certain features of .NET Web Forms for jQuery.
At the time, there may have been a little overhead replacing various javascript code I am written with jQuery but the rewards were high. It was cleaner frontend and backend code, thanks to simple AJAX calls.
Since then I've always had huge respect for jQuery!
While I don't consider myself a decent javascript as I don't use it much. However, when I do come back to web development, I cannot be asked with the modern ways. To me it's bloat. I just stick with htmx, now. If I have do some fancy things visually then I will use jQuery.
Don’t let all of the old heads glazing jquery in this thread confuse you - they’re just nostalgic. There’s no reason to even think of using jquery in 2026
Generally speaking, no, since a lot of what it does is now available natively, the odds that you'll need something from it are much lower.
There's probably some corner-case stuff it still makes easier if you're not using some framework, but I don't think there's a reason to go out of your way to use it just for the sake of using it.
What is the usecase for this in the age of React, NextJS? And for static sites we have Astro etc.
And even if you need something simple why use jQuery? Vanila JS has better API now. Am I missing anything?
I do a lot of custom JS widget development, games, and utilities that are outside the context of a gigantic framework like React. Not everything is a a full-page SPA. Vanilla JS is indeed better than it was, but I found myself writing small JQ-like libraries and utilities to do tedious or even basic DOM manipulation, so I switched back to JQ and saved myself a lot of time and headaches. Compressed, minified JQ is also pretty small and is negligible in space consumption.
JQ is also used in frameworks like Bootstrap (although I think they’re trying to drop third-party dependencies like this since they tend to cause conflicts).
I have also used JQ in an Angular app where complex on-the-fly DOM manipulation just isn’t practical with standard tooling.
Hobbyists don’t want to learn every new framework. Someone can have a small business website for their activity and have been happy using jQuery since 2010.
jQuery is v4 now, but a lot of sites esp. wordpress still have 1.11 or 1.12 and only uses them to either doing modals(popover), show/hide(display), or ajax(fetch).
usere9364382|1 month ago
Having said that, after JQuery 1.x, and in particular, the changing, the deprecating, and the dropping of things here and there, JQuery no longer made sense. Somewhat similar to the SDL situation in the C/C++ word. An important role of JQuery, similar to SDL, was a strong code contract before anything else, and if the developer now has to account for JQuery's version differences like having to account for browser differences, what is the point.
masfoobar|1 month ago
However, and adding to other replies, by SDL I assume you mean the Simple Directmedia Layer?
SDL looks rather strong from my perspective and still my typical goto when having fun making a game. You could argue SDL lost some customers in favour of other libraries like RayLib - or moving away from making things from scratch to Unreal, Unity, etc.
SDL still seems popular - as SDL version 3 was officially released less than a year ago (or it feels like it) However, I guess it depends what you need to do.
pas|1 month ago
Could you explain this please?
jxhdbdbd|1 month ago
Are you talking about STL? But even there it makes no sense
JoeyJoJoJr|1 month ago
synergy20|1 month ago
alnico|1 month ago
For what it’s worth, if you’re looking for a more structured approach on top of jQuery, JsViews (https://jsviews.com) provides a reactive templating and data-binding system that’s been around and stable for many years.
It hasn’t seen the same level of adoption as newer frameworks, but it may still be of interest to people who prefer the jQuery ecosystem.
vanderZwan|1 month ago
Regarding adoption levels, the JsViews website made me think I had accidentally toggled the "Desktop Site" option in my Iceweasel browser, I wonder if that scared people off. Or perhaps it's because, as others mentioned, most jQuery development these days is in legacy codebases where the devs are not allowed to add any new libraries, reducing the adoption rates of any new jQuery libraries even more than you'd expect based on the raw nrs of jQuery users.
(the website does work though, and it loads fast. Which is something I've always appreciated about jQuery based sites still alive today. The only thing I'm missing is any indication of how big it is when minified + gzipped. EDIT: jsrender.js is 33.74 kB, jsrender.min.js a mere 12.82 kB)
shimman|1 month ago
https://cheerio.js.org/
https://alpinejs.dev/
chao-|1 month ago
phatskat|1 month ago
karim79|1 month ago
Live on jQuery! Go forth and multiply!
alexchantavy|1 month ago
sieep|1 month ago
ei8ths|1 month ago
radicalethics|1 month ago
ksec|1 month ago
But then Google, Chrome, iPhone, PWA or JS for everything took over and took a completely different path to what I imagine webpage would be.
lrvick|1 month ago
Is there still anything jquery does you cannot easily do with a couple lines of stdlib?
simondotau|1 month ago
jampekka|1 month ago
flomo|1 month ago
Anyway, jQuery always did the job, use it forever if it solves your problems.
recursivedoubts|1 month ago
https://api.jquery.com/load/
which I found while doing some performance work at one point. intercooler.js started as a custom function that hooked .load() in based on custom attributes (a trick I learned from angular 1.x)
deeply respect and love jquery
hsbauauvhabzb|1 month ago
While presumably jquery is slower than native selectors, maybe that could be pre-computed away.
gbalduzzi|1 month ago
sgt|1 month ago
blakewatson|1 month ago
https://css-tricks.com/reactive-jquery-for-spaghetti-fied-le...
lioeters|1 month ago
Klaster_1|1 month ago
augusto-moura|1 month ago
If someone is still using jQuery for legacy reasons, BackboneJS might be a good intermediate step before going for a modern framework. Backbone is pretty light and pretty easy to grasp
[1]: https://backbonejs.org/
[2]: https://github.com/jashkenas/backbone/tags
mb2100|1 month ago
1123581321|1 month ago
kccqzy|1 month ago
insin|1 month ago
Browser extension options pages are mostly a form mapped to what you have stored in the Storage API, so implementing them by handling the change event on a <form> wrapping all the options (no manual event listener boilerplate) then calling a render() function which applies classes to relevant elements (<body> classes are so good for conditionally showing/hiding things without manually touching the DOM), updates all form fields via named form.elements and re-generates any unique UI elements makes it so un-painful to change things without worrying you're missing a manual DOM update somewhere.
My options pages are Zen Garden-ing 5 different browser-specific UI themes from the same markup to match their host browsers, which is a brittle nightmare to maintain in an app which needs to change over time rather than static demo HTML, but once you've tamed the CSS, the state handling and re-rendering is so painless I'm sticking with it for a while yet, even though it would be long-term easier if I used Preact+htm for no-build option components which know what the active theme is and can generate specific UI for it.
My favourite dirty old-school knowledge is still the named global created for an element with an id, why bother selecting an element when it's right there (once you know you need to avoid global name collisions)?. I use those suckers all the time for quick fun stuff and one-off tool pages.
davidzweig|1 month ago
jusonchan81|1 month ago
Joel_Mckay|1 month ago
gethly|1 month ago
Good times, I'm glad it is still around.
shevy-java|1 month ago
b3ing|1 month ago
altern8|1 month ago
It made it so much better to build apps vs. spaghetti jQuery.
I still have nightmares about jeeping track of jQuery callbacks
mikeaskew4|1 month ago
unknown|1 month ago
[deleted]
b65e8bee43c2ed0|1 month ago
senfiaj|1 month ago
https://youmightnotneedjquery.com/
Yes, sometimes the vanilla JS analogs are not the most elegant, but the vast majority are not terribly complicated either.
IMHO, another advantage of vanilla JS (aside from saving ~30KB) is potentially easier debugging. For example, I could find / debug the event listeners using the dev tools more easily when they were implemented via vanilla JS, since for complicated event listeners I had to step through a lot of jQuery code.
ulrischa|1 month ago
niek_pas|1 month ago
rationably|1 month ago
indolering|1 month ago
But maybe they will scope this one better: they were talking about getting 4.0 released in 2020 back in 2019!
[1]: https://github.com/jquery/jquery/pull/5077 [2]: https://github.com/jquery/jquery/issues/4299
tartoran|1 month ago
layer8|1 month ago
ulrischa|1 month ago
thm|1 month ago
thrownaway561|1 month ago
NetOpWibby|1 month ago
Incredible it's still being maintained.
giancarlostoro|1 month ago
ttoinou|1 month ago
15+ years ago I wrote a tutorial for french people about using jQuery, it got a lot of views. I hope it helped spread jQuery.
maxpert|1 month ago
Minor49er|1 month ago
nilslindemann|1 month ago
OvervCW|1 month ago
hypnot|1 month ago
KellyCriterion|1 month ago
Whats the current behemoth instead of JQ?
I perceive it as still being the de-facto standard?
Pikamander2|1 month ago
Has anyone done any benchmarks yet to see how jQuery 4 compares to jQuery 3.7?
unknown|1 month ago
[deleted]
giancarlostoro|1 month ago
netbioserror|1 month ago
NetOpWibby|1 month ago
pocketarc|1 month ago
Most of the changes are completely reasonable - a lot are internal cleanup that would require no code changes on the user side, dropping older browsers, etc.
But the fact that there are breaking API changes is the most surprising thing to me. Projects that still use jQuery are going to be mostly legacy projects (I myself have several lying around). Breaking changes means more of an upgrade hassle on something that's already not worth much of an upgrade hassle to begin with. Removing things like `jQuery.isArray` serve only to make the upgrade path harder - the internal jQuery function code could literally just be `Array.isArray`, but at least then you wouldn't be breaking jQuery users' existing code.
At some point in the life of projects like these, I feel like they should accept their place in history and stop themselves breaking compatibility with any of the countless thousands (millions!) of their users' projects. Just be a good clean library that one can keep using without having to think about it forever and ever.
wartijn_|1 month ago
shevy-java|1 month ago
goykasi|1 month ago
ethagnawl|1 month ago
MarkdownConvert|1 month ago
t1234s|1 month ago
augusto-moura|1 month ago
[1]: https://htmx.org/
indolering|1 month ago
AdrianB1|1 month ago
It was a nice ride, many thanks to the people that worked and still work on it. Not sure we'll ever see a jQuery 5, but that's life.
erichanson|1 month ago
sodafountan|1 month ago
My next question would be, is this something that OpenAI and Anthropic would train their data on? If I ask Claude Code to write an app and utilize jQuery, would it resolve to the previous version until it's retrained in a newer model?
hu3|1 month ago
they have legendary backwards compatibility.
most of the breaking changes are dropping support for ancient browsers.
so yes, LLMs are great with jQuery.
thr0waway001|1 month ago
Thank you for everything you've done for us.
thrownaway561|1 month ago
bikamonki|1 month ago
Thanks guys!
markandrewj|1 month ago
zghst|1 month ago
padjo|1 month ago
madduci|1 month ago
nchmy|1 month ago
tanseydavid|1 month ago
tracker1|1 month ago
yread|1 month ago
g947o|1 month ago
Looks like the core behavior doesn't change, something that people complain about, e.g. https://github.blog/engineering/engineering-principles/remov...
> This syntax is simple to write, but to our standards, doesn’t communicate intent really well. Did the author expect one or more js-widget elements on this page? Also, if we update our page markup and accidentally leave out the js-widget classname, will an exception in the browser inform us that something went wrong? By default, jQuery silently skips the whole expresion when nothing matched the initial selector; but to us, such behavior was a bug rather than a feature.
I completely agree with this, because I have been bitten so many times by this from subtle bugs. However I can see some other people not caring about any of it.
I already know that I am definitely not going to use jQuery in my personal projects, and there is no chance that my workspace does. (I much prefer letting a framework handle rendering for me based on data binding.) So none of that concerns me. But good luck to jQuery and anyone who sticks with it.
masfoobar|1 month ago
Before jQuery, I had vanilla JS code that factored in Safari, Firefox, Opera... and... IE6, IE7, and then IE8 which was (from memory) recent at the time.
Trying to design a visual drag n' drop editing interface on the web was a chore at the time especially with the differences in IE browsers! It was suprising how many customers were still using IE6!
A lot of this is purely by memory, now. I even have shivering memories reminding myself I was using VB.NET with ASP.NET Web forms. I really HATED it!
I remember ASP.NET provided dynamic web pages with things like Placeholder tag, etc. Again, It felt bloated even back then but I made it work. It was a balance of using what was recommended by other developers, and trying to ensure performance is good.
By around end of 2009, I tried jQuery as an experimental branch and very impressed with its capabilities. Despite being a decent Javascript developer at the time I was inexperienced with AJAX (Technically I was a Junior dev in ways) but jQuery shows me the way. It was not long before I ditched certain features of .NET Web Forms for jQuery.
At the time, there may have been a little overhead replacing various javascript code I am written with jQuery but the rewards were high. It was cleaner frontend and backend code, thanks to simple AJAX calls.
Since then I've always had huge respect for jQuery! While I don't consider myself a decent javascript as I don't use it much. However, when I do come back to web development, I cannot be asked with the modern ways. To me it's bloat. I just stick with htmx, now. If I have do some fancy things visually then I will use jQuery.
johanyc|1 month ago
modarts|1 month ago
thunderfork|1 month ago
There's probably some corner-case stuff it still makes easier if you're not using some framework, but I don't think there's a reason to go out of your way to use it just for the sake of using it.
hu3|1 month ago
maybe use Vue or something like mithril which doesn't require build. But jQuery is short and easy to grasp.
nprateem|1 month ago
alphax314|1 month ago
hk1337|1 month ago
I’m glad JavaScript has evolved to the point we don’t need jQuery anymore.
nashashmi|1 month ago
admiralrohan|1 month ago
temporallobe|1 month ago
JQ is also used in frameworks like Bootstrap (although I think they’re trying to drop third-party dependencies like this since they tend to cause conflicts).
I have also used JQ in an Angular app where complex on-the-fly DOM manipulation just isn’t practical with standard tooling.
hotgeart|1 month ago
rtbruhan00|1 month ago
kordlessagain|1 month ago
unknown|1 month ago
[deleted]
recursivedoubts|1 month ago
kordlessagain|1 month ago
tpoacher|1 month ago
fourseventy|1 month ago
thrownawaysz|1 month ago
[deleted]
pseudocomposer|1 month ago
unknown|1 month ago
[deleted]
tonijn|1 month ago
gocsjess|1 month ago
nchmy|1 month ago
maxloh|1 month ago
[0]: https://bundlephobia.com/package/jquery@4.0.0
[1]: https://bundlephobia.com/package/preact@10.28.2
topspin|1 month ago
Is there some outlier place where people using virtual DOM frameworks don't also include 100-200kb of "ecosystem" in addition to the framework?
I suppose anything is possible, but I've never actually seen it. I have seen jQuery only sites. You get a lot for ~27kB.
onion2k|1 month ago