Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Its strange how flip floppy the JS ecosystem is, because go back literally 1-3 years or so and the BIGGEST complaint was the lack of a standard library and having to use a package for everything.

But now that Bun is actually doing it its somehow bad? Its also still open source, so those implementations you mention need dedicated teams can still get the attention they need by the community if needed.

I'm on the side that I'd actually prefer if node included more out of the box and we could drastically cut down on the number of packages we need due to the amount of supply chain attacks that happen on packages in the node ecosystem.



Is that flip-flopping or just different developers having different preferences? Those who complain now would have had no reason to complain back then, and vice versa


Also known as the Goomba fallacy:

https://en.wiktionary.org/wiki/Goomba_fallacy


I'm pretty sure it's this. There's a genuine split in the developer community over this issue. And the JS community in particular is enormous.


I would guess that many devs' preference would be for a larger standard library, but not a kitchen sink.

Personally, I'd be happy with a larger suite of utility functions (say, most of Lodash / es-toolkit - remove the need for left-pad silliness), probably SQLite bindings (having a good persistence layer is great, it's perhaps the most robust and most widely deployed software on the planet), but not YAML (complex, security concerns, parser differences) or image handling (again, security concerns).

Node.js is, IMO, actually pretty good these days; they're regularly adding useful built-in tools that remove the need for add-on packages. (The ecosystem is so big that getting those updates to filter out is hard.)


SQLite bindings should absolutely not belong in a JS "standard library". SQLite is a project that most JS environments won't have enbedded.


There should be a space between "in the standard library" and "in a library written by some random person with a github account". An sqlite driver does not need to be bundled by the runtime, but it would be pretty great if there was an official sqlite driver library developed and supported by the node.js project but distributed through NPM.


I agree and I also wish Node did more.

Otoh should a standard lib give you absolutely everything? Probably not. There needs to be a line somewhere.

Right now Bun’s policy on this seems to be "whatever Jarred feels like should be in there".


> "whatever Jarred feels like should be in there"

This is the main draw. Everything he implemented was fast and minimalist and he usually implements a standardized api (web apis, esbuild bundler api).

The opinionated stuff is usually very common sense.

Most of the libraries OC mentions are things you would just like to be as fast as possible above all else.


My line for exclusion from standard library is a library that’s any one of:

- not obviously/generally useful (i.e. useless or too specific/should be a program not a library)

- obviously trivial

- already available (open source) elsewhere by a credible team that supporte and maintains it

Anything else… put it in the stdlib


I would argue it is more of a politcal problem, rather than in tech problem.

It is the same idea arounds LLM: people loving it keep praising it and criticise the haters, people hating it keep nitpicking it and criticise the lovers, and both of them tries to poach you to go to their side.

So no matter what, those people would also try to find things to shit on Bun if they make a move even if it is considered rational.

So the whole thing is never about tech anymore, it is about wanting Bun to succumb to their will.


wasn't that complaint mostly about those tiny dependencies like `is-even` or `is-array`?

I feel like nobody complained that you needed to install a dependency to do headless browser testing for example.


Standard library is up to the TC39 committee, not a VC-funded all-in-one JS runtime owned by Anthropic.


I could argue that one implementation adding these things does not make a std library. You lose portability and fracture the ecosystem, which is probably one of their intentions



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: