Why would I want everything reimplemented in this massive binary? Why would Bun be anymore in touch with nuances of all these different technologies then individual projects dedicated to their own speciality?
JS Runtime, Package Manager, Test Runner (both unit and headless browser), Bundler, JSX, PosgreSQL/MySQL/SQLite drivers, S3 client, Redis client, Formatter, Linter, etc.
Not to mention parsers for YAML, TOML, Markdown which are easily three separate projects worth of complexity in their own right.
I guess one clear downside is to get all these great features they're pushing for 1.4 you needed to wait until everything was ready. Given 1.3 was pushed out in October 2025, a 10 month release cycle across so many large technologies is tough. Before you give a pass because of the Rust rewrite Bun 1.2 was released in January 2025
I have to respect Jarred knows how to work the algorithm, 10 carefully crafted X teaser posts for this release spaced out over 72 hours https://xcancel.com/jarredsumner
It's funny because the top article on HN is about a malicious rust crate package, and people keep making comparisons to js/npm and how both language suffer from frequent security issues because they have weak std libs.
I assume the same benefit applies to humans as well!
When the LLM can verify its own output by running static analysis they produce better results. They also seem to understand type definitions and avoid going to the source which, in theory, should reduce context size.
(1) scare quotes because I think it's dumb for us software people to call code we picked up on the side of the road part of a 'supply chain' like that means anything.
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.
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.)
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".
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.
- 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 feel like nobody complained that you needed to install a dependency to do headless browser testing for example.
Take Python - the standard lib now has things like a toml parser, sqlite client.
And while I avoid the entire JS ecosystem as much as possible, a simple search to find a good Postgres client was not elucidating.
https://wiki.postgresql.org/wiki/List_of_drivers two options - with node-postgres / pg seeming to be the most supported or postgres.js which has more abstractions but is less active
Contrast that to the question for Java, where it's clear the official JDBC driver is the best option.
A couple years ago a common complaint was that the JavaScript ecosystem relied too heavily on dependencies for everything. Remember the left-pad incident where the developer deleted the popular dependency out of protest for reasons I can even remember? Or when colors.js was sabotaged to break everything that depended on it? The node-ipc package was sabotaged to delete files on developer’s machines. Then we had a wave of supply chain attacks that tried to insert malware into build scripts of popular dependencies.
So the ecosystem started moving toward more batteries-included style development in response.
You have more options, not less, you can still use the external dependencies.
For example, I might well choose to reimplement eg a subset of TOML parsing to avoid the dependency risk.
I don’t write JavaScript/TypeScript, but if I did, I’d find Bun’s “batteries included” approach compelling, at least to the extent I decide I can trust Bun, after due diligence
JavaScript runtime (obviously), package manager, test runner for unit tests, bundler, JSX, SQLite bindings, formatter, linter, YAML and TOML parsers. Maaaaybe even a Markdown parser and HTML5 parser. Definitely JSON, CSV and XML parsers.
I.e. similar to Python. Though Python is a bit of an incoherent mess. If you have all these you need them to be coherent.
In 1.3 you couldn't even use the repl without downloading dependencies.
In 1.4 it is now finally built-in, hurray! That alone is why I'm going to install 1.4. Finally a truly portable typescript repl.
Add in the influencer dev brainrot culture and you get these VC backed efforts to privatized publicly important projects (node.js) under control of quite evil people that have zero record of helping others.
This isn’t about what individual developers would want but what is most beneficial to Anthropic and claude code. They are likely using Bun as a vehicle for standardizing and enriching local user environments in order to address common tasks that claude generally writes bespoke scripts to accomplish.
Yes, I know there's probably better options than Rust for building APIs, but I wanted to learn it, so why not?
Go is a good stdlib and trivial build toolchain.
You just cargo build and all your apes gone.
Claude building stuff means a lot of things that everybody wanted to do, just couldn't allocate the attention or other resources - now get built.
I don't care about 100% compatibility. NodeJS is a standard but dead to me.
I rather have faster feedback loop and less development/build/test time than worrying about Node.JS compatibility.
Bun is the answer for my flow.
---
Bun might as well promote itself as the total replacement of Node.JS, and I will still hop in.
And somehow, the programming language he made (that currently bans AI contributions outright) ended up being instrumental for a tool that's in the center of the whole craze, and doing Tony Hawk 900 aerial spins with agentic AI software rewrites under a frontier lab. I'm not commenting on the effectiveness of the rewrite, but it seems fascinating that for a moment Zig found itself at the intersection of two very different camps that the software world seems to be divided into. It seems in retrospect like a bomb waiting to go off even if they didn't jump ship to Rust!
A year from now folks will be; I can’t use it anymore it’s too unreliable but for now keep looking the other way.
I don't use Bun, so I don't know if quality has degraded. But if it hasn't and they're shipping features users want faster than ever, I wouldn't call it slop. I don't care who wrote the code if the end product is working.
This isn't so much about Bun or Node.js any more. It is the battleground for AI and non-AI coding.
This isn't so much about Bun or Node.js any more. It is the battleground for AI and non-AI coding.
The JVM and GCC have forbidden AI generated code. The world is bigger than you think.
Comments here 3 months ago are quite something: https://news.ycombinator.com/item?id=48132488
> Absolute crickets from the "there's no way LLM's can rewrite Bun to Rust this quickly, it's going to be buggy, it's marketing" crowd
> Comments here 3 months ago are quite something: https://news.ycombinator.com/item?id=48132488
Did you… perhaps read the entire comment you just posted? The crowd that was saying “no way they did that in 11 days” sure seems correct given that the release today is 3 months later. 3 months is longer than 11 days. Significantly so, in fact.
Internet echo chambers are quite a problem. AI success and its immense implications are wreaking havoc on the ability of even intellectuals in HN and lobsters to face reality in front of them, even as their predictions become falsified again and again.
How about you make a video on something you published and see how you look?
Maybe run it as process 1 in a future ClaudeOS.
This is unmaintable mess, and the author himself is struggling already, given how he pushed the release date ten times.
Jared has always done that. Thats not specific to this 1.4 release.
How is this even possible?
I know we're all using AI, but Bun seems like the one singular project where there's just been a crazy increase in the amount of output, a 10x on the 10x.
How are they doing this?
Jarred spins it as "pre-release" [1] but it was pre-embargo.
[1]: https://bun.com/blog/bun-in-rust#loops-that-write-review-cod....
Hey, did the memory leak really solve with slop rewrite?
slightly aside, but I find it worrying that our industry treats a lot of cannon events in stride and don't organize around that idea or to mitigate the risks around that idea.
things that everybody basically just complained but ended up working out fine,
- Bun rust rewrite. - Elon Musk firing 80% of twitter by stack ranking employees by code committed - autocompletion basically just taking over everyone
maybe I'm just taking extremely outlier outcomes. but it is still fascinating to see people complain about how LLMs don't think
twitter has (irrespective of the political turmoil etc.) purely as a technical product added more users, more features etc.
to me that seems like it worked out fine.
twitter was a dumpster fire before and now it is (to me) less of a dumpster fire.
so far it seems like the bun rewrite is going quite well. I haven't found any major issues since the merge despite, robobun being the top committer in the repo.
With LLM, Bun can ship new features effortlessly and bundle many features directly into the runtime, which could be implemented by third-party libraries.
While this is more convenient for Bun user, this development approach just steals the time-tested designs of these open-source libraries. By offering simplified bundled APIs, Bun diminishes the value of contribution on those libraries.
As a general-purpose runtime, Bun cannot continously improve on every one of these domains in depth; it can only provide the most common functionality. When changes are needed, developers also cannot easily patch or customize the interfaces bundled with the Bun runtime itself.
If Bun becomes widely adopted, its APIs could effectively become locked in. That would not be healthy for the ecosystem.
> In Bun 1.4, I rewrote Bun in Rust. [...] I did it in 11 days, using Claude Code, and wrote about how, in our blog.
Everything else in the video is phrased as "we", and even the section in the blog post is "We rewrote Bun in Rust"[1].
There's no question Jarred did the work and deserves enormous credit for it. I just found the contrast interesting, because the video explicitly frames the rewrite as "I", whereas the rest of the release frames it as "we".
nobody ever reports that they installed it and ran it on production or something.
personally I only use bun to replace yarn as script executor now. Used to follow it and tried to replace node server sveltkit runtime with bun, but it didn't work reliably so I stopped the experiment.
it's too bad. when you are spoiled by crystal/go/rust written servers that consume 20MB-50MB ram only, seeing a nodejs server consume 400-500MB ram looks ridiculous bun was such an attractive option.