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

141–150 of 266 posts

Re: JavaScript Bloat in 2024

#141

Post by wruza »

w3news wrote: post #58

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

Pretty sure the situation wouldn't change if it wasn't minified.

Recently I had to add a couple of mechanics into sd-web-ui, but found out that the "lobe theme" I used was an insufferable pile of intermingled React nonsense. Returned to sd-web-ui default look that is written in absolutely straightforward js and patched it to my needs easily in half an hour.

This is a perfect example based on a medium-size medium-complexity app. Most sites in TFA are less complex. The delusions that frontend guys are preaching are on a different level than everything else in development.

Re: JavaScript Bloat in 2024

#142

Post by diimdeep »

Remember The Website Obesity Crisis [1] article from 2015, since then [2] things only got worse, and it is been almost 10 years already, well will be next year.

Is it foolish to say that in 10 more years you wont be able to navigate the web on a circa 2015 PC ? If nothing changes seems like it.

My old macbook from 2013 with latest Firefox is already can not handle loading https://civitai.com web page with 23.98 MB of JavaScript, it is just hangs for half a minute while trying to render this disaster of web frontend.

It is not just web, mobile all in one apps got so large that 2013 phone the same way unable to load them, and guess what, half of them are written on top of web tech stack, why three comma ,,, budget companies can not afford to write native application ?

[1] https://idlewords.com/talks/website_obesity.htm

[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

Re: JavaScript Bloat in 2024

#143

Post by aembleton »

dieulot wrote: post #55

For a more complete view, the HTTP Archive tracks general site weight over time and gives you percentiles (click Show table): https://httparchive.org/reports/page-weight#bytesJs The median JS bundle is 600kB on desktop. p90 (“high 10%”) is 1830kB.

Weird spike in March 2021 in the `Other Bytes` graph. Wonder what went on then; or if there was a glitch in their data.

Re: JavaScript Bloat in 2024

#144

Post by lifthrasiir »

guappa wrote: post #129
hnarn wrote: post #90

Earlier quoted context omitted.

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.

"Loaded" part is no longer true in major JS implementations (for example, [1]).

[1] https://v8.dev/blog/preparser

Re: JavaScript Bloat in 2024

#146

Post by sbergot »

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

> Any reason why we're looking at uncompressed data? Some of the listed negative examples easily beat GMaps 1.5mb when compressed. Because for a single page load, decompressing and using the scripts takes time, RAM space, disk space (more scratch space used as more RAM gets used), and power (battery drain from continually executing scripts). Caching can prevent the power and time costs of downloading and decompressin…

While you are right that there is a cost, the real question is to know whether this cost is significant. 10 Mb is still very small in many contexts. If that is the price to pay for a better dev ex and more products then I don't see the issue.

Re: JavaScript Bloat in 2024

#147

Post by ginko »

jakelazaroff wrote: post #14

I know the implication here is "too much JavaScript" but we also need to talk about how much of this is purely tracking junk.

But surely even pieces of scummy tracking code can't take up megabytes of memory, right?! Just collect user session data and send it to some host.

Re: JavaScript Bloat in 2024

#148

Post by rgblambda »

diggan wrote: post #102
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…

> 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 sucks in so many ways Also, Spotify (at least on iOS) seems to have fallen into the trap of thinking there is only "Online" and "Offline", so when you're in-between (really high latency, or really lossy connection), Spotify thinks it's onl…

I've noticed BBC Sounds has the opposite problem. If you were offline and then get a connection it still thinks you're offline. Refreshing does nothing. You need to restart the app to get online.

Re: JavaScript Bloat in 2024

#149

Post by lifthrasiir »

aembleton wrote: post #143
dieulot wrote: post #55

For a more complete view, the HTTP Archive tracks general site weight over time and gives you percentiles (click Show table): https://httparchive.org/reports/page-weight#bytesJs The median JS bundle is 600kB on desktop. p90 (“high 10%”) is 1830kB.

Weird spike in March 2021 in the `Other Bytes` graph. Wonder what went on then; or if there was a glitch in their data.

That spike is only visible when Drupal/Magento/WordPress lenses are selected, and disappears with the top ~1M websites, so I assume it is a very long tailed behavior.

Re: JavaScript Bloat in 2024

#150

Post by subtra3t »

ustad wrote: post #62
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

The article is related to js bloat and the images are required for the presentation. The images come to 10MB - not bad. The js? 4.5KB!

> required for the presentation

But is such a high resolution really needed?

Post reply on HN