Bun 1.4 is out.
I had been following the plan to move Bun from Zig to Rust for a while, so this was one release I was genuinely looking forward to.
I also use Bun with Vite fairly often in my own projects. There is nothing inherently wrong with Node.js, but I tend to prefer a lighter stack with fewer moving parts when I can get away with it. Bun fits that preference rather well.
And Bun 1.4 is a substantial release.
It closes more than 2,900 issues, passes 1,517 additional tests from the Node.js test suite, cuts idle CPU usage by as much as fivefold, reduces memory usage by up to 35%, and improves Linux startup time by up to 50%. Underneath all of that, large parts of Bun have moved from Zig to Rust.
With that much changing, I did have one small reaction: this is still 1.4, not 2.0.
Major migration from Zig to Rust
The Rust migration is the part that caught my attention first.
Bun has long been associated with the idea of a fast JavaScript runtime written in Zig, so when I first heard about the rewrite, my reaction was basically: they are changing that part too?
The reasoning makes sense, though.
Bun has had to deal with issues such as memory leaks and use-after-free bugs that come with manual memory management. Moving more of the codebase to Rust gives the project another layer of protection against that class of problem.
The way the migration was carried out is also interesting. The Bun team used many Claude Code agents in parallel to help move a large existing codebase from one systems language to another.
Having AI write code is no longer unusual. Using AI agents as part of a large-scale language migration for a runtime that already has a substantial user base is a different kind of experiment.
Interestingly, this Rust-based build of Bun had reportedly already been running in production as the internal runtime powering Claude Code well before the stable release—meaning the very agent helping with the migration was already running on top of it.
The fact that it made it all the way into a stable release makes Bun 1.4 interesting not only as a runtime update, but also as a practical example of how AI-assisted software development may evolve.
Further improvements to Node.js compatibility
For day-to-day use, Node.js compatibility matters to me even more than raw speed.
There are still moments when I install an npm package and wonder whether it will behave exactly the same way under Bun.
Bun 1.4 passes 1,517 additional tests from the Node.js test suite. That does not mean complete Node.js compatibility, of course, but every reduction in the number of "I should probably check this on Bun first" cases makes the runtime easier to choose by default.
Bun 1.4 also raises its Node.js compatibility target from Node.js 24.3.0 to 26.3.0. process.versions.node now reports 26.3.0, and NODE_MODULE_VERSION is 147.
That matters in practice. Native addons built for Node 24 may need to be rebuilt, so projects that rely on node-gyp, N-API, or other native integrations should not assume that updating Bun is always a completely transparent change.
Even when I am working in a Bun + Vite project, a compatibility issue can still send me back to Node.js. If those cases keep disappearing, "start with Bun" becomes a much easier default.
That is probably the compatibility trend I care about most.
What to check before upgrading to Bun 1.4
The internals have changed enough that moving from the 1.3 series is worth treating as more than a routine minor-version bump.
The x64 builds have also been reorganized. The separate Haswell build is gone, x64 now uses the baseline build, and SIMD support is selected at runtime.
Most users will probably never notice this. But if a project depends on native addons, CPU-specific behavior, or embeds Bun into a distributed binary, the 1.4 release notes are worth reading before upgrading.
Bun as a lightweight JavaScript development stack
Bun is usually sold on speed, but the part I increasingly like is how much of the JavaScript toolchain it can collapse into one executable.
It is not just a runtime. Bun includes a package manager, test runner, bundler, and direct support for running TypeScript and JSX. It also ships built-in APIs for things such as SQLite, SQL, Redis, S3, Shell, and YAML.
Bun 1.4 adds XML support as well.
At this point, Bun feels less like "a faster Node.js runtime" and more like a tool for keeping a JavaScript development environment compact.
That direction suits me.
For a small CLI or personal project, I would rather avoid adding another dependency or configuration file if the runtime already covers the job.
bun run
bun test
bun build
There is something appealing about being able to stop there.
Expanded built-in APIs with XML and WebView
Bun 1.4 adds an XML API and also introduces the experimental Bun.WebView.
So yes, WebView is part of Bun now too.
I have been thinking about whether a Tauri-based desktop app can be made even smaller, and more generally about how little infrastructure is actually needed to ship a lightweight desktop app built with web technologies. That makes Bun.WebView especially interesting to me.
It is obviously not a Tauri replacement at this point. But Bun already supports single-file executables.
If those pieces mature together, there is a plausible path toward small desktop tools built with Bun plus HTML, CSS, and JavaScript, then shipped with relatively little ceremony.
That is one part of Bun I plan to keep watching.
Why Bun 1.4 is worth trying
Bun 1.4 changes a great deal internally without changing what I like about Bun from the outside.
It still tries to be an all-in-one JavaScript toolchain while staying relatively lightweight. The Rust migration and Node.js compatibility work make that same idea feel a little more dependable.
And completely unrelated to runtime design: Bun's little mascot still looks a bit like a steamed bun, which is part of its charm.
I will be using 1.4 in my Bun + Vite projects for a while and seeing how it holds up in practice.
Reference: Bun 1.4 release post
Reference: Bun v1.4.0 on GitHub Releases
Reference: Bun 1.4 breaking changes
Comments