The three pillars of JavaScript bloat • Hacker News Board

Re: The three pillars of JavaScript bloat

#291

Post by spartanatreyu » Mon, Mar 23, 2026, 4:20 AM UTC

realityking wrote: post #267

josephg wrote: post #190

Earlier quoted context omitted.

Thanks but that doesn't answer my question. Forget node and bun then. What is missing from the standard library?

There’s been a lot of progress (Temporal, URL, TextDecoder, Base64 encoding, etc.) but there are still gaps. Math.clamp is a big one (it’s a TC39 proposal). I’d also love to have the stats functions that Python has (geometric mean, median, etc.). On the more ambitious end: CSV reading/writing and IPv4/IPv6 manipulation.

> On the more ambitious end: CSV reading/writing

Deno's standard libary has nice CSV parsing/serializing, and you can use it in any environment.

Docs: https://docs.deno.com/examples/parsing_serializing_csv/

Re: The three pillars of JavaScript bloat

#292

Post by pennaMan » Mon, Mar 23, 2026, 7:59 AM UTC

auxiliarymoose wrote: post #20

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc. People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependen…

This is one of the best parts of agentic development. I almost never had to reach for any npm package besides the foundational staples like the tailwinds and react queries. My pacakge.json dependency array vs project size ratio is just incredible nowadays

Re: The three pillars of JavaScript bloat

#293

Post by nektro » Mon, Mar 23, 2026, 8:19 AM UTC

> Atomic architecture

this an artifact of dealing with a pre-esm ecosystem. before esm these small packages were the easiest way to help bundlers do better tree shaking

Re: The three pillars of JavaScript bloat

#294

Post by jgilias » Mon, Mar 23, 2026, 8:19 AM UTC

szatkus wrote: post #246

jgilias wrote: post #193

Earlier quoted context omitted.

I remember reading somewhere that Deutsche Bahn is running Windows 3.1 for something still?

Somehow I doubt they use it to access another Next.js app created by some startup from SV.

The point was - some people are running hugely outdated stacks for “reasons”.

Re: The three pillars of JavaScript bloat

#295

Post by Levitating » Mon, Mar 23, 2026, 9:14 AM UTC

The problem is that people prefer adding a shebang regex dependency, rather than just copy the regex into their codebase.

If your dependency is less than 10 lines of code, you shouldn't depend on it. You can just copy those 10 lines of code.

Re: The three pillars of JavaScript bloat

#296

Post by jazzypants » Mon, Mar 23, 2026, 1:05 PM UTC

userbinator wrote: post #288

jazzypants wrote: post #283

Earlier quoted context omitted.

What has degraded? Name one single thing specifically. Every aspect of web development is easier and better than it was two, five, ten, or twenty years ago. Entropy is a fact, but whining about it without solutions doesn't help anyone.

As I write this comment, this happens to be at the top of the front page: https://news.ycombinator.com/item?id=47480507

Yes, that's a single website that is fixed with an ad blocker. You have proven absolutely nothing. You are very bad at crafting arguments.

Re: The three pillars of JavaScript bloat

#297

Post by halapro » Mon, Mar 23, 2026, 5:59 PM UTC

saghm wrote: post #79

halapro wrote: post #56

Earlier quoted context omitted.

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

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

OSS is not a democracy. If he controls packages with millions of downloads, you either follow what he does or fork the packages, which is what the article is about.

And even then the vast majority of people will continue to use his packages because they don't care or don't have time to investigate bloat.

Re: The three pillars of JavaScript bloat

#298

Post by whstl » Mon, Mar 23, 2026, 6:46 PM UTC

algolint wrote: post #265

whstl wrote: post #217

Earlier quoted context omitted.

I like to criticize React as much as the next person, but this is an JS ecosystem problem around third-party libraries, not a React problem per se. If you're using third-party NPM packages to do "Vanilla", you're will probably run into the same problem. If you import React directly from a CDN, you won't.

[flagged]

Yeah, I agree.

Build systems (especially Babel and Webpack) were the first big culprits in terms of dependency bloat, and it was very rare to see React without them.

Re: The three pillars of JavaScript bloat

#299

Post by Joeri » Mon, Mar 23, 2026, 9:50 PM UTC

auxiliarymoose wrote: post #124

Joeri wrote: post #104

Earlier quoted context omitted.

I’ve been exploring this for years, even made a tutorial website about building sites and apps without dependencies (plainvanillaweb.com). What I’ve learned is that many of the things the frameworks, libraries and build tools do can be replaced by browser built-ins and vanilla patterns, but also that making things that way is at present an obscure domain of knowledge. I think this is because the whole web dev knowled…

Thanks for creating and sharing that resource! I'm reading through it now, and it looks fantastic. I'll share it the next time someone asks where to get started with web dev. Come to think of it, I should write up the techniques I use, too...e.g. I have simple wrappers around querySelector() and createElement() with a bit of TypeScript gymnastics in a JSDoc annotation to add intellisense + type checking for custom el…

I think a blog post on jsdoc would be a better fit, with a link out from one of the main tutorial pages. Reach out to me over mail and we can work something out.

Re: The three pillars of JavaScript bloat

#300

Post by saghm » Wed, Mar 25, 2026, 7:40 AM UTC

halapro wrote: post #297

saghm wrote: post #79

Earlier quoted context omitted.

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

OSS is not a democracy. If he controls packages with millions of downloads, you either follow what he does or fork the packages, which is what the article is about. And even then the vast majority of people will continue to use his packages because they don't care or don't have time to investigate bloat.

> OSS is not a democracy. If he controls packages with millions of downloads, you either follow what he does or fork the packages, which is what the article is about.

My point is that in order for any other package not controlled by him, there needs to be someone choosing to depend on them (either by adding it themselves or merging a change that adds it). Whoever that is clearly doesn't seem to hate it as much as you claimed.

> And even then the vast majority of people will continue to use his packages because they don't care or don't have time to investigate bloat.

So in other words, you were grossly exaggerating when you said "everyone" hates the junk dependencies. By your own words, the vast majority of people don't seem to really care enough about it to do anything.