This is my WIP fork of Bun, based on the last commit before their Rust rewrite. It is still very early in its development and is nowhere near ready for production. I saw that a similar project had already been posted on Ziggit, so I am posting mine to avoid duplicating any development effort, though I have not looked at the other project as of this writing.
I have ported Bun to build with the current upstream Zig (with minor patches to get incremental rebuilds to work). The whole build graph is now in build.zig, including vendored sources of JavaScriptCore. This allows for sub-1s incremental builds, greatly improving the dev loop for the project.
The goal is to be a drop-in replacement for Bun, with a saner codebase. To that end, I have imported all the new tests from Rust Bun into the project, many of them covering new features and bug fixes. A lot of tests don’t pass yet, so this will be a treadmill of keeping up with upstream. But I am trying to deslop the codebase in the process, and keep reducing technical debt.
To that end, I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code. I’ve also rewritten and modernized parts of the codebase, trying to rely more on Zig’s stdlib. In the process, countless bugs have also been fixed.
Supported Zig versions
The project has a slightly patched Zig master submodule, mostly regarding incremental builds. Upstream Zig at yesterday’s commit 2b1c663 should be able to build it just fine.
AI / LLM usage disclosure
Bun is the quintessential AI slop project at this point. Inheriting that is no easy task. I don’t think any human should sacrifice their sanity untangling this mess of 600K lines of slop code. For that reason, I will not be accepting any human-coded contributions until I deem the project to be in a sane enough shape. It will likely require most subsystems to be rewritten.
To this end, LLMs will be used extensively. But hopefully better development practices, with a human in the driver’s seat, and a focus on reducing technical debt and writing idiomatic Zig, mean that in a few weeks or months there will be a presentable codebase that serves as a drop-in replacement for Rust Bun 1.4.0. If you have access to Sol or Fable, you can help me get there faster.
Feel free to point out cases of the most egregious slop in the Bun codebase, and I’ll do my best to fix and modernize them. I am using this as a way to improve my own Zig skills. In the long term, I hope this becomes a codebase that is pleasant enough to maintain without LLM help.
kracked 2
Sounds like a plan.
I’ve also built a JavaScript Runtime, and to be honest, I don’t think Zig or Rust is the most core part of Bun.
What really makes up Bun are C/C++ projects like JSC, uWebSockets, brotli, lol-html, tinycc, etc. Zig or Rust is just the glue.
That’s also why I’m not particularly interested in Jarred rewriting Bun in Rust—rewriting the glue doesn’t make much sense, and similarly, continuing to maintain a Zig fork doesn’t make much sense either.
So I’m curious if you have plans to rewrite these dependencies using Zig, and whether you have plans to implement a v8-compatible API for JavaScriptCore.
Since Bun’s performance is already excellent (regardless of code quality, its performance truly outpaces Node or Deno), the only two issues are stability and V8/N-API compatibility. The community would welcome a project that addresses these problems.
Thank you for the feedback!
I wish Bun was just glue, then it would be easy to clean up. There is a lot of glue, but most of it is real code, I would say about 3/4. For instance, the package manager is 40K lines of code. And of course all the Node APIs and Web APIs are implemented in Zig. Not to name 10-20 other native features it ships.
Just maintaining the current feature set, and keeping up with any new Bun features, and JSC updates, is probably going to be very hard. I wouldn’t mind rewriting some small dependencies once the project stabilizes, but I can’t see myself competing with large established projects like Brotli. At least not while this is a side-project. Zig is perfectly capable of building Brotli.
Bun already has some v8 compatibility. I’m glad I haven’t needed to look at that code yet. My understanding is that there are partial V8 API shims that make popular packages work, but nowhere near complete coverage. So that would remain the strategy going forward, unless a better solution comes up.
As for stability, is there anything in particular you have in mind that Jarred did poorly or that I could do better?
This seems a truly interesting project in terms of software “refurbishing” and I’m very happy to see that you were able to achieve the thing that to me was the biggest missed opportunity with the original maintainers: being able to get fast incremental builds.
If you want some more eyeballs on your project, I recommend writing a blog post where you demo the incremental rebuild speed!
As incremental nears full arch/os support, we’re (zsf) also going to make more noise about it, inclusive of demo videos.
