Disclaimer 1: We actually didn't totally remove jQuery as we have a few custom features and pages that use it, but for ~99.7% of our pages, it's gone!
Disclaimer 2: The following method isn't something we recommend if you rely heavily on front-end contrib modules, authenticated traffic, or parts of Drupal 7 core that depend on jQuery.
I wonder if they considered decoupled Drupal, where Drupal functions as the CMS and API, and you can use anything you want for the front-end. I've done 3 sites this way, using Angular for the front-end, and it's been a pretty good experience.
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.
A lot of clients won't accept a custom CMS due to security concerns. Every line of code I write on the projects I mentioned before go for a security scan with a third party. Scans already cost tens of thousands of dollars, using a custom backend would drive that price up even higher. In terms of PHP CMS's for enterprise, you're very limited, and a lot of companies are moving towards Drupal.
The other major benefit is that it's (fairly) easy to swap out either the frontend or backend. If we need to migrate to another CMS, we don't have to change anything on the frontend as long as the new API confirms with the old. And vice versa for migrating to another frontend. Also if you need to create an app or any other application you already have an API.
I wouldn't necessarily use this same architecture for smaller sites, but for enterprise it's a pretty good option.
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
I always wonder - is it really worth removing jQuery. Idealistic side of me is envious of their feat. However pragmatic me says that I have 99 features in the pipeline and removing jQuery is not one of them.
The mentioned 150GB bandwidth saving surely sounds good however when I contemplate about ROI somehow I still endup thinking: it’s not worth it. Or maybe I’m just too old.
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.
> 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.
This is a missconception. The problem of multiple CDN's and various patch releases of shared libaries means the hit rate is only likely to be in the 2% region.
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.
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.
Why is it times unique page views? If I view 5 unique pages at your site, wouldn't I only have to download your JS bundle once, due to my browser cache?
Or does each page have a different bundle so that the browser cannot do any useful caching?
Legitimate question (I am not trolling), but is there truly a good reason to stop using jQuery? I get that there are now standard ways to do DOM lookups and so on, but what if you simply like jQuery's API? Can't we recognize that as one of the web's most widely installed libraries, it's practically a standard library module for the DOM and for x-browser JavaScript? Why are we so eager to get rid of it?
> 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.
If you intend to write ~5-10k of custom JS that users will need to download over some potential high traffic scenario to get rid of a ~29k gzipped dependency that is almost certainly cached already because hosted on Google's CDN or elsewhere, you might want to look at your stats and see how much caching is going on before giving this a go.
(The article says: "[...] 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." But that is utter BS that wouldn't pass a sniff test with a 10-year old who understands a modicum of browser caching and network caching.)
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 starting to feel like I should expand this into a manifesto.
<sarc>
Yes, let's give the clueless tech recruiters more ammunition to screen out otherwise qualified candidates after someone with a blog stumbles across your site and suddenly recruiters are doing machine learning-matching on resumes against "the manifesto"
</sarc>
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.
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.
That pretty much sums it up. jQuery animation can be pretty atrocious. Granted, CSS transitions/animations can also be atrocious if certain properties are being changed at the wrong times.
jQuery is going to select and manipulate elements, but it's not going to compensate for when the developer does moronic things like creating DOM elements a bajillion times with HTML strings in jQuery every time something changes, animating things in improper ways(like animating dimensional properties that cause extra redrawing before postrender), etc.
There's nothing wrong with using jQuery. I just find that I don't even need it and would much prefer to just use existing APIs in its place. If there's a compatibility issue, I can install a polyfill that's much smaller than jQuery ever will be.
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.
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.)
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.
Removing jQuery is a curious and unproductive goal to have. You should focus on things that really matter to your users.
You should also remove drupal (bloated and low security cms based on php), that's making your site ways more slow than jQuery
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.
How do you cache POST actions? Login, create account, search, purchase, ...? All those actions go through the bloated cms
It's not unusual to see 1000 to 3000 ms response time on drupal, joomla and wordpress
Umm... Well, you obviously can’t cache POST actions but you usually can cache a lot of the stuff in the response. The cache system in Drupal 8 is pretty awesome - especially when backed by Memcache or Redis.
I’d say it’s quite easy to build slow sites on any platform. I also know it’s very well achievable to build truly perfomant sites on Drupal. Also, with the sites built on top of these CMSs, performance very rarely actually becomes an issue. The number one worry with the sites is their unmaintained codebase and all the security implications that come with it.
I really like Drupal 8 and I certainly wouldn’t call it bloated. It’s extremely modular and you can enable just the things you need. What I really want, though, is that people would take better care of the sites they build on it.
Except when you don't do cached actions (all POST, like search, create an account, login, purchase, ...)
So drupal is not an issue when you serve static content.
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.
Removing jQuery would definitely improve your page loading time for a lot of reasons. You're getting rid of all those plugins you were talking about plus you get rid of jQuery itself which I remember being like 12,000 Kb? Plus as jQuery fades out there will be fewer and fewer people with your exact version of jQuery, from the exact same CDN (of which there are more now too), which would lower the chances of it already being cached.
I'd like to add on to your main point. Improving page loading speed is a major issue for some places. I've seen one and instead of fixing the issue (their awesome home made DAL) they did all kinds of things several orders of magnitute smaller in terms of the amount of time they took. Now maybe they had some hidden reason for the way they were doing things, idk. My point, if I have one, is to pay attention to what's causing the page to load slow.
jQuery itself is rarely a problem. It's a tool, just like any other library, and it's very effective at solving the problems it sets out to. But at the end of the day, it's still just a tool - and tools aren't solutions by themselves. Good application architecture usually points to the right tool for the job. I've developed on projects where jQuery, requireJS, AngularJS, Angular 2+, and React have each provided the best tool (and sometimes in conjunction with each other!) for what we needed.
They have to remove all redundant, not just jQuery.
It's almost a static site without any interactive functions. 46.9KB unzip JS still seem too much.
On another side, they have more than 30KB preloaded articles data on every page. That could be a 2nd Ajax call or a better data structure. CSS is another place I think that can be optimized.
Obviously, the Drupal settings and few JS functions are added twice and debug mode for JS bundle is enabled I bet.
58 comments
[ 3.9 ms ] story [ 32.2 ms ] threadDisclaimer 2: The following method isn't something we recommend if you rely heavily on front-end contrib modules, authenticated traffic, or parts of Drupal 7 core that depend on jQuery.
Really, mostly getting rid of something is an effective optimization; 80-20 rule applies.
The other major benefit is that it's (fairly) easy to swap out either the frontend or backend. If we need to migrate to another CMS, we don't have to change anything on the frontend as long as the new API confirms with the old. And vice versa for migrating to another frontend. Also if you need to create an app or any other application you already have an API.
I wouldn't necessarily use this same architecture for smaller sites, but for enterprise it's a pretty good option.
The mentioned 150GB bandwidth saving surely sounds good however when I contemplate about ROI somehow I still endup thinking: it’s not worth it. Or maybe I’m just too old.
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.
This is a missconception. The problem of multiple CDN's and various patch releases of shared libaries means the hit rate is only likely to be in the 2% region.
https://www.root777.com/appdev/does-using-google-libraries-a...
Developers tend to focus on their use-case too much.
> 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.
Or does each page have a different bundle so that the browser cannot do any useful caching?
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.
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
(The article says: "[...] 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." But that is utter BS that wouldn't pass a sniff test with a 10-year old who understands a modicum of browser caching and network caching.)
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.
<sarc> Yes, let's give the clueless tech recruiters more ammunition to screen out otherwise qualified candidates after someone with a blog stumbles across your site and suddenly recruiters are doing machine learning-matching on resumes against "the manifesto" </sarc>
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.
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.
jQuery is going to select and manipulate elements, but it's not going to compensate for when the developer does moronic things like creating DOM elements a bajillion times with HTML strings in jQuery every time something changes, animating things in improper ways(like animating dimensional properties that cause extra redrawing before postrender), etc.
There's nothing wrong with using jQuery. I just find that I don't even need it and would much prefer to just use existing APIs in its place. If there's a compatibility issue, I can install a polyfill that's much smaller than jQuery ever will be.
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.
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...
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.
I’d say it’s quite easy to build slow sites on any platform. I also know it’s very well achievable to build truly perfomant sites on Drupal. Also, with the sites built on top of these CMSs, performance very rarely actually becomes an issue. The number one worry with the sites is their unmaintained codebase and all the security implications that come with it.
I really like Drupal 8 and I certainly wouldn’t call it bloated. It’s extremely modular and you can enable just the things you need. What I really want, though, is that people would take better care of the sites they build on it.
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.
I'd like to add on to your main point. Improving page loading speed is a major issue for some places. I've seen one and instead of fixing the issue (their awesome home made DAL) they did all kinds of things several orders of magnitute smaller in terms of the amount of time they took. Now maybe they had some hidden reason for the way they were doing things, idk. My point, if I have one, is to pay attention to what's causing the page to load slow.
I have zero knowledge on Drupal but is this true?
That’s the exact opposite of a technical reason. Actually sound like following the hype.
Their 'conditions for removal' are half made up of reasons they want to remove jQuery. Makes no sense.
It's almost a static site without any interactive functions. 46.9KB unzip JS still seem too much.
On another side, they have more than 30KB preloaded articles data on every page. That could be a 2nd Ajax call or a better data structure. CSS is another place I think that can be optimized.
Obviously, the Drupal settings and few JS functions are added twice and debug mode for JS bundle is enabled I bet.