We Removed jQuery

> is there truly a good reason to stop using jQuery?

Nope. If you like it, and you don't have performance problems for which jQuery is a significant contributing factor (which is extremely unlikely), then keep using it.

Not really. Especially if you want to support all browsers it still does an excellent job.

External libraries often introduce unused methods, thus expanding the size of your size, which could be problematic on high traffic size.

So, if your site is small and has medium to low traffic, there's not really a "good" reason.

But if you have high traffic you might want to really squeeze every saving you can

One less thing for new developers to learn. One less thing for each visitor to download. One less thing to maintain. JQuery is probably the least obtrusive framework though, eg you do not have to rewrite all your JQuery code every 3 year due to breaking changes. Also you do not have to compile your JQuery code to JavaScript, it's already JavaScript.

It's just following the laws of Resume Driven Development.

1) If it's not on your resume it needs to be. 2) If it's already on everyone's resume you must seek alternatives 3) Resumes are never finished, only abandoned

I'm starting to feel like I should expand this into a manifesto.

I'm torn as jQuery allows dense code with it's query language, but at the same time it tends to produce brittle code that has high coupling and low cohesion, so that is hard to maintain.

I think the trade-off is that you opt for a more wholistic approach or framework that is more costly to bootstrap but easier to maintain, especially as complexity increases.

I presume it's hailed as such an unbelievable achievement because the sorry state of frontend development means just answering "what is my exposure to library X" is impossible, so scrubbing a single leaf from a 30 wide 10 deep dependency tree is unheard of.

It's an extra dependency that each user has to download, and that their browser has to parse. If you don't need it, and can avoid using it, why not?

You're right, the dogmatic opposition to jQuery tends to be unconvincing.

The reason I don't use jQuery these days is because other libraries serve jQuery's functions a little better for me.

* If I want a more robust interface for my XHR requests, there are a ton of nice libraries out there. Superagent is a good example.

* If I need utility belt stuff, I can get more out of Lodash, Ramda, etc.

* If I want animations, there are much better ways to do that nowadays, even with just basic CSS3.

* If I need distinct DOM lookup and manipulation...well, this might not be needed at all if I'm doing an SPA (in React, etc.). That said, there are compelling alternatives that I like, such as bonzo.

And then there's just the fact that you can now do an awful lot with bare Javascript.

So my argument against jQuery is less "jQuery sucks" and more "I prefer using all these other tools that cover the same surface". jQuery is still a marvel for all the conveniences it provides, and I don't think anyone should stop using it just because the cool kid says so.

I think a big part of the problem is that jQuery went from a nifty tool to do nifty things to a crutch that is abused by low-end devs.

The most recent project I took over had jQuery loading on every page. Even though jQuery was actually only used on maybe 10% of the pages. And the thing the previous developer was trying to accomplish with jQuery can be easily done in CSS.

Needless to say, that web site is now jQuery free.

because its not cool

Have you ever single stepped through the jQuery code and looked at the return stack? shudder

There's a whole lot of complexity due to cross platform browser compatibility, working around various quirks, especially in the event handling plumbing, etc. It provides some nice conveniences, but if you're not using them, you're still paying for that big fancy layer.

Also, jQuery's APIs tend to be very polymorphic and fuzzy and interpretive, taking different numbers and types of parameters, supporting multiple overloaded interfaces, wrapping and unwrapping proxies, sniffing parameter types and shuffling them around, applying various defaults and shortcuts, bending over backwards to be "fluid", etc.

That kind of dynamic code has a cost and doesn't optimize so well, compared to the simple crisp unambiguous calls with with regularly typed parameters directly into native code that the newer standard DOM APIs tend to provide.

But the worst thing about jQuery isn't its own fault, it's the way people use it. I've seen so much jQuery code that repeats selectors and other slow searching method calls again and again because the programmer apparently thought calling into jQuery was faster than using a local or instance variable, doing the expensive computation once, then re-using the result.

Or maybe it's because using local variables doesn't match with jQuery's "fluid" style of chaining method calls. As if it was bad luck to break the chain of method calls by using a local variable and giving something a name.

And many people tend to use jQuery as a crutch to avoid learning and using JavaScript itself. (This explains all the excitement about that jQuery plugin that adds and subtracts numbers.)

https://github.com/cbrandolino/jQuery-basic-arithmetic-plugi...

One reason is it should not have been there in the first place. Due to it's age, if you google / stackoverflow something, the odds are very high a jQuery response will be among the top hits. And so you end up with some jQuery dependency.

Back in the day when you had to target IE-6 that made sense - the web was so broken you really needed something it jQuery to render it sane. But that time has gone now, and I can't count the number of times the jQuery solution actually used more core than raw js.

