Hacker News new | past | comments | ask | show | jobs | submit
zdc1 | on: The three pillars of JavaScript bloat
A lot of this basically reads to me like hidden tech debt: people aren't updating their compilation targets to ESx, people aren't updating their packages, package authors aren't updating their implementations, etc.

Ancient browser support is a thing, but ES5 has been supported everywhere for like 13 years now (as per https://caniuse.com/es5).

loading story #47481780
anematode | parent | next
The desire to keep things compatible with even ES6, let alone ES5 and before, is utterly bizarre to me. Then you see folks who unironically want to maintain compatibility with node 0.4, in 2025, and realize it could be way worse....

Ironically, what often happens is that developers configure Babel to transpile their code to some ancient version, the output is bloated (and slower to execute, since passes like regenerator have a lot of overhead), and then the website doesn't even work on the putatively supported ancient browsers because of the use of recent CSS properties or JS features that can't be polyfilled.

I've even had a case at work where a polyfill caused the program to break. iirc it was a shitty polyfill of the exponentiation operator ** that didn't handle BigInt inputs.

Slothrop99 | root | parent | next
Maybe I didn't look hard enough, but there's no obvious switch to "just turn off all the legacy stuff, thnx".

Also, there has been a huge amount of churn on the tooling side, and if you have a legacy app, you probably don't wanna touch whatever build program was cool that year. I've got a react app which is almost 10 years old, there has to be tons of stuff which is even older.

vkou | root | parent
> Maybe I didn't look hard enough, but there's no obvious switch to "just turn off all the legacy stuff, thnx".

There is. Break compatibility for it, and whatever poor bastard that is still maintaining software that is targeting a PalmPilot is free to either pin to an older version of your library, or fork it. Yes, that's a lot of pain for him, but it makes life a little easier for everyone else.

josephg | root | parent | next
This is my philosophy too. If the nodejs project doesn't support node 18, why on earth should I?

Here's the schedule, if anyone hasn't seen it. Node 18 is EOL. Node 20 goes EOL in a bit over a month.

https://nodejs.org/en/about/previous-releases

Pxtl | root | parent | next
It's just an excuse to not change things.
fragmede | root | parent | next
Just how old an Android device in the developing world do you not want to support? Life's great at the forefront of technology, but there's a balancing act to be able to support older technology vs the bleeding edge.
anematode | root | parent | next
I like the sentiment, but building a website that can actually function in that setting isn't a matter of mere polyfills. You need to cut out the insane bloat like React, Lottie, etc., and just write a simple website, at which point you don't really need polyfills anyway.

In other words, if you're pulling in e.g. regenerator-runtime, you're already cutting out a substantial part of the users you're describing.

Dylan16807 | root | parent | next
A quick search tells me that firefox 143 from 6 months ago supported android 5 (Lollipop).

So that's my cutoff.

dfabulich | root | parent
Android phones update to the latest version of Chrome for 7 years. As long as you're using browser features that are Baseline: Widely Available, you'll be using features that were working on the latest browsers in 2023; those features will work on Android 7.0 Nougat phones, released in 2016.

Android Studio has a nifty little tool that tells you what percentage of users are on what versions of Android. 99.2% of users are on Android 7 or later. I predict that next year, a similar percentage of users will be on Android 8 or later.

kennywinker | root | parent
3.9 billion android users, means that 0.8% is 31 million people - and for a very small number of developers most of their users will be from that slice. For most of them… yeah go ahead an assume your audience is running a reasonably up to date os
oflebbe | root | parent
Websites built with tons of polyfills are likely not run on these devices anyway, since they will run out of RAM before, let alone after they will only load after sone minutes because of CPU limitations on top of not being loaded because their x509 certs are outdated as well as the bandwith they support is not suitable to load MB sited pages
hsbauauvhabzb | root | parent
I’ve been very lost trying to understand the ecosystem between es versions , typescript and everything else. It ends up being a weird battle between seemingly unrelated things like require() vs import vs async when all I want to do is compile. All while I’m utterly confused by all the build tools, npm vs whatever other ones are out there, vite vs whatever other ones are out there, ‘oh babel? I’ve heard the name but no idea what it does’ ends up being my position on like 10 build packages.

This isn’t the desire of people to build legacy support, it’s a broken, confusing and haphazard build system built on the corpses of other broken, confusing and haphazard build systems.

anematode | root | parent | next
Honestly, Vite is all you need. :) It's super flexible compared to the status quo of require vs. import etc. For example, I recently wanted to ship a WASM binary along with the JS rather than making it a separate download (to avoid having to deal with the failure case of the JS code loading and the WASM not fetching). All I had to do was import `a.wasm?url` and it did the base64 embedding and loading automatically.
Maxion | root | parent
This sentiment is all well and good, but when you end up in a new-to-you JS codebase with a list of deps longer than a Costco receipt using some ancient Webpack with it's config split into 5 or so files, then no-one is letting you upgrade to vite unless the site is completely down.
tankenmate | root | parent | next
It's almost like Churchill's quip "He has all the virtues I dislike and none of the vices I admire". In other words, in some ways the JS ecosystem rushes to all the tech debt inducing "shiny shiny" and avoids all the tech debt reducing "hard work of refactoring and wisdom". It's almost like a large chunks of the JS ecosystem thrives on "the dopamine hit". Santayana's wisdom whispers behind every import.
CoderLuii | root | parent | next
this is exactly where i landed too. i build docker images that bundle node tooling and every time i think i understand the build system something changes. require vs import, cjs vs esm, babel vs swc vs esbuild, then half your dependencies use one format and half use the other. the worst part is when you containerize it because now you need it all to work in a clean linux environment with no cached state and suddenly half the assumptions break.
conartist6 | root | parent
Yes, yes to all of that, but there is still hope.
hsbauauvhabzb | root | parent
This fancy new build tool with emojis will fix it!
kennywinker | root | parent
This fancy new vibe coded build tool with emojis
hsbauauvhabzb | root | parent
Built in rust
conartist6 | root | parent
Mmmmhm. But not all the people building devtools got distracted by a pretty butterfly.
tgv | parent | next
> Ancient browser support is a thing

