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

131–140 of 266 posts

Re: JavaScript Bloat in 2024

#131

Post by jnsaff2 »

Tistron wrote: post #108
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…

Offline is still miles and miles better than patchy Internet. If spotify thinks you have Internet it calls the server to ask for the contents of every context menu, waiting for a response for seconds before sometimes giving up showing a menu and sometimes falling back to what would have been instant if it was in offline mode. I really loathe their player.

Not only that, there are many apps with no online aspect to them that have facebook sdk or some other spyware that does a blocking call on app startup and the app won't start without it succeeding, unless you are completely offline.

Especially annoying when one is using dns based filtering.

Re: JavaScript Bloat in 2024

#132

Post by dudus »

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…

Why SPAs became popular? Because they "feel" native on mobile. Now you have page transitions and prefetch which really should kill this use case.

IMO the bloat he talks about on the post is not representative of 2024. Pretty much all frontend development of the last 2 years has been moving away from SPAs with smaller builds and faster loading times. Fair enough it's still visible in a lot of sites. But I'd argue it's probably better now than a couple years ago.

Re: JavaScript Bloat in 2024

#134

Post by atraac »

nsonha wrote: post #81
atraac wrote: post #57

Earlier quoted context omitted.

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

It actually depends, developer can block you from using the app until you update, either themselves or through Play Store's 'Immediate updates'.

Re: JavaScript Bloat in 2024

#135

Post by gpjanik »

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 the websites mentioned is smooth as it can only get; everything is super fast and nice. Every subsequent click is just instant action. That's how web should look like.

Is the problem here that they perform poorly on slower computers/connections? Is it even true? Is there an audience of developers who can't use Vercel or GitLab productively because of that? Any metrics to support that? IMHO optimizing against bundle size/JS sent over the network is one of the worst metrics for performance I could imagine.

Re: JavaScript Bloat in 2024

#136

Post by ozim »

figmert wrote: post #123
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…

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

Oh my god iframes should be removed from browsers so no one should be able to use them ever.

Re: JavaScript Bloat in 2024

#137

Post by jwr »

I have a large and complex (ERP/MRP/inventory system for electronics) ClojureScript application and I was worried about my compiled code size being around 2.45MB.

This puts it into perspective. I heard complaints about ClojureScript applications being large, which I think is true if you write a "Hello, world!" program, but not true for complex applications.

Also, Google Closure compiler in advanced compilation mode is a great tool. Of course, since it is technically superior, it is not in fashion, and since it is hard to use correctly, people pretend it isn't there.

Re: JavaScript Bloat in 2024

#138

Post by okaleniuk »

Meanwhile, all the pages on https://wordsandbuttons.online/ with all the animation and interactivity are still below 64 KB.

This one, for example, https://wordsandbuttons.online/trippy_polynomials_in_arctang... is 51 KB.

And the code is not at all economical. It's 80% copy-paste with little deviations. There is no attempt to save by being clever either, it's all just good old vanilla JS. And no zipping, no space reduction. The code is perfectly readable when opened with the "View page source" button.

The trick is - zero dependency policy. No third party, no internal. All the code you need, you get along with the HTML file. Paradoxically, in the long run, copy-paste is a bloat preventor, not a bloat cause.

Re: JavaScript Bloat in 2024

#140

Post by lifthrasiir »

vendiddy wrote: post #133

I'm inspired to slim down my own app. Any good tools or techniques out there to identify what's causing bloat?

In general, look for dependencies. Any popular enough bundlers should have a feature or plugin to show the bundle statistics (e.g. webpack-bundle-analyzer or rollup-plugin-analyzer). Audit your dependency to see if that's not requested nor needed, and try to remove them with a finer-grained dependency or leaner library or rewriting, in the order of preference. That alone is enough for usual JS apps, because not much people do so...
Post reply on HN