4 ms·

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 p

by 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.
- deleted 8y ago
  [deleted]
pjmlp 8y ago
Same here, it always looks like doing what feels cool instead of the hard features that actually matter.
wrigby 8y ago
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.
bvoran 8y ago
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.
- tzs 8y ago
  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?

by vilius 8y ago

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.

deleted 8y ago
[deleted]

pjmlp 8y ago

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

wrigby 8y ago

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.

bvoran 8y ago

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.

tzs 8y ago
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?