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

151–160 of 266 posts

Re: JavaScript Bloat in 2024

#151

Post by wruza »

dudus wrote: post #132
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…

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…

Personally, I don't see why one would hate SPA concept. I like it, because it enables to lower the traffic and make interactions... normal? And to use local computing when possible, instead of adding 2 and 2 over HTTP.

When people hate SPAs they actually hate terminally overweight abominations that no one (i.e. google) keeps in check, and that's the reason they are like that. Why should on-page interaction be slow or cost one 20MB of downloads? No reason. replaceChild() uses the same tech as . SPA is not a synonym for "impotent incompetence 11/10".

If humanity didn't invent SPAs, all these companies would just make half-a-minute loading .aspx-es instead. Because anything else they can not.

Re: JavaScript Bloat in 2024

#152

Post by lifthrasiir »

okaleniuk wrote: post #138

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

You can do the same with dependencies and "modern" JS toolkits. Dependency itself is not a cause but a symptom; websites and companies are no longer incentivized to reduce bloats, so redundant dependencies are hardly pruned.

Re: JavaScript Bloat in 2024

#153

Post by avgcorrection »

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

gmail is terrible, idk if it's just me but i have to wait 20 seconds are marking an email as read before closing the tab. otherwise it's not saved as read spotify has huge issues with network connectivity, even if i download the album it'll completely freak out as the network changes. plain offline mode would be better than its attempt at staying online

Gmail has this annoying preference which you can set: set email to read if viewed for x seconds. Mine was set to 3 seconds. Which is I guess why I sometimes would get a reply on a thread and I had to refresh multiple times to get rid of the unread status.

Maybe that’s related?

Re: JavaScript Bloat in 2024

#155

Post by m_rpn »

dukeyukey wrote: post #128
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.

i will never understand what all the people on the tube are doing on their phones with no internet, do they have the entirety of youtube bufferred XD?

Re: JavaScript Bloat in 2024

#156

Post by jongjong »

Just checked my SaaS platform. The entire application front end is 1.3 MB. But 300KB of that are font files and 490KB is for a cryptographic library for blockchain authentication.

The thing is; I didn't use any bundling or minification. Also, it loads faster than most of the websites mentioned in this article and that's with minimal optimizations and my server being located on the other side of the world.

Re: JavaScript Bloat in 2024

#158

Post by d1sxeyes »

rob74 wrote: post #124
jjav wrote: post #103

Earlier quoted context omitted.

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

Re: JavaScript Bloat in 2024

#159

Post by matthewhammond »

YuukiRey wrote: post #47
iamsaitam wrote: post #34

At this point, blog posts like these just look like "rage bait" for web developers.. What's the point of it? What's the alternative? The biggest reason why this topic is a topic, is due to the browser developer tools letting anyone glance at these details easily. If this wasn't a low hanging fruit blog post, it would also try to figure out if this is isolated to web development or can we see this across the board (hi…

I think it's good and important that people occasionally call this out. Same as https://news.ycombinator.com/item?id=39315585 I don't understand why you'd consider this "low hanging fruit". What could the author have done to make it a high quality submission in your eyes? The alternative is to have more awareness of the amount of dependencies you really need, of when you actually need a framework with a runtime, and…

It would be much more interesting to analyse one of the sites in detail and consider what could be done to reduce the code size, looking at where it's coming from and what it does. Or to find out why it might be that some landing pages are shipping a lot of JS (could be because they are landing pages for web apps?). Or consider performance more holistically (are pages shipping a lot of code, but lazy loading or otherwise optimising it so that pages still perform well?). Or maybe compare these web application sizes to mobile or desktop equivalents too (where it's surely easier to optimise amount of code shipped).

The article is just a lot of vague pointing at sites and insinuating (not even asserting) that they're too bloated or not. I don't get a sense of whether it's worse that Medium ships 3mb of code or Soundcloud ships 12. There's a lot of bad faith "this is just a text box" for sites which clearly do much more than that too.

Re: JavaScript Bloat in 2024

#160

Post by wruza »

thiht wrote: post #80
wruza wrote: post #35

Earlier quoted context omitted.

Pornhub will be run in incognito mode It’s not '80s anymore, nobody cares about your porn. I have bookmarks on the bookmarks bar right next to electronics/grocery stores and HN. And if you’re not logged in, how would PH and others know your preferences?

I don’t think you’re speaking for the majority here, no one has pornhub in their bookmarks bar

Yeah that was incoherent remark on my side, and there are situations where I'd put them in a folder.

But I still find going incognito to watch porn paranoid.

Post reply on HN