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

51–60 of 266 posts

Re: JavaScript Bloat in 2024

#51

Post by realusername »

SebastianKra wrote: post #6
acdha wrote: post #5

Earlier quoted context omitted.

Compression helps transfer but your device still has to parse all of that code. This comes up in discussions about reach because there’s an enormous gap between iOS and Android CPU performance which gets worse when you look at the cheaper devices a lot of the public use where new Android devices sold today perform worse than a 2014 iPhone. If your developers are all using recent iPhones or flagship Android devices, i…

I happen to develop a JS-App that also has to be optimised for an Android Phone from 2017. I don't think the amount of JS is in any way related to performance. You can make 1MB of JS perform just as poorly as 10MB. In our case, the biggest performance issues were: - Rendering too many DOM nodes at once - virtual lists help. - Using reactivity inefficiently. - Random operations in libraries that were poorly optimised.…

You can theoretically have a somewhat fast enough large JS app but it's going to be an uphill battle.

You have to make regular bundle analysis otherwise the cache won't work if you deploy too much and package updates and new additions are likely to break the performance analysis you've just made before.

Less JS = better performance is a simplified model but very accurate in practice in my opinion, especially on large teams.

Re: JavaScript Bloat in 2024

#52

Post by devjab »

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.

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 everything that came before. You’re free to insert Angular/Vue/whatever by the way. But these are designed to replace all the various horrible client/server UIs that came before. For a web-page that’s hardly necessary unless you’re g-mail, Facebook or similar, where you need the interactive and live content updates because of how these products work. But for something like pornhub? Well PHP serves them just fine, and this is true for most web sites really. Just look at HN and how many people still vastly prefer the old.reddit.com site to their modern SPA. Hell, many people still would probably still prefer an old.Facebook to the newer much slower version.

Re: JavaScript Bloat in 2024

#53

Post by BlueTemplar »

acdha wrote: post #5
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.…

Compression helps transfer but your device still has to parse all of that code. This comes up in discussions about reach because there’s an enormous gap between iOS and Android CPU performance which gets worse when you look at the cheaper devices a lot of the public use where new Android devices sold today perform worse than a 2014 iPhone. If your developers are all using recent iPhones or flagship Android devices, i…

Even decently powerful phones can have issues with some of these.

Substack is particularly infuriating : sometimes it lags so badly that it takes seconds to display scrolled text (and bottom of text references stop working). And that's on a 2016 flagship : Samsung Galaxy S7 ! I shudder to think of the experience for slower phones...

(And Substack also manages to slow down to a glitchy crawl when there are a lot of (text only !) comments on my gaming desktop PC.)

Re: JavaScript Bloat in 2024

#54

Post by pkphilip »

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)

No idea why an email client should have 20 MB of JS.

Re: JavaScript Bloat in 2024

#57

Post by atraac »

nsonha wrote: post #39

it's always bothered me that this dogma exists. Somehow web apps need to be super frugal with code size, while apps distributed on other (native) platforms never have such a problem. Somehow it's the bloated web that blocks the access for children in Affrica, but they can download bloated android apps just fine? Maybe, just maybe, the problem isn't the size of the javascript, it's how broken the entire web stack (spe…

> while apps distributed on other (native) platforms never have such a problem

Could you give an example? I was an android app dev over 5 years ago and there was a huge push for lower app size everywhere. Google even made Android App Bundles to fight this issue specifically.

Re: JavaScript Bloat in 2024

#58

Post by w3news »

So true, we build large complex frameworks, abstractions over abstractions. Try to make things easy to build and maintain. But I think the problem is that many developers that using these frameworks not even know the Javascript basics. Of course there are smart people at these large companies. But they try to make things easy instead of learn people the basics. We over engineer the web applications, create too much layers to hide the actual language. 20 years ago, every web developer can learn building websites by just check the source code. Now you can see the minified Javascript after a build, and nobody understand how it works, even the developers that build the web application don't recognize the code after the build. I love Javascript, but only pure Javascript, and yes, with all his quirks. Frameworks don't protect you from the quirks, you have to know it so you don't make quirks, and with all the abstraction layers, you not even know what you are really building. Keep it simple, learn Javascript itself instead of frameworks, and you downsize the Javascript codebase a lot.

Re: JavaScript Bloat in 2024

#59

Post by guappa »

SebastianKra wrote: post #6
acdha wrote: post #5

Earlier quoted context omitted.

Compression helps transfer but your device still has to parse all of that code. This comes up in discussions about reach because there’s an enormous gap between iOS and Android CPU performance which gets worse when you look at the cheaper devices a lot of the public use where new Android devices sold today perform worse than a 2014 iPhone. If your developers are all using recent iPhones or flagship Android devices, i…

I happen to develop a JS-App that also has to be optimised for an Android Phone from 2017. I don't think the amount of JS is in any way related to performance. You can make 1MB of JS perform just as poorly as 10MB. In our case, the biggest performance issues were: - Rendering too many DOM nodes at once - virtual lists help. - Using reactivity inefficiently. - Random operations in libraries that were poorly optimised.…

> You can make 1MB of JS perform just as poorly as 10MB.

But can you make a 10MB js perform as good as a good 1MB js?

Re: JavaScript Bloat in 2024

#60

Post by advael »

I have to also wonder what percentage of each of those web logic figures come from code that's there to silently do telemetry rather than part of e.g. a UX framework
Post reply on HN