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

161–170 of 266 posts

Re: JavaScript Bloat in 2024

#161

Post by CompuIves »

tjosepo wrote: post #26
pier25 wrote: post #22

What's up with the React site? This is embarrassing...

You can see from the recording that it's downloading the same few files from Codesandbox over and over again, as the iframes used for the examples are being unloaded and reloaded on scrolls and because the author disabled caching. The author could've scrolled forever and the number would've gone up indefinitely.

Exactly, the result would've been different if the author would not have disabled caching.

In this case it's because the iframes are loaded/unloaded multiple times, but we also spawn web workers where the same worker is spawned multiple times (for transpiling code in multiple threads, for example). In all those cases we rely on caching so we don't have to download the same worker code more than once.

Re: JavaScript Bloat in 2024

#162

Post by kmlx »

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 worked in that field. one of the main reasons adult entertainment is optimised so heavily is because lots of users are from countries with poor internet.

countless hours spent on optimising video delivery, live broadcasts (using flash back in the day, and webrtc today), web page sizes... the works.

Re: JavaScript Bloat in 2024

#163

Post by jspdown »

threatofrain wrote: post #130
agos wrote: post #127

Earlier quoted context omitted.

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.

I'm leaving in France, not off-grid and not very far from a big city. We still don't have fiber connection available yet. What I'm saying is that we are a lot in this situation, even in developed countries. Those that accept shipping 10mb bundle clearly forget that not everyone have the same connection they have in their office.

To the point where the web is mostly unusable if you don't disable ads. I'm not against ads, but the cost is just to high for my day to day use of internet.

Re: JavaScript Bloat in 2024

#165

Post by user432678 »

d1sxeyes wrote: post #158
rob74 wrote: post #124

Earlier quoted context omitted.

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

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 to use their subscription service.

Re: JavaScript Bloat in 2024

#166

Post by danabramov »

The React site part of this is not real. The author ticked "Disable cache" which means the same code (which powers the interactive editable sandboxes they're scrolling by) gets counted over and over and over as if it was different code.

If you untick "Disable cache", it's loaded once and gets cached.

Re: JavaScript Bloat in 2024

#167

Post by renegade-otter »

I often have to close a tab because my 12-core Mac mini starts heating the room and the fan sounds like it's about to fly off the axis. This is not specific to Javascript but the ad code doing this is obviously JS.

Speaks more to the general Enshitifcation of the web.

Does Web 3.0 fix this? /s

Re: JavaScript Bloat in 2024

#168

Post by alexey2020 »

gpjanik wrote: post #135

Serious question: what is the issue with these paritcular sizes? I know that features/look these websites have are definitely achievable with less JS at a higher engineering cost, but what's the problem with it? 10MB loads in two seconds on an okay-ish desktop connection (correct me if I'm wrong, but most of people don't deploy Vercel apps from their phone from a mountain range with 3G connection). The experience on…

came here to write a similar comment. Totally agree!

Focusing on a particular metric for the sake of the metric - what's the point?

Let's spend a couple months, refactor an app to generate less js just to look cool in the eyes of dev community?

Re: JavaScript Bloat in 2024

#169

Post by DanielHB »

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.

In a previous job I had to declare war against google tag manager (tool that let marketers inject random crap in your web application without developer input). Burned some bridges and didn't win, performance is still crap.

After those things it is the heavy libs that cause performance problems, like maps and charts, usually some clever lazy loading fixes that. Some things I personally ran into: - QR code scanning lib and Map lib being loaded at startup when it was actually just really small features on the application - ALL internationalisation strings being loaded at startup as a waterfall request before any other JS ran. Never managed to get this one fixed... - Zendesk just completely destroys your page performance, mandated through upper-management, all I could do was add a delay to load it

After that then it comes just badly designed code triggering too many DOM elements and/or rerenders and/or waterfall requests.

After that comes app-level code size, some lazy loading also fixes this, but it is usually not necessary until your application is massive.

Re: JavaScript Bloat in 2024

#170

Post by nickserv »

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…

There might be a legal requirement for them to make sure you accept the "I'm 18" dialog before displaying anything.
Post reply on HN