Doing this is positively harmful. Not only is it slower and creates clashing dependencies because library A wants jQuery version B, but library Y wants version jQuery Z, it forces the programmers to learn the 10'th different way of doing something (there are always at least 10 libraries that do it). It's unnecessary because there is one thing every javascript programmer should know (and it's not jQuery) - it's modern javascript and the standard library provided by a IE9+ browser. If it can be done with a few lines that then that is how you should do it - because it makes like so much easier for those who follow you.

Your users care about page load time. If you can remove jQuery then the page will load faster. Users do not care if your CMS is bloated and written in PHP.

Drupal will have no impact on site speed if it is behind a caching proxy

As someone who has used jQuery on one project for about 10 years I disagree. Some big problems:

1. Upgrading jQuery has been hell over the years. Literally every time something wierd breaks. Major version like the 2.0 transition meant major rewrites.

2. Most of the plugins seem to of varying quality between dire and just about usable but even the best we used died and got abandoned. I've had to fork, maintain and fix a load and then most of the contributors of those plugins don't know or care about updates or forks or pull requests or are total assholes so we're doomed to maintain them forever.

4. It is terribly slow in some circumstances. You don't know this until you find some client who is using a Citrix terminal deployment and is forced to use some tail end supported version of IE. And they are the loudest complainers.

5. It's pretty difficult to get rid of it. The tentacles are right in there. That monkey is on your back forever.

6. It's huge. Core isn't but by the time you've dragged in everything in via plugins to be productive you've got a meg of insecure god knows what crap running on your front end.

Regardless of the progress in browser tech, having your stuff run like ass, which it will in the future (I know after 10 years), because it's easy and convenient is just wrong.

The goal isn't to remove one thing or the other. The goal is to improving page load time and speeding up JS rendering time. We just got to a point where jQuery was something we could do without.

> bloated and low security cms based on php

I have zero knowledge on Drupal but is this true?

bloated and low security - can't this be said about wordpress and joomla as well? what do you consider as light and high security php based CMS?

> but for ~99.7% of our pages, it's gone!

Really, mostly getting rid of something is an effective optimization; 80-20 rule applies.

100% agree.

People hate farrrrrr too much on jQuery. Sure, you should remove it when you can but the library size plus the fact it’s likely already cached on the browser from a common CDN makes it seem quite silly to go out of your way to remove it.

I actually don't fully understand how they came to the 150GB conclusion. They write:

> Before our jQuery removal refactoring, the bundle file on our most popular content type, article.min.js, was 139kb minified (gzipped 47kb). After our refactor, our jQuery-free code comes in at 50kb (gzipped 15kb).

So it sounds like they bundled jquery into article.min.js. But then they go on to write:

> This might seem trivial, but when you consider that we have over 5 million pageviews to the article content type in any given 30 days, it translates to roughly 150GB of bandwidth saved.

This then indicates that no request to their most popular javascript will be cached by clients, which seems odd. I don't think people typically mean "unique visitors" when they say "pageviews", or?

I clicked on ~5 pages on their site and my browser downloaded about 10MB. Their JQuery optimization saved them 30kB. From a bandwidth perspective, it doesn't seem so significant.

Edit: Actually I almost get upset when I browse their site. My laptop screen is 1920x1080, and their content doesn't really fit on the screen. I'm thinking about for example the "Dispatches" section on the / page. I can't even see the complete frigging boxes without scrolling. The font size of the header is crazy 150px and then the boxes underneath. Wtf. Now, this blog article reminds me of those from Netflix about how they improved some "blablabla-engine" and then they can't even be bothered to do a somewhat user friendly site.

Same here, it always looks like doing what feels cool instead of the hard features that actually matter.

Yeah, I take issue with that 150GB number. For one, it doesn't take into account browser caching, and if you're trying to save origin bandwidth, you're better off making sure you're using your CDN as well as you can than reducing your JS bundle by 30kb. I'd be very surprised if there was actually a 150GB drop in total data transferred to users over the month.

Hi there. The bandwidth measurement is purley from our JS bundle. We are saving roughly 32kb (47kb - 15kb) from our previous article bundle with jquery... so 32kb x 5 million (unique pageviews) = ~160gb so actually more than I stated in the article. Now we do use a CDN but the idea is that we would have the lowest js footprint possible especially b/c of things like 3rd party ads which we unfortunately can't control.

something like ghost/custom mumbo-jumbo cms should do the trick

I don't get "headless" CMSs. If you remove the front-end and write a custom one, you could as well use something different on the backend alltogether. The appeal for Drupal and WP is that it's possible for a layman to get a working generic web site running, isn't it? If you're developing a custom UI using JavaScript, then you're already knee-deep into webpack, asset pipelines, git, node, etc. and should be able to put together a lightweight backend using node and will prefer one where page templates are managed as files under version control, rather than via mysql.

Hi There, we have considered a decoupled Drupal architecture but being that we are primarily a publishing site, we didn't feel it was a top priority. Things like SEO are more important... However we are reevaluating this soon and are considering tools like Nuxt.js and Gatsby.js

> Our quest for greater page-speed optimizations reached a point were we considered jQuery as unnecessary overhead.

Their 'conditions for removal' are half made up of reasons they want to remove jQuery. Makes no sense.

Never said they were all "technical" reasons :)