Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The three pillars of JavaScript bloat

43081j.com

Post reply on HN
Print view View original

21–30 of 301 posts

Re: The three pillars of JavaScript bloat

#21

Post by dfabulich »

fragmede wrote: post #10
anematode wrote: post #8

Earlier quoted context omitted.

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

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.

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.

Re: The three pillars of JavaScript bloat

#22

Post by onlyspaceghost »

cute_boi wrote: post #19
skydhash wrote: post #3

Fantastic write up! And we're seeing rust happily going down the same path, especially with the micro packages.

Rust is different as there is no runtime.

but it still increases compile time, attack surface area, bandwidth use, etc.

Re: The three pillars of JavaScript bloat

#23

Post by conartist6 »

hsbauauvhabzb wrote: post #12
anematode wrote: post #8

Earlier quoted context omitted.

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

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

Yes, yes to all of that, but there is still hope.

Re: The three pillars of JavaScript bloat

#24

Post by est »

More like a nodejs bloat rather than JS bloat.

For personal objects I always prompt the AI to write JS directly, never introduce nodejs stack unless absolutely have to.

Turns out you don't always need Nodejs/Reactto make a functional SPA.

Re: The three pillars of JavaScript bloat

#26

Post by cwnyth »

andai wrote: post #17

Great article, but I think these are all marginal. The main cause of bloat is not polyfills or atomic packages. The cause of bloat is bloat! I love this quote by Antoine de Saint-Exupéry (author of the Little Prince): "Perfection is achieved, not when there is nothing left to add, but nothing to take away." Most software is not written like that. It's not asking "how can we make this more elegant?" It's asking "what'…

Cf. Vonnegut's rule #4 of good writing:

> Every sentence must do one of two things—reveal character or advance the action.

Or Quintilian's praise of Demosthenes and Cicero: "To Demosthenes nothing can be added, but from Cicero nothing can be taken away."

Re: The three pillars of JavaScript bloat

#27

Post by rtpg »

I think on the first point, we have to start calling out authors of packages which (IMO) have built out these deptrees to their own subpackages basically entirely for the purpose of getting high download counts on their github account

Like seriously... at 50 million downloads maybe you should vendor some shit in.

Packages like this which have _7 lines of code_ should not exist! The metadata of the lockfile is bigger than the minified version of this code!

At one point in the past like 5% of create-react-app's dep list was all from one author who had built out their own little depgraph in a library they controlled. That person also included download counts on their Github page. They have since "fixed" the main entrypoint to the rats nest though, thankfully.

https://www.npmjs.com/package/has-symbols

https://www.npmjs.com/package/is-string

https://github.com/ljharb

Re: The three pillars of JavaScript bloat

#28

Post by hinkley »

rtpg wrote: post #27

I think on the first point, we have to start calling out authors of packages which (IMO) have built out these deptrees to their own subpackages basically entirely for the purpose of getting high download counts on their github account Like seriously... at 50 million downloads maybe you should vendor some shit in. Packages like this which have _7 lines of code_ should not exist! The metadata of the lockfile is bigger…

Hat tip to Sindre who has fifty bagillion packages but few of them depend on more than one of his other packages.

Re: The three pillars of JavaScript bloat

#29

Post by stephenr »

The primary cause of JS bloat is assuming you need JS or that customers want whatever you're using it to provide.

For $client we've taken a very minimal approach to JavaScript, particularly on customer facing pages. An upcoming feature finally replaces the last jquery (+ plugin) dependent component on the sales page, with a custom implementation.

That change shaved off ~100K (jquery plus a plugin removed) and for most projects now that probably seems like nothing.

The sales page after the change is now just 160K of JS.

The combination of not relying on JS for everything and preferring use-case-specific implementations where we do, means we aren't loading 5 libraries and using 1% of each.

I'm aware that telling most js community "developers" to "write your own code" is tantamount to telling fish to "just breathe air".

Post reply on HN