And weird browser support.

People use the oddest devices to do "on demand" jobs (receiving a tiny amount of money for a small amount of work). Although there aren't that many, I've seen user agents from game consoles, TVs, old Androids, iPod touch, and from Facebook and other "browser makers", with names such as Agency, Herring, Unique, ABB, HIbrowser, Vinebre, Config, etc. Some of the latter look to be Chrome or Safari skins, but there's no way to tell; I don't know what they are. And I must assume that quite a few devices cannot be upgraded. So I support old and weird browsers. The code contains one externally written module (stored in the repository), so it's only a matter of the correct transpiler settings.

hrmtst93837 | parent | next
The root isuue is that the web rewards shipping now and fixing later so old deps and conservative targts linger until stuff breaks.
ivanjermakov | root | parent
Not just web, gamedev is suffering this too, since ~2020.
Tade0 | parent | next
Sometimes it's a result of unforeseen consequences of design decisions.

All pre-signal Angular code must be compiled down to JS which replaces native async with Promise.

Why is that so? For a long time Angular's change detection worked by overriding native functions like setTimeout, addEventListener etc. to track these calls and react accordingly. `async` is a keyword, so it's not possible to override it like that.

Signals don't require such trickery and also allow to significantly decrease the surface area of change detection, but to take advantage of all of that one has to essentially rewrite the entire application.

userbinator | parent | next
The newer version is often even more bloated. This whole article just reinforces my opinion of "WTF is wrong with JS developers" in general: a lot of mostly mindless trendchasing and reinventing wheels by making them square. Meanwhile, I look back at what was possible 2 decades ago with very little JS and see just how far things have degraded.
jazzypants | root | parent | next
Literally nothing has degraded. What in the world are you talking about? All of this stuff is optional.
michaelchisari | root | parent | next
A standard library can help, but js culture is not built in a way that lends to it the way a language like Go is.

It would take a well-respected org pushing a standard library that has clear benefits over "package shopping."

halapro | root | parent | next
> WTF is wrong with JS developers

Don't confuse "one idiot who wants to support Node 0.4 in 2026" with "JS developers". Everybody hates this guy and he puts his hands into the most popular packages, introducing his junk dependencies everywhere.

saghm | root | parent | next
If everyone hates him and thinks his dependencies are junk, why would anyone let him introduce them to popular packages? Clearly there are at least some people who are indifferent enough if the dependencies are getting added elsewhere
Maxion | root | parent | next
The other problem is that this is a bit of a circular path, with deps being so crap and numerous, upgrading existing old projects become a pain. There are A LOT of old projects out there that haven't been updated simply because the burden to do so is so high.
albedoa | root | parent | next
The guy you are responding to is longing for what was possible two decades ago. He is that one idiot. He even replied to your comment with confirmation!
userbinator | root | parent
Then I wish there were more of these "idiots who want to support Node 0.4 in 2026". Maybe they're the ones with the common sense to value stability and backwards compatibility over constantly trendchasing the new and shiny and wanting to break what was previously working in the misguided name of "progress".
josephg | root | parent | next
NodeJS has a clear support schedule for releases. Once a version of nodejs is EOL, the node team stops backporting security fixes. And you should really stop using it. Here's the calendar:

https://nodejs.org/en/about/previous-releases

Here's a list of known security vulnerabilities affecting old versions of nodejs:

https://nodejs.org/en/about/eol

In my opinion, npm packages should only support maintained versions of nodejs. If you want to run an ancient, unsupported version of nodejs with security vulnerabilities, you're on your own.

userbinator | root | parent
"support" and "works" are two different things.
Griffinsauce | root | parent | next
You wouldn't if you look more deeply at this. He doesn't push for simplicity but for horrible complexity with an enormous stack of polyfills, ignoring language features that would greatly reduce all that bloat. .
userbinator | root | parent
That's also a problem. I've written JS that would work on any browser from the latest ones all the way back to IE5, and I'm not even a professional JS developer. It's not hard.

Maybe "professional" is the problem: they're incentivised to make work for themselves so they deliberately add this fragility and complexity, and ignore the fact that there's no need to change.

| root | parent
{"deleted":true,"id":47475361,"parent":47475036,"time":1774166104,"type":"comment"}
prinny_ | root | parent
I believe if you read this article https://www.artmann.co/articles/30-years-of-br-tags your "wtf is wrong with js developers" question will be answered.