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

121–130 of 266 posts

Re: JavaScript Bloat in 2024

#121

Post by lukaqq »

jerbear4328 wrote: post #84
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://wavacit…

Sorry for that, we just focus on js bundle and don't realize how big the ffmepg.wasm is. Thanks for reminding, next step we will try to rebuild ffmepg.wasm and make it smaller.

Re: JavaScript Bloat in 2024

#123

Post by figmert »

devjab wrote: post #52
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 every…

> It’s like we suddenly and collectively became afraid of the page reload on websites

I used to work at a place where page reloads was constantly an issue brought up as a negative. They couldn't be bothered to fix the slow page loads and instead avoided page changes.

I argued several times that we should improve performance instead of caring about page reloads, but never got through to anyone (in fairness, it was probably mostly cos of a senior dev there).

At some point a new feature was being developed, and instead of just adding it to our existing product, it was decided to use an iframe with the new feature as a separate product embedded.

Re: JavaScript Bloat in 2024

#124

Post by rob74 »

jjav wrote: post #103
user432678 wrote: post #98

Earlier quoted context omitted.

Re: Spotify So much agree here, the offline mode is so beyond being annoying so I even started building my own iOS offline first music app.

> my own iOS offline first music app Sadly ironic that apple used to sell this, in the shape of an ipod! I hold on to mine, it is perfect in every way that a phone is terrible. It is tiny and 100% offline, just what I need.

Wait... iOS doesn't have an offline music app anymore either? Google replaced the "Play Music" app (which could also play offline music files) with "Youtube Music" a few years ago (not sure if that works with offline files, I switched to a third party app), but I thought iOS still had one (precisely because they used to sell the iPods, specifically the iPod touch which was more or less an iPhone lacking the phone part)?

Re: JavaScript Bloat in 2024

#125

Post by lifthrasiir »

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

> 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. Almost none of those are loaded in the initial bundle, are they? All those come as data from the server. How much JS do you need for `if data.transliteration show icon with audio embed`?

> Almost none of those are loaded in the initial bundle, are they?

In my testing, at least some input methods are indeed included in the initial requests (!). And that's why I'm stressing it is not "one-interaction" app; it is interactive enough that some (but not all) upfront loading might be justifiable.

Re: JavaScript Bloat in 2024

#126

Post by agos »

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

GitHub's probably the worst example of "Pjax" or HTMX-style techniques out there at this point…I would definitely not look at that and paint a particular picture of that architecture overall. It's like pointing at a particularly poor example of a SPA and then saying that's why all SPAs suck.

is there a good example of reasonably big/complex application using pjax/htmx style that sucks less? Because GitHub isn't making a good case for that technology

Re: JavaScript Bloat in 2024

#127

Post by agos »

threatofrain wrote: post #115
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.

read it as "of the people who have a fiber connection, most..."

Re: JavaScript Bloat in 2024

#128

Post by dukeyukey »

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…

I live in London which typically gets great signal everywhere. Except in the Underground network, where they're rolling out 5G but it's not there yet.

Please Spotify, why do I need to wait 30 seconds for the app to load anything when I don't have signal? All I want to do is keep listening to a podcast I downloaded.

Re: JavaScript Bloat in 2024

#129

Post by guappa »

hnarn wrote: post #90
guappa wrote: post #59

Earlier quoted context omitted.

> 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?

It is parsed and loaded in memory, and not executed.

Re: JavaScript Bloat in 2024

#130

Post by threatofrain »

agos wrote: post #127
threatofrain wrote: post #115

Earlier quoted context omitted.

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.

read it as "of the people who have a fiber connection, most..."

Yeah, I'm saying the relevance of that statement is pretty low because most of us don't experience that, certainly not enough to tip the needle of JS culture.
Post reply on HN