When jQuery was released in 2006, there was a seismic shift in web development. Interactive web experiences that were too difficult to build becaus...
For further actions, you may consider blocking this person and/or reporting abuse
Hating on
{LIBRARY}and telling people they are not real developers because they use{LIBRARY}= never cool, I agree. That said I personally don't see the need for jQuery anymore if it were up to me to decide on the tech stack (barring specific backwards compatibility requirements).There's nothing wrong with that. I personally use React for most of my current projects because the kinds of apps I'm building are a bad fit for jQuery.
I think that jQuery has a sweet spot where it's a really good fit: it feels best suited for building interactivity into 5-15 components on an otherwise static site. With less interactivity than that, Vanilla JS may make more sense. When you start having more than 20 interactive components, frameworks like React, Vue and Svelte make a lot of sense.
I've used jQuery, MooTools, Prototype, Dojo Toolkit and ExtJS in the past. Some of them were, and are still good for different purposes.
The thing about web development though, it moves really fast in the sense that there are new libraries and frameworks coming out literally every day. However, many of these libraries solve the same problem all over again. Instead of extending existing open source libraries, web devs tend to rewrite them, particularly JavaScript libraries. I wonder why.
A lot of web devs I met are young and dynamic, most of them are in their early/mid 20s. They are energetic and always curious to try new technologies. These are all good traits and I prefer such qualities in my team. However, they often forget that the main point of software development is to solve problems. If the tool solves the problems and fulfill the initial requirements, then it is good enough. There might be better tools out there, but you don't need to have the shiniest bleeding-edge tools out there every time, particularly if they don’t solve the initial problems.
What I often hear from web devs I know is that, because library A does one or two things better than library B, library B is automatically out-of-date and that library A is superior to B. That kind of thinking is, well, sad.
Preach!
This is very true.. as an older developer I enjoy and like that our tools are constantly evolving - and finding new and better ways of doing things is what we do every day
I also know that whatever the current fashionable method, library or framework is they'll be a new one along in a minute that everyone says is much better!
"they often forget that the main point of software development is to solve problems"
This is soo true. Nowdays we are too much biased towards discussing & arguing about tools rather than actually solving the problem.
I'm pretty young in tech industry, i don't have much experience, but i always get frustrated when a person argues/discusses about what tool to use for 2hours rather than solving the actual problem.
xD
An interesting post, Tyler, thank you for it. While I agree that there's a tool for every job, I can't help but wonder why reach for jQuery when libraries like zepto and cash are a tenfold smaller and also more performant? they give you almost all the features and allow you to plug in all the same plug-ins. Also there are other great behavior and interaction targeted libs like alpine.js that I'd recommend checking out. I feel like fighting for jQuery in 2020 is more of a novelty thing and people not willing to let go. At this point, I'd feel safe to say that if you can support evergreen users, you should never reach for jQuery (even if you check all your listed criteria), simply because there are more lightweight options available that fit the bill.. And while you can still argue that the couple tens of kilobytes are irrelevant, adding a few plug-ins of the same size really adds up (and I feel
$plugin developers are notorious for bloated code that you can't treeshake nor import dynamically with ESM etc).Would love to hear your thoughts on my take 🙏
Edit: just re-read my reply and I wanted to emphasize that I agree with you in the larger sense, just not specifically on the jQuery bit itself 100% 😅
WordPress powers 35% of sites on the Internet, and the majority of those sites are already using the copy of jQuery that's bundled with WordPress on the front end. This is even true with custom built themes: almost all of the popular WordPress form plugins use jQuery. That means almost 1/3 of sites on the Internet have already paid the jQuery penalty. If you do development on a WordPress site, you're almost certainly sending down extra bytes by including Alpine or friends.
Except it's not just WordPress. W3Techs estimates jQuery to be used on about 75% of sites on the internet.
These newer, more performant libraries are pretty cool. But most of them are developed largely by sole maintainers who could walk away at any time. jQuery–for better or worse–will outlive us.
Every time I hear talk about jQuery's performance and "right tool for the job," I'm reminded that there are a decade of "Ruby on Rails is Dead" posts floating around the Internet. Surely with Elixir, Rust, and Go, there's no reason to write Ruby on Rails in 2020!
Except there's enormous business in boring tools. Airbnb, Groupon, Github, Couchsurfing and Shopify use Rails, and they know that the future of the framework is secure. If their entire engineering department was hit by an astroid, they'd be able to find more Rails developers and the framework would still be around. Mega companies still use jQuery in their stack for the same reason: the best technology available isn't always the best technology for the business.
jQuery isn't the right tool for every job. It's not what I use the majority of the time in my day job. But it's still relevant in 2020, and it will likely still be relevant for at least another decade.
Everybody always mentions bytes sent over the network, and that's great to keep in mind, but your gzip number only tells half the story. That prepaid ~30kB network cost that you save is still 86kB of raw JavaScript for the browser to parse, every time.
And as you bring up enormous tools like GitHub etc, note that almost all of them opt for vanilla JavaScript that gets sprinkled in sparsely, and not an outdated library that costs a user a tenth of a MB to parse 🤷♂️
But I obviously can't dispute that this little conversation could change anything and that we'll of course see jQuery and friends stick around, and that's okay.
I remember my first project ever doing AJAX: I was still super new as a dev and I had promised some AJAX stuff to client that I didn't actually know how to do. I had blown off the feature until the end, and like an hour before I had to leave for the meeting, I pulled up the jQuery AJAX docs and got everything to work straight away. That was a live saver.
There are still plenty of enterprise level websites on Drupal and Wordpress or other like frameworks (or using Bootstrap.js) where jQuery is just part and parcel. If you have jQuery available already, minified and cached, rolling out your own custom vanilla javascript may not be the best option. Like you said in the article:
"The poorly documented helper functions a developer wrote ... will bite them as they onboard new developers later."
Of course a counter to that is to write well-documented helper functions, but still, there it beauty in the speed and elegance of well-maintained, cross-browser supported, chainable, utility functions and classes.
That being said, that doesn't mean I don't like writing my own functions and using modern libraries. But my feelings about such things isn't the most relevant factor in most cases.
Bootstrap is dropping jQuery dependency in the next version FYI. Source: blog.getbootstrap.com/2020/06/16/b...
There's a difference between hating on JQuery, and knowing when it's simply not worth adding the dependency for something simple.
I am by no means a fan of JQuery, but when a client requests compatibility with IE6 (Oh yeah, enterprise sure loves their "if it ain't broke") being able to drop in JQuery sure makes things a lot easier.
generally though, JQuery used to solve the problem of compatibility which is (largely) not a problem anymore (see youmightnotneedjquery.com/).
As with all tools, it's useful for it's designed use cases
I agree that knowing when it's not worth it to add a dependency for something simple is valuable. I think that jQuery's usefulness is more than just compatibility though.
jQuery is really good at DOM manipulation and has an easy-to-learn API. It's possible to write a site's back-end code in C, but most developers prefer to use something a little easier to learn and less verbose like PHP, Python or JS.
jQuery can make development a lot faster on some projects. It's not the right tool for every project, but it is for some.
jQuery definitely has a very neat API, but a lot of that API has been ported into the standard runtime (think sizzle etc), I haven't really found myself reaching back for jQuery when dealing with DOM modifications rather than the standard API (though I have to admit that adding a bunch of DOM elements can be cumbersome, that's usually the sign you're in need of something more template-like like Vue, Svelte etc when you don't need a full SPA)
While I am very happy about my conversion to Stimulus - which is actually by the creator of Prototype, which inspired jQuery - I am regularly frustrated by how some things that are easy in jQuery are still difficult and wildly non-standard in vanilla JS.
One of the best examples is the
.parents()method, which returns an array of the ancestor chain. It's not even mentioned on You Might Not Need jQuery.I have legitimate beef with jQuery's fake event system, and even wrote a Stimulus controller to map them to real events.
However, the main reason I had to move beyond jQuery is that it is stuck in the 1:1 page load/screen world that made sense when it came out, but not in an era when people use Turbolinks and other tools to make things fast. One load event just doesn't work in 2020 and that's why so many jQuery plugins are just broken, now. I wrote about this issue extensively, if you're interested.
Stimulus is a really warm pool to get into. If you love working with jQuery, Stimulus provides lifecycle events but otherwise lets you do your thing. You can even use jQuery inside Stimulus, but I suggest you just bite the bullet.
I've looked at Stimulus before, but I haven't had a good use case to try it out yet. Maybe someday when I do a Rails project!
I like Turbolinks a lot. What a silly and wonderful idea that was.
Right on. Please let me know if you have any questions.
In the meantime, it does seem important to stress that Stimulus is not a Rails thing, at all.
2 years later, are you still holding that opinion?
As a web developer who owns a project with JQuery and another with Angular I prefer JQuery, why?
Angular had so many problems over the years they had to make 14 versions of it and it still has many problems!
Each time I click save in my project it compiles and it takes 10-20 seconds till I see the result in the screen, HMR doesn't work while using lazy loaded modules so what is the point of it?
Even though React and Angular were suppose to solve bugs and give the end user a "SPA experience" of fast browsing they actually created tons of new bugs, a good example is Facebook that was written using React, they have so many bugs that I must click the refresh button a few times in every session in order for it to work properly!
Facebook are not the only ones, almost every website has errors in the console, cache that didn't get refresh, "couldn't load lazy module" etc..
Using JQuery with a module pattern is the easiest solution for me and you can combine it with typescript and .netcore and it doesn't get any better than that.
I develop much faster using JQuery and server-side rendering than Angular and I get SEO out of the box.
Well said.
Thank you for reading it 😊
Learning JavaScript Design Patterns by Addy Osmani, the link to this text seems to be broken.
Thanks for telling me, I sure messed that up. It's fixed now!
addyosmani.com/resources/essential...