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

81–90 of 266 posts

Re: JavaScript Bloat in 2024

#81

Post by nsonha »

atraac wrote: post #57
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.

however big, you're only required download an app once. Next time there is an update that you cannot download, generally that won't block you from using the app at that point in time.

Re: JavaScript Bloat in 2024

#82

Post by nsonha »

troupo wrote: post #73
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…

No. Native apps are not exempt from this either. Nothing justifies the bloat

are you deliberately not getting the point for some reason? How big is considered bloated in native apps, how big can a native app can get before it hurts accessibility because people cannot download it? Is it a few MB?

Web apps are soon going to be if not already matching native apps in terms of complexity yet we are still distracted from the real problem and quibble about some arbitrary and frankly pathetic code size restriction. Fix the root problem with PWA or something.

Re: JavaScript Bloat in 2024

#83

Post by tgv »

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…

There's always a speed/storage tradeoff. Apps should be more economic too, but you download native apps once, and web apps almost every time you open them. So indeed, caching could help, but how large would your cache have to be? Big enough to hold all 50MB downloads for every website you visit? That's an awfully large cache. So I'd say economy is more necessary for web-apps than for native/store apps.

I just checked my web usage on my work computer. The last 120k opened URLs were on 8300 unique hosts. 8300 * 50MB is not feasible.

Re: JavaScript Bloat in 2024

#84

Post by jerbear4328 »

lukaqq wrote: post #24

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

Your editor downloads a 32.6MB ffmpeg WASM binary on every page load.

Throttling the network to "Slow 3G", it took over four minutes of a broken interface before ffmpeg finally loads. (It doesn't cache, either.) A port of the Audacity audio editor to web[1] with WASM takes 2.7 minutes on the same connection, so the binary is totally reasonable, but I think claiming less than 2 MB is disingenuous.

[1]: https://wavacity.com/

Re: JavaScript Bloat in 2024

#86

Post by bambax »

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.

> Would love to see this test with unblock origin enabled.

Me too. I suspect most of this code is for user tracking and ad management.

Re: JavaScript Bloat in 2024

#87

Post by shiomiru »

iamsaitam wrote: post #34

At this point, blog posts like these just look like "rage bait" for web developers.. What's the point of it? What's the alternative? The biggest reason why this topic is a topic, is due to the browser developer tools letting anyone glance at these details easily. If this wasn't a low hanging fruit blog post, it would also try to figure out if this is isolated to web development or can we see this across the board (hi…

> What's the alternative?

Many websites listed on the page don't even need JS.[0]

Consider how just a few years ago there used to be an entire suite of alternative frontends to major "web apps"/"social media platforms", which generally worked without any JS, and were created & ran by volunteers. In general, they all provided superior UX by just not loading megabytes and megabytes of tracking code; this would be the alternative.[1]

Now they are slowly evaporating: not because of lack of interest, but because it was affecting the margins of these companies, and they actively blocked the frontends.[2]

So I think of it this way: these megabytes and megabytes of JS do not serve me, the user. It's just code designed to fill the pockets of giant corporations that is running on my computer. Which is, indeed, quite infuriating.

OK, maybe not even that; after all, you get what you pay for. It's just sad that despite the technological possibilities, this is the norm we have arrived at.

[0]: Of course, there is valid use of JS, it's a wonderful technology. I'm talking about cases where you could pretty much write the whole thing in pure HTML without losing core functionality.

[1]: Well, only if there existed a viable financing model besides "selling user data to the highest bidder" :( technologically at least, it's possible.

[2]: See cases of bibliogram, teddit, libreddit, nitter, ...

Re: JavaScript Bloat in 2024

#88

Post by guappa »

mrighele wrote: post #63
420698008 wrote: post #28

Meanwhile the author has a ton of 1440p images while pegging his website width to 560px I like the conversation about web performance, but you should make sure you practice what you preach

Even if you are not using an high resolution display like the sibling comment says, the images are reasonably sized (they are a few hundreds KB each). I have seen landing pages with 20-30 MB images for no good reason.

Don't forget the ones with background videos of random diversely raced young good looking models having coffee and looking at screens while nodding.

Re: JavaScript Bloat in 2024

#90

Post by hnarn »

guappa wrote: post #59
SebastianKra wrote: post #6

Earlier quoted context omitted.

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?

I'm not a JS developer but I imagine that the amount of JavaScript code isn't the most relevant part if most of it isn't being called. I mean, if you have some particularly heavy code that only runs when you click a button, is that really parsed and causes overhead before the button is clicked?
Post reply on HN