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

111–120 of 266 posts

Re: JavaScript Bloat in 2024

#111

Post by pavlov »

deliriumchn wrote: post #100
jspdown wrote: post #67

The state of the web is very sad. Most people with a fiber connection don't even notice how slow it became. But when you are still on a 2Mbps connection, this is just plain horrible. I'm in this case, it's terribly painful. Because of this, I can't even consider not using an ad/tracker blocker. Would love to see this test with Ublock origin enabled.

> But when you are still on a 2Mbps connection What happens when you use modern apps on iphone 3 or first nexus phone? I don't understand, do people think that with better, faster computers and network speed we should focus on smaller and smaller apps and websites?

Your iPhone CPU doesn't suddenly become an iPhone 3G CPU sometimes, but network availability does vary a lot.

You may also one day find yourself on a flaky 3G connection needing access to some web app that first loads twenty megabytes of junk before showing the 1 kB of data you need, and then it's clearer what the problem is here.

Re: JavaScript Bloat in 2024

#112

Post by meowtimemania »

Tistron wrote: post #108
djtango wrote: post #77

I recently came back from a road trip in New Zealand - a lot of their countryside has little to no cell coverage. Combined with roaming (which seems to add an additional layer of slowness) and boy did it suck to try to use a lot of the web. Also if any spotify PMs are here, please review the Offline UX. Offline is pretty much one of the most critical premium features but actually trying to use the app offline really…

Offline is still miles and miles better than patchy Internet. If spotify thinks you have Internet it calls the server to ask for the contents of every context menu, waiting for a response for seconds before sometimes giving up showing a menu and sometimes falling back to what would have been instant if it was in offline mode. I really loathe their player.

I get irritated by this too. When it happens I put my phone on airplane mode to force Spotify to show the offline ui.

Re: JavaScript Bloat in 2024

#114

Post by panstromek »

jkoudys wrote: post #19
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)

Pornhub needs to be small. Jira will download once then be loaded locally until it gets updated, just like an offline app. Pornhub will be run in incognito mode, where caching won't help.

JIRA transfers like 20MB of stuff everytime you open the board, including things like 5MB JSON file with list of all emojis with descriptions (at least the last time I profiled it).

Re: JavaScript Bloat in 2024

#115

Post by threatofrain »

jspdown wrote: post #67

The state of the web is very sad. Most people with a fiber connection don't even notice how slow it became. But when you are still on a 2Mbps connection, this is just plain horrible. I'm in this case, it's terribly painful. Because of this, I can't even consider not using an ad/tracker blocker. Would love to see this test with Ublock origin enabled.

Most people with a fiber connection? I bet a lot of people with money don't have a fiber connection, certainly not most people here on HN.

Re: JavaScript Bloat in 2024

#116

Post by jve »

Tistron wrote: post #108
djtango wrote: post #77

I recently came back from a road trip in New Zealand - a lot of their countryside has little to no cell coverage. Combined with roaming (which seems to add an additional layer of slowness) and boy did it suck to try to use a lot of the web. Also if any spotify PMs are here, please review the Offline UX. Offline is pretty much one of the most critical premium features but actually trying to use the app offline really…

Offline is still miles and miles better than patchy Internet. If spotify thinks you have Internet it calls the server to ask for the contents of every context menu, waiting for a response for seconds before sometimes giving up showing a menu and sometimes falling back to what would have been instant if it was in offline mode. I really loathe their player.

Hmm, this would also imply they would need more infrastructure at their side when they could just maybe use cached values stored locally.

Re: JavaScript Bloat in 2024

#117

Post by azangru »

panstromek wrote: post #106
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.…

Interesting that you mention GitHub file tree. I recently encountered a periodic freezing of that whole page. I've profiled for a bit and found out that every few seconds it spends like 5 seconds recomputing relative timestamps on the main thread.

> I recently encountered a periodic freezing of that whole page.

Yes; this started happening after they rolled out the new version of their UI built with React several months ago.

Re: JavaScript Bloat in 2024

#118

Post by blue_pants »

crooked-v wrote: post #68
BandButcher wrote: post #21

Earlier quoted context omitted.

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.

These days, slow-loading images usually mean that somebody hasn't bothered to use any of the automatic tooling various frameworks and platforms have for optimized viewport- and pixel density-based image sets, and just stuck in a maximum size 10+ MB image.

Could you suggest some of those automatic tools?

Re: JavaScript Bloat in 2024

#120

Post by jve »

sublinear wrote: post #3

Any piece of software reflects the organization that built it. The data transferred is going to be almost entirely analytics and miscellaneous 3rd party scripts, not the javascript actually used to make the page work (except for the "elephant" category which are lazy loading modules i.e. React). Much of that is driven by marketing teams who don't know or care about any of this. All devs did was paste Google Tag Manag…

I remember associating Google with lean and fast: Google the search (vs Yahooo) and Chrome (vs IE/FF (i'm talking about when Chrome was released))... chrome on itself had not much of an UI and it was a feature.
Post reply on HN