11 ms·

We Removed jQuery

35 points by joegahona 8y ago

winningcontinue 8y ago
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.
- yjftsjthsd-h 8y ago
  > but for ~99.7% of our pages, it's gone! Really, mostly getting rid of something is an effective optimization; 80-20 rule applies.
invalidusernam3 8y ago
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.
- mishaor 8y ago
  something like ghost/custom mumbo-jumbo cms should do the trick
- tannhaeuser 8y ago
  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.
  - invalidusernam3 8y ago
    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.
- bvoran 8y ago
  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
vilius 8y ago
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.
- brogrammernot 8y ago
  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.
  - nextweek2 8y ago
    > 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-api-cdn-give-you-performance-benefits/ https://www.root777.com/appdev/does-using-google-libraries-a... Developers tend to focus on their use-case too much.
- nitramavfank 8y ago
  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.
pixelmonkey 8y ago
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?
- lisper 8y ago
  > 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.
- kyriakos 8y ago
  Not really. Especially if you want to support all browsers it still does an excellent job.
- asdojasdosadsa 8y ago
  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
  - ddebernardy 8y ago
    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.)
draw_down 8y ago
I like these posts because they seem to bother some people to an unreasonable degree.
js4ever 8y ago
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
- untog 8y ago
  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.
  - js4ever 8y ago
    Bloated cms means slow server response time. So users will care
    - untog 8y ago
      Not if you have a caching layer, which any site of reasonable volume does.
      - js4ever 8y ago
        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
        Kimitri 8y ago
        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.
noncoml 8y ago
> We wanted to be one of the first major consumer-publishing websites to be jQuery-free! That’s the exact opposite of a technical reason. Actually sound like following the hype.
- ZoomStop 8y ago
  > 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.
  - bvoran 8y ago
    Which one of the 4 reasons were "made up"? The last reason may not be technical but it's a reason we wanted to exploit. Looks like it worked ;)
- bvoran 8y ago
  Never said they were all "technical" reasons :)
schrodingersket 8y ago
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.
rustcharm 8y ago
I like DruPal’s TV show on MTV
intellix 8y ago
Surprised to be reading about this 5 years later
KayL 8y ago
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.

35 points by joegahona 8y ago

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.

yjftsjthsd-h 8y ago
> but for ~99.7% of our pages, it's gone! Really, mostly getting rid of something is an effective optimization; 80-20 rule applies.

invalidusernam3 8y ago

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.

mishaor 8y ago
something like ghost/custom mumbo-jumbo cms should do the trick
tannhaeuser 8y ago
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.
- invalidusernam3 8y ago
  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.
bvoran 8y ago
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

vilius 8y ago

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.

brogrammernot 8y ago
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.
- nextweek2 8y ago
  > 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-api-cdn-give-you-performance-benefits/ https://www.root777.com/appdev/does-using-google-libraries-a... Developers tend to focus on their use-case too much.
nitramavfank 8y ago
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.

pixelmonkey 8y ago

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?

lisper 8y ago
> 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.
kyriakos 8y ago
Not really. Especially if you want to support all browsers it still does an excellent job.
asdojasdosadsa 8y ago
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
- ddebernardy 8y ago
  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.)

draw_down 8y ago

I like these posts because they seem to bother some people to an unreasonable degree.

js4ever 8y ago

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

untog 8y ago
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.
- js4ever 8y ago
  Bloated cms means slow server response time. So users will care
  - untog 8y ago
    Not if you have a caching layer, which any site of reasonable volume does.
    - js4ever 8y ago
      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
      - Kimitri 8y ago
        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.

noncoml 8y ago

> We wanted to be one of the first major consumer-publishing websites to be jQuery-free! That’s the exact opposite of a technical reason. Actually sound like following the hype.

ZoomStop 8y ago
> 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.
- bvoran 8y ago
  Which one of the 4 reasons were "made up"? The last reason may not be technical but it's a reason we wanted to exploit. Looks like it worked ;)
bvoran 8y ago
Never said they were all "technical" reasons :)

schrodingersket 8y ago

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.

rustcharm 8y ago

I like DruPal’s TV show on MTV

intellix 8y ago

Surprised to be reading about this 5 years later

KayL 8y ago

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.