Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Bloat in 2024

tonsky.me

Post reply on HN
Print view View original

21–30 of 266 posts

Re: JavaScript Bloat in 2024

#21

Post by BandButcher »

lifthrasiir wrote: post #11

One thing completely ignored by this post, especially for actual web applications, is that it doesn't actually break JS files down to see why it is so large. For example, Google Translate is not an one-interaction app once you start to look further; it somehow has dictionaries, alternative suggestions, transliterations, pronunciations, a lot of input methods and more. I still agree that 2.5 MB is too much even after…

Don't want to hate on the author's post but the screenshots being slow to load made me chuckle, understandable as images can be big and there were a lot, but just found it a little ironic.

Re: JavaScript Bloat in 2024

#23

Post by tadfisher »

BandButcher wrote: post #20
jakelazaroff wrote: post #14

I know the implication here is "too much JavaScript" but we also need to talk about how much of this is purely tracking junk.

Was going to mention this, almost any company's brand site will have tracking and analytics libraries set in place. Usually to farm marketing and UX feedback. Whats worse is some of them are fetched externally rather than bundled with the host code thus increasing latency and potential security risks

> Whats worse is some of them are fetched externally rather than bundled with the host code thus increasing latency and potential security risks

Some vendor SDKs can be built and bundled from NPM, but most of them explicitly require you fetch their minified/obfuscated bundle from their CDN with a script tag. This is so they don't have to support older versions like most other software in the world, and so they can push updates without requiring customers to update their code.

Try to use vendors that distribute open-source SDKs, if you have to use vendors.

Re: JavaScript Bloat in 2024

#25

Post by chuckadams »

Jeepers, how does this even happen? I've been developing a fairly complex app with Nuxt, Apollo client, and PrimeVue, and paid no attention to size whatsoever. Yet the most complex page in the app with the most module dependencies loads only 3.8 megs, and that's not even a minified build. Same page from the Nuxt dev server throws 24.4M at me, but I'm pretty sure it's pre-loading everything. Do the big players just not do any code splitting at all?

On the other hand, node_modules weighs in at 601M. Sure I've got space to burn on the dev box, but that's reason #1 I'm not doing yarn zero-install and stuffing all that into the repo.

Re: JavaScript Bloat in 2024

#26

Post by tjosepo »

pier25 wrote: post #22

What's up with the React site? This is embarrassing...

You can see from the recording that it's downloading the same few files from Codesandbox over and over again, as the iframes used for the examples are being unloaded and reloaded on scrolls and because the author disabled caching.

The author could've scrolled forever and the number would've gone up indefinitely.

Re: JavaScript Bloat in 2024

#27

Post by hdjrudni »

chuckadams wrote: post #25

Jeepers, how does this even happen? I've been developing a fairly complex app with Nuxt, Apollo client, and PrimeVue, and paid no attention to size whatsoever. Yet the most complex page in the app with the most module dependencies loads only 3.8 megs, and that's not even a minified build. Same page from the Nuxt dev server throws 24.4M at me, but I'm pretty sure it's pre-loading everything. Do the big players just no…

I'm at 329 kB of JS. I've been building on the same app for 10 years. That's a lot of cruft build up. And I'm still nowhere close to any of these numbers. I've got React, jQuery, lodash, and I don't know what else in there.

Re: JavaScript Bloat in 2024

#29

Post by latency-guy2 »

mewpmewp2 wrote: post #16
PetitPrince wrote: post #2

This compares how much Javascript is loaded from popular sites (cold loaded). Some highlights: - PornHub loads ~10x less JS than YouTube (1.4MB vs 12MB) - Gmail have an incomprehensible large footprint (20MB). Fastmail is 10x ligthter (2MB). Figma is equivalent (20MB) while being a more complex app. - Jira has 58MB (whoa)

YouTube feels really snappy to me, but Figma is consistently the worst experience I have ever felt for web apps. Jira is horrible and slow also though.

YouTube does not feel snappy to me anymore, its still one of the better experiences I have on the internet, but quite bad from years before.

I just tested my connection to youtube right now, just a tiny bit over 1.2 seconds from not using it for a few days. A fresh, no cache, no cookies, the entire page loaded in 2.8 seconds. A hot reload on either side varied between 0.8s to 1.4 seconds. All done with at most ublock as an extension on desktop chrome with purported gigabit speeds from my ISP.

That speed is just OK, but definitely not the 54ms response time I got to hit google's server to send me the HTML document that bears all the dynamic content on youtube

Figma is very surprising to me, that bullshit somehow is PREFERRED by people, getting links from designers from that dogshit app screeches my browser to speeds I haven't seen in decades, and I don't think I'm exaggerating at all when I say that

Re: JavaScript Bloat in 2024

#30

Post by willsmith72 »

SebastianKra wrote: post #4

Any reason why we're looking at uncompressed data? Some of the listed negative examples easily beat GMaps 1.5mb when compressed. Also, I'll give a pass to dynamic apps like Spotify and GMail [1] if (and only if) the navigation after loading the page is fast. I would rather have something like Discord which takes a few seconds to update on startup, than GitLab, which makes me wait up to two seconds for every. single.…

gmail is terrible, idk if it's just me but i have to wait 20 seconds are marking an email as read before closing the tab. otherwise it's not saved as read

spotify has huge issues with network connectivity, even if i download the album it'll completely freak out as the network changes. plain offline mode would be better than its attempt at staying online

Post reply on HN