Live data from Hacker News

JavaScript Bloat in 2024

tonsky.me

91–100 of 266 posts

Re: JavaScript Bloat in 2024

#93
post #41
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…

If Atlassian did't use a full minute to update a certain roadmap view on my MBP from January I would be one step closer to agreeing with you even if it was still 50 MB. But I am old enough to remember Gannt charts didn't use to take that long on old Pentium processors back in school, way before Git was invented. Another thing is the sheer yuck of it: If a typical web app was lots of business code, maybe. But when you…

yes, the problem with the narrative is that web apps that are logic heavy are lumped together with content based sites who cannot justify their code bloat.

Re: JavaScript Bloat in 2024

#95

Earlier quoted context omitted.

Was going to mention this, almost any company's brand site will have tracking and analytics libraries set in place. Usually to farm marketing and UX feedback. Whats worse is some of them are fetched externally rather than bundled with the host code thus increasing latency and potential security risks

im pro privacy, but is it really so bad to get anonymous data about where people clicked and how long they stayed where? it would be almost impossible to measure success without it, whether it's a conversion funnel or tracking usage of a new feature

How should we feel if when we learn that due to technical constraints, Stasi wasn’t able to measure how successful it was?

Re: JavaScript Bloat in 2024

#96

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…

100% agree. Most of these apps could definitely use some optimization, but trivializing them to something like "wow few MBs of javascript just to show a text box" makes this comparison completely useless

Re: JavaScript Bloat in 2024

#97
post #86
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.

Tracking is a bit heavy, but from what I've looked at, the app code is usually much worse. I've looked at what Instagram and JIRA ship during the initial load and it's kinda crazy.

Re: JavaScript Bloat in 2024

#98
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…

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.

Re: JavaScript Bloat in 2024

#99
post #71
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…

I love SPAs. I love making them, and I love using them. The thing is, they have to be for applications . When I'm using an application, I am willing to eat a slower initial load time. Everything after that is faster, smoother, more dynamic, more responsive.

> Everything after that is faster, smoother, more dynamic, more responsive.

IF and only IF you have at least med- to high-end computer and smartphone. If you have low-end hardware you first have to wait for that 20MB to load AND get to use slow and choppy app afterwards. Worst of both worlds, but hey, it's built according to modern standards!

Re: JavaScript Bloat in 2024

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

> But when you are still on a 2Mbps connection

What happens when you use modern apps on iphone 3 or first nexus phone? I don't understand, do people think that with better, faster computers and network speed we should focus on smaller and smaller apps and websites?

Post reply on HN