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

71–80 of 266 posts

Re: JavaScript Bloat in 2024

#71

Post by ralusek »

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…

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.

Re: JavaScript Bloat in 2024

#72

Post by guappa »

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…

> This code likely makes life hard for the developers as well.

Well if you have static pages you don't need a team of 10 developers… so there is some self interest there.

Re: JavaScript Bloat in 2024

#73

Post by troupo »

nsonha wrote: 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…

No. Native apps are not exempt from this either. Nothing justifies the bloat

Re: JavaScript Bloat in 2024

#74

Post by yomly »

thakoppno wrote: post #40
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.

> Can’t remember a single time they’d screw up basic ui/ux, content delivery or common sense. There are many, many cases of porn websites breaking the law.

Yes - writing PHP in 2024 is a crime that we should hold PH accountable for.

Re: JavaScript Bloat in 2024

#75

Post by StressedDev »

palmfacehn wrote: post #37
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…

To let us know we are not alone with our disdain. Too many JS enthusiasts paper over this insanity. The remnant lives on. "But JS is the biggest developer ecosystem in the world!"

This is not a JavaScript issue. It’s a software enginner/people issue. The question is how do you get people to care about performance, security, reliability, etc.? How do you get organizations to care about these issues?

These are hard problems and people have been complaining about software size forever. Back in the early 90s, it was bloated C++ code.

You will also see that all software continues to use more ram, more disk space, more network bandwidth etc. This trend has been going on for decades.

For example, why do we use JSON as an interchange format? It’s relatively slow (i.e. creating it and parsing it is slow), nor is it is not space efficient. Back in the 1980s, the Unix community created RPC and the RPC wire formats were much more efficient because they were binary formats. The reason we use JSON is it makes the developer’s life easier and because developers prefer ease of use to performance.

Re: JavaScript Bloat in 2024

#76

Post by gloosx »

It would be useful if author sorted the requests by size. Most of this junk anyway is analytics, heatmaps, tracking and all that bullshit. Ofc you can make <1MB sites easily with the most complex UI and functionality, but the business just doesn't demand this or care while pennies are flowing. Caching and compression is also very important especially for virtualised sites like react-dev which author did not understood, they are essential features packed and turned on in every browser and in "real-life" test i wouldn't disable them.

Re: JavaScript Bloat in 2024

#77

Post by djtango »

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 sucks in so many ways

Re: JavaScript Bloat in 2024

#79

Post by tgv »

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

Some of my (non-programming) colleagues don't seem to be able to wrap their head around image size. And someone who taught courses to communication/marketing students told me, it took 2 hours to explain resolution and all that to them, and then half even didn't get it. Yeah, I can hear you: "something that easy? must have been a bad teacher," but the concepts are rather weird for non-techies. So those people become responsible for updating the website content, and upload whatever the graphical artists show them. And designers like to zoom in, a lot, so often that's a 20MB png, where a 200kB jpeg would suffice.

Re: JavaScript Bloat in 2024

#80

Post by thiht »

wruza wrote: post #35
jkoudys wrote: post #19

Earlier quoted context omitted.

Pornhub needs to be small. Jira will download once then be loaded locally until it gets updated, just like an offline app. Pornhub will be run in incognito mode, where caching won't help.

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
Post reply on HN