It's weird their promotional video repeats "you can do <million things> without installing dependencies", if I want headless browser testing is that wrong to install a project that offers that?
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
> 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?
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 saw a post recently about how LLMs are much more effective in Ruby on Rails because it's batteries included, so you don't get so many implementation details crapping up the context window.
I assume the same benefit applies to humans as well!
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
Some of these feel like solved problems effectively, so having them in the standard library is nice (at the expense of keeping these forever for backwards compatibility once a new tech replaces it). I do think having a larger standard library for common things (like golang) is the way to go. If a dependency seems to basically be installed by default everywhere, maybe it should go in the standard library.
> It's weird their promotional video repeats "you can do <million things> without installing dependencies",
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.
The complaint was micro-dependencies and huge sprawling trees. What was needed was quality dependencies on the level of SDL, ffmpeg, libcurl, where one domain is solved well and the focus is on API stability and good implementation. Not a battery included type of things.
I've still yet to run into any enterprise project using bun in the wild. It really feels like something entirely contained within startups that would choose wildly inappropriate tech like next.js.
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.
From the release video, something catching my attention:
> 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".
This is a huge win for Bun & Anthropic. I've been keeping an eye on Bun development cycle since they announced the Rust rewrite and the huge drama and backlash it generated. They seem to be proving the skeptics wrong with this release.
I recently pivoted to Rust for the backend development, after getting tired of the nodejs ecosystem fragmentation and how fragile things feel. Bun seems very interesting since it allows you to do so many things without pulling in 3rd party libraries and bundlers? Is anybody using it instead of nodejs? how's the experience so far? I might have to give it a try.
Yes, I know there's probably better options than Rust for building APIs, but I wanted to learn it, so why not?
While it has been used by Anthropic, the main question is if it works in other Bun's 1.3 production settings. Ignoring all the improvements, if it does work and no major bug or problems occurred, We are in for some management top down "Rewrite it in Rust" action over the next few years. And perhaps even worst, management will believe in Claude feed into Claude development.
This isn't so much about Bun or Node.js any more. It is the battleground for AI and non-AI coding.
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
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.
It's weird their promotional video repeats "you can do <million things> without installing dependencies", if I want headless browser testing is that wrong to install a project that offers that?
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
> 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?
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 saw a post recently about how LLMs are much more effective in Ruby on Rails because it's batteries included, so you don't get so many implementation details crapping up the context window.
I assume the same benefit applies to humans as well!
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
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.
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.
It's faster to have it in the runtime in native code.
You have more options, not less, you can still use the external dependencies.
Some of these feel like solved problems effectively, so having them in the standard library is nice (at the expense of keeping these forever for backwards compatibility once a new tech replaces it). I do think having a larger standard library for common things (like golang) is the way to go. If a dependency seems to basically be installed by default everywhere, maybe it should go in the standard library.
> It's weird their promotional video repeats "you can do <million things> without installing dependencies",
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.
The complaint was micro-dependencies and huge sprawling trees. What was needed was quality dependencies on the level of SDL, ffmpeg, libcurl, where one domain is solved well and the focus is on API stability and good implementation. Not a battery included type of things.
I personally do not feel limited by the ~100mb binary size. We're working in Javascript after all.
I've still yet to run into any enterprise project using bun in the wild. It really feels like something entirely contained within startups that would choose wildly inappropriate tech like next.js.
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.
From the release video, something catching my attention:
> 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".
[1] https://bun.com/blog/bun-v1.4#we-rewrote-bun-in-rust
This is a huge win for Bun & Anthropic. I've been keeping an eye on Bun development cycle since they announced the Rust rewrite and the huge drama and backlash it generated. They seem to be proving the skeptics wrong with this release.
I like how the "over 10 MB smaller" is dubbed, sure the video was recorded some time ago and that number changed.
https://youtu.be/i38DgEuaJwM?si=6oKAysKoRDPCihsL&t=176
I recently pivoted to Rust for the backend development, after getting tired of the nodejs ecosystem fragmentation and how fragile things feel. Bun seems very interesting since it allows you to do so many things without pulling in 3rd party libraries and bundlers? Is anybody using it instead of nodejs? how's the experience so far? I might have to give it a try.
Yes, I know there's probably better options than Rust for building APIs, but I wanted to learn it, so why not?
I always use Rust. You've made the right choice.
While it has been used by Anthropic, the main question is if it works in other Bun's 1.3 production settings. Ignoring all the improvements, if it does work and no major bug or problems occurred, We are in for some management top down "Rewrite it in Rust" action over the next few years. And perhaps even worst, management will believe in Claude feed into Claude development.
This isn't so much about Bun or Node.js any more. It is the battleground for AI and non-AI coding.
Announcing that the SSR memory leak is gone as part of a product launch is wild.
I wonder what was total token cost of the rewrite.
every couple years someone rewrites the whole toolchain and we collectively agree the last one was the mistake. good to know the cycle still works.
This blog post / changelog is extremely long. Around 50 metres long on mobile.
It's pretty long, but looking through it the text seems pretty streamlined. I think there's just a lot of changes.
They recently used AI to rewrite the whole app in rust. Expect the slop fest to continue for some time yet.
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.
Congratulations to the Bun team!
This is awesome.
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
https://bsky.app/profile/jacob.gold/post/3msvjwys7lc2t
Hey, did the memory leak really solve with slop rewrite?
omfg, that's a long post.
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?
Unlimited full-access to one of the best LLMs / agents on the market, and 80 hour work weeks probably.
I, for one, don't welcome our new AI overlords