Live data from Hacker News

The three pillars of JavaScript bloat

43081j.com

61–70 of 301 posts

Re: The three pillars of JavaScript bloat

#61

Earlier quoted context omitted.

Is there no room for describing the setting? Must every utterance that sets the atmosphere also advance the plot or reveal character? Is there no room for mood?

> Is there no room for describing the setting? Is there no room for mood? You mean the character of a place?

sure, setting and character are the same thing

Re: The three pillars of JavaScript bloat

#62
post #56

Earlier quoted context omitted.

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.

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

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.

Re: The three pillars of JavaScript bloat

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

As usual, there's a cultural issue here. I know it's entirely possible to paste those seven lines of code into your app. And in many development cultures this will be considered a good thing.

If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".

Re: The three pillars of JavaScript bloat

#64
post #53

Earlier quoted context omitted.

As usual, he's copying someone else who's been doing this for years: https://www.npmjs.com/package/is-number - and then look and see shit like is odd, is even (yes two separate packages because who can possibly remember how to get/compare the negated value of a boolean??) Honestly for how much attention JavaScript has gotten in the last 15 years it's ridiculous how shit it's type system really is. The only type relat…

To be fair, prototypal inheritance is relatively uncommon language design. I'd rank it as considerably harder to understand than the % operator.

That's a good point, it's only been around for 30 years, and used on 95% of websites. It's not really popular enough for a developer to take an hour or two to read how it works.

Re: The three pillars of JavaScript bloat

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

As usual, there's a cultural issue here. I know it's entirely possible to paste those seven lines of code into your app. And in many development cultures this will be considered a good thing. If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".

I think the fact that everyone cites the same is-number package when saying this is indicative of something though.

Like I legit think that we are all imagining this cultural problem that's widespread. My claim (and I tried to do some graph theory stuff on this in the past and gave up) is that in fact we are seeing something downstream of a few "bad actors" who are going way too deep on this.

I also dislike things like webpack making every plugin an external dep but at least I vaguely understand that.

Re: The three pillars of JavaScript bloat

#66
post #56

Earlier quoted context omitted.

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.

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

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".

Re: The three pillars of JavaScript bloat

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

> entirely for the purpose of getting high download counts on their github account Is this an ego thing or are people actually reaping benefits from this? Anthropic recently offered free Claude to open source maintainers of repositories with over X stars or over Y downloads on npm. I suppose it is entirely possible that these download statistics translate into financial gain...

I'm completely apathetic about spicy autocomplete for coding tasks and even I wonder which terrible code would be worse.

The guy who wrote is even/odd was for ages using a specifically obscure method that made it slower than %2===0 because js engines were optimising that but not his arcane bullshit.

Re: The three pillars of JavaScript bloat

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

As usual, there's a cultural issue here. I know it's entirely possible to paste those seven lines of code into your app. And in many development cultures this will be considered a good thing. If you're working with Javascript people, this is referred to as "reinventing the wheel" or "rolling your own", or any variation of "this is against best practice".

The problem I think is that the js community somehow thinks that being on npm is some bastion of good quality.

Just as the cloud is simply someone else's computer, a package is just someone else's reinvented wheel.

The problem is half the wheels on npm are fucking square and apparently no one in the cult of JavaScript realises it.

Re: The three pillars of JavaScript bloat

#70
post #59

Earlier quoted context omitted.

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.

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.

Sad but true...
Post reply on HN