If you're a modern framework user, you may laugh at jQuery but somehow it's still widely used and even frontend newcomers often begin their dev journey with the devil $. I wrote this article for both - jQuery users and those who use modern frameworks to make them aware that while we're focusing on high level framework related problems, there are still incoming jQuery folks.
Why people choose it over frameworks? ...I don't know, maybe it's because the entry tech barrier isn't that high. It doesn't require many tools and libs in order to start adding interactivity here and there. Also, it uses selectors many of which you can use in a regular document.querySelector() or document.querySelectorAll() these days. Anyway, I'm not a fan boy of jQuery, so enough of this attempt of understanding why. And, I think you shouldn't use it anymore nor bother learning it, unless you like learning for the sake of learning. I'm not going to even say it's OK to use it in small projects because many of them quickly evolve to bigger ones.
Why not $
- There is already native support of
document.querySelector()anddocument.querySelectorAll() - ES6+ brought plenty of native goodies you can use instead of the jQuery's "convenience" functions. I mean, I have nothing against shortcuts in dev but what I've been seeing often is that people become the prisoners of their tools. They are forcing themselves to use jQuery for every possible piece of logic, even though it could be done simpler natively.
- Modern web apps must be interactive but at the same time maintainable. And, keeping data in HTML and reshaping it with manual DOM manipulations leads to repetition and multiple sources of truth. It becomes a mess which doesn't scale.
- For styling, there is a sophisticated technology called CSS. So, you don't need to
.show()or.hide() - Styling directly from JS (using
.css()), despite the fact it makes my eyes bleeding, leads to repetition and just violates what CSS stands for. As a reminder, it's a cascading style sheets ...and I won't go on this. - Abstracting away things like:
element.addEventListener('click', ...)with:element.click(...)doesn't bring any benefits anymore and renaming the native JS API causes unnecessary confusion.
Why being reactive
By reactive, I don't mean using React and if I would promote anyone here I would SolidJS but it's something for a different article. It's about a conceptual model which is built on the following pillars:
- A classical separation of structure (HTML), styles (CSS) and any dynamic interactions (JS).
- Separation of data from the view inspired by a family of MV* patterns.
- Declarative way of constructing UI which means the markup can be understood as a DSL describing UI in its any possible states driven by outside data.
- Modularisation, personally I value pure functions over classes and their pureness gives the self-contained feel you'd expect from a component.
So why being reactive? There is already a few hints above, but let me explain it a bit further. It's certainly not about being fancy and a CV-driven development or whatsoever. It provides real benefits. It gives you a long-term maintainability and helps you tweak your projects without the need of understanding the whole codebase. In short, it makes your and your teammates lives more enjoyable and allows you to deliver more features sooner without breaking everything around (automated tests would be a cherry on the cake).
Objections
So if you're are a jQuery guy, you might be moaning that it's all cool but with jQuery you can jump straight into adding stuff. Other tools require bazillion of tools around the main tool. So, from toggling an element you have to go through the whole spectrum of skills and there is no time for that. The budget is tight...
Well, I totally get it. But, you can't sacrifice all the aspects of decades of dev evolution only because something seems to be simpler.
There are many great frameworks out there, starter boilerplates and automation tools. Since I write this article as an owner of such a tool, and I genuinely believe I significantly lowered the tech-barrier for newcomers and the simplicity enthusiasts, I'll allow myself for self-promotion.
So, dear jQuery developer: what if I told you that I made a tool which lets you jump straight into coding ultra-fast apps that scale? And, that you'd be using classic HTML, CSS and JS without worrying about any glueing code. It would be preorganised, and you'd be driving your UI states declaratively by data by using HTML attributes. Would it be cool? So here: 👉 GlueCodes Studio, go and just enjoy writing reactive apps which you can export to self-contained SolidJS codebase. Whether you experienced or new to frontend dev, with a little of learning, I'm sure you will never want to get back to jQuery.
🙏 Let me know if anything above got your interest and I'd be glad to guide you through the mental conversion going from jQuery to the reactiveness.
Top comments (4)
Hello Chris. No offence. jQuery is there, it will be still be there for years to come and I will keep using it until its wiped out from this world unless otherwise there is a "real" reason for my own needs to do so otherwise. I see jQuery as a convenience library that takes away the burdon of thinking too many scenarios away from my shoulders. I mean I am not against using plain javascript but then $('.someclass') selector is enough for me to stick using it. Otherwise I would still have my own convenience function to do exactly what $('.someclass') does. $.each is another - although i will admit I prefer plain javascript depending on the scenario.
My opinion is for developers to use whatever works for them and their team the best. jQuery is not an evil. You might want to call it that but that does not make it an evil.. You may be coding in plain javascript and the whole thing might be evil itself. What we should be promoting for devs to do is to learn clean coding whether it be jQuery or javascript or any other language for that matter.
Thanks for sharing your thougts. I see your point, I think jQuery can be used in a clean way but it requires a lot of self-discipline. And I think it's something unrealistic to expect from newcomers. Ultimately we get poorly made websites made by people who don't know plain JS. But, I guess I might be a bit radical and there are simple cases when jQuery just works...
I 100% agree with you. I'm a Web developer and designer. I make apps in react. But Tbh when it comes to websites. The amount of jquery I have to write is minimal. I have written animation sequences that are triggered by add class remove class. I don't see the need for other frame works Tbh. Jquery will be around for years to come. I think alot of people hate it. But it's incredibly useful and as you said convenience If It didn't have a simple class selector $(".class") I'd just make my own.
Thanks for the comment. I'm rather against direct DOM manipulations. When worked with React I was finding inconvenient to add/remove classes etc. However, when I started working with SolidJS, there is a very neat concept called signals and it's useful for managing local state. Similar to React hooks but conceptually even simpler. Still, I can imagine jQuery makes sense when having HTML pages with some animations. On the other hand, the tool I've been building is exactly about using HTML and give that simple experience. OK, it's slightly extended by useful attribute directives and Solid's signals but still much closer to basics than any modern framework.