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

251–260 of 266 posts

Re: JavaScript Bloat in 2024

#252

Post by kcrwfrd_ »

wruza wrote: post #32

10MB, 12MB, … Compare it to people who really care about performance — Pornhub, 1.4 MB Porn was always actual web hi-tech with good engineering, not these joke-level “tech” giants. Can’t remember a single time they’d screw up basic ui/ux, content delivery or common sense.

Looks like us at playboy.com/app have Pornhub beat, with our 1.1 MB (when authenticated—when not, it's 993 kB).

Re: JavaScript Bloat in 2024

#253

Post by smsm42 »

diggan wrote: post #105
devjab wrote: post #52

Earlier quoted context omitted.

I never really understood why SPAs became so popular on the web. It’s like we suddenly and collectively became afraid of the page reload on websites just because it’s not a wanted behaviour in actual web applications. I have worked with enterprise applications for two decades, and with some that were build before I was born. And I think the React has been the absolute best frontend for these systems compared to every…

> But for something like pornhub? Well PHP serves them just fine, Kind of fun to make this argument for Pornhub when visiting their website with JavaScript disabled just seems to render a blank page :) > how many people still vastly prefer the old.reddit.com site to their modern SPA Also a fun argument, the times I've seen analytics on it, old.reddit.com seems to hover around/below 10% of the visitors to subs. But I…

> visiting their website with JavaScript disabled just seems to render a blank page :)

Average people don't disable Javascript. So they predictably don't spend much time trying to make the site work for people who aren't their core audience.

Re: JavaScript Bloat in 2024

#254

Post by jauntywundrkind »

ivanjermakov wrote: post #231
jauntywundrkind wrote: post #230

It sucks that we blew up CDNs for security reasons. How nice it would be if sites using React could use the React already in cache from visiting another site! I keep wanting to have some kind of technical answer possible here. Seems hard. And who cares, because massive bundles are what we do now anyways, in most cases. But it sucks that the web app architecture and web resource architecture are both massively less ca…

Empty React app is ~400KB uncompressed AFAIR. So just CDNs wouldn't drastically improve the situation.

React was one example, of a library that might be used repeatedly. The premise isn't that react and react alone's core lib is reused (did you include react.dom too?), but that many different libs become cached over time & space.

Re: JavaScript Bloat in 2024

#256

Post by niutech »

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)

Figma uses WASM, so its total size is much bigger: https://www.figma.com/blog/figma-faster/

Re: JavaScript Bloat in 2024

#257

Post by pama »

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.…

From the article: “To be honest, after typing all these numbers, 10 MB doesn’t even feel that big or special. Seems like shipping 10 MB of code is normal now. If we assume that the average code line is about 65 characters, that would mean we are shipping ~150,000 lines of code. With every website! Sometimes just to show static content! ”

Re: JavaScript Bloat in 2024

#258

Post by jerbear4328 »

lukaqq wrote: post #164
lukaqq wrote: post #24

Chillin, https://chillin.online/app/editor , integrated complete video editing functions, just for 1.8MB

By re-confirmed, the 36MB ffmpeg.wasm file is compressed by brotli to 9.6 MB as transferred.

Oh, nice! Compression is magical nowadays.

Re: JavaScript Bloat in 2024

#259

Post by andelink »

user432678 wrote: post #165
d1sxeyes wrote: post #158

Earlier quoted context omitted.

It does. You can download playlists on Apple Music (or even use your own files with it, a rarity in the post-cloud world). Maybe OP was talking specifically about the behaviour of Spotify?

To be honest the offline support of Apple Music even though exists, is on par with Spotify. It will bug you about “turn on wifi, you’re offline”, ask you to provide or update payment information, fail at synchronisation time to time with music purchased on iTunes, and overall work unreliably when you just want to listen to some songs you’ve copied from your physical CD’s. Like the whole thing trying hard to push you…

I’ve never had a problem with Apple Music offline. It works great.

Re: JavaScript Bloat in 2024

#260

Post by littlecranky67 »

blue_pants wrote: post #118
crooked-v wrote: post #68

Earlier quoted context omitted.

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?

Yes, next/image which is part of Next.js Framework
Post reply on HN