Thoughts on the Current State (Especially Quality Issues) and Future of Bun

My Thoughts on the Current State (Especially Quality Issues) and Future Development of Bun #27664

Description

Based on my experience with Bun recently, I really have a lot to say. Although I am just an ordinary developer, I feel it is necessary to express my views regarding Bun's future development.

I scrolled through Bun's official X account as well as the author's personal X account, and I found that even after being acquired by Anthropic, most of the official marketing is still obsessed with the "performance" narrative, namely, repeatedly emphasizing how much processing time a new feature cuts down compared to competitors or older features.

Then there are the new features.

Regarding the new features, the ones that left a deep impression on me are native support for Markdown and Stage 3 Decorators.

Stage 3 Decorators are certainly a great feature, but as for Markdown, I truly cannot understand: is rendering Markdown really the proper job of a JavaScript Runtime?

From what I knew about Bun previously, it can do almost anything, from a bundler to built-in database support — I could understand those previous features as Bun's "All-in-One" strategy. But I really cannot understand the Markdown support. I feel this is no longer "All-in-One"; this is "All-in-Everything." Doing this will truly cause maintenance costs to skyrocket.

Granted, Bun is now under Anthropic (acquired in December 2025), and Anthropic has a lot of money, but no amount of money can allow a team to add features limitlessly while also guaranteeing quality. That is extremely difficult.

Speaking of quality. I have expressed similar views in the comment sections of some issues(Issue 26660 and Issue 26625) before, but I assumed my views wouldn't get enough attention, which is why I opened this issue.

I think it was around 2023 when I first learned about Bun. At that time, star number and open issues weren't that high. Back then, I thought Bun was pretty good; although there were some minor bugs, it was generally acceptable.

But now, in March 2026, although Bun's star count has reached nearing 100k, the number of open issues has also hit a staggering 4.9k (Now it has dropped to 4.8k again and is now stably maintained at this level long-term) , and this is even with a bot automatically closing duplicate issues.

JavaScriptCore comes from Apple, and getting it to run on Windows indeed requires some adaptation work. I am also aware that in production environments, Bun mostly runs on GNU/Linux (especially backend web apps). From this perspective, it's understandable that Bun focuses more on POSIX-compliant operating systems like macOS and GNU/Linux — but right now, many developer-side tools like Claude Code and OpenCode are also based on Bun. Objectively speaking, the percentage of users running these tools on Windows is not trivial. You can't just abandon one group of users to cater to another, right? Moreover, even though I have now switched to macOS, I see many users in the issues reporting that Segmentation Faults also exist on macOS and GNU/Linux. This shows that the instability is not just limited to Windows compatibility issues.

Some time ago, I submitted an issue about a Segmentation Fault related to OpenCode. At that time, I was still using Windows 11 as my development environment. The AI @robobun very quickly called Claude Code and submitted a PR. I downloaded that PR to check it and found it didn't solve my problem, and I explicitly replied back then saying it didn't solve it. But unfortunately, this PR was still merged by the author. I opened another issue and did not get a meaningful response.

"Vibe coding" --- everyone is discussing this term, and sure, you can also have "Vibe Debugging."

But what is Bun? Bun is a runtime, it is an infrastructure! If it's a little demo, or a relatively unimportant app, I think handing it over entirely to AI for fixing is fine. But for the incident I mentioned above, can you really do that? AI is very important to Bun and to Anthropic, and I can understand Anthropic wanting to use @robobun as a window to demonstrate Claude AI's capabilities. But why merge this PR without conducting a rigorous PR Review? Isn't this just using AI-generated hallucinations to cover up Bun's quality issues?

Bun is long past being a seed-round project, Bun is now used by commercial products, and Claude Code's capabilities are built on it. I think this level of stability is hardly reassuring, nor can it bear the weight of an enterprise-grade production environment.

I strongly urge the Bun team to take the issue of stability seriously. To this end, I hope Bun can be like Microsoft: Since January of this year, Windows 11 has experienced a large number of stability issues, and Windows 11 has similarly added some flashy but impractical features. However, we see that Microsoft has committed to listening to users' voices in the coming months and focusing their efforts on fixing Windows 11's stability issues. I hope the Bun team can make a similar commitment and focus their energy on fixing Bun's stability issues.

Activity

- I think bun is fundamentaly different in what it tries to be. People who value stability over everything aren't going to choose bun anyway, they'll use .net or node. People who choose bun are making a conscious choice to compromise stability for DX and performance. Bun states their goal is 100% compatibility with node which is incredibly ambitious considering node has a long history, and is actively evolving in real time also accelerated by AI. Bun being a smaller project then Node really has no choose but to embrace commit first debug later strategy to catch up. Thorough review and testing of every pr would become a bottleneck. I'm your example the fix haven't solved the issue but didn't break anything either so it has net neutral impact and is an acceptable compromise for fast development rate. I think in the future Bun will have to reconsider their strategy and get to the more stable release model but it's not there yet. Going stable won't resolve 5k issues. I think the biggest problem is Bun not properly following semver. The version number is absolutely meaningless and rushed to declare 1.0 release for marketing purposes but it is what it is. - First, we must be clear about Bun’s current stage of development. It is not in its infancy. From its start in 2021 to the 1.0 release in 2023, and now in 2026, nearly five years have passed. Regardless of whether the 1.0 label contained a marketing element, in the industry context, it represents a commitment to being production-ready. Furthermore, if the latest version 1.3.10 is still viewed as an experimental plaything where basic stability can be sacrificed for speed, then what is the point of this version? In fact, from official promotion to heavy-duty applications like Claude Code that rely on Bun, it has already proven to the market that its positioning is Production-ready. - I have emphasized in my post that it is a runtime, It isn't a hello-world project, nor is it a product of vibe coding like OpenClawd. Its importance is far greater than those mentioned, which makes stability its absolute lifeline. It might be running on enterprise servers or being used by developers; in such cases, "merge first, debug later" is unacceptable. - I agree with your point that users will tolerate some risk in pursuit of DX and performance, but there is a bottom line to that tolerance. 4.8k unresolved issues are severely decoupled from a "Production-ready" positioning. If it were 2.8k or fewer, we could view it as the price of rapid iteration but 4.8k implies that the project's technical debt is quite serious. I’ve looked through issues from previous years and found a significant number from 2023 that remain open. - Furthermore, we cannot say that merging an invalid PR has no harm and no benefit. It’s like a house—if you add a brick and even the person building it doesn't know why it’s there, it creates a latent risk. I believe infrastructure cannot afford to have uncertain factors. - Performance, features, and stability are not zero-sum, especially with the support of a giant like Anthropic, which possesses immense capital and technical reserves. It is enough mature now. I don't think there’s any need to "All-in-Everything" anymore. Reacted by ZW, Agung Adhinata, Ruby Bui, Christian Emmer, Adarsh Madrecha, Alejandro, ericchase, Sijawusz Pur Rahnama, Pedro Sliuzas and Chan Kang

- Issue count is not really a reliable indicator for much of anything other than popularity. - Popular projects, especially of this complexity, simply do not have enough time/maintainers to ever handle the volume, and never will. - TypeScript has 5k open issues. I don't think anyone would say it's not production ready. - Also, concerning Windows compatibility: have you looked into dev containers? I am a Windows user and just run Bun on Linux through that. It's a very simple setup and might fulfill your needs. - I analyzed the first 7 pages of issue reports for TypeScript and Bun. From a data perspective, the numbers are both very large, and crashes account for 10-15% of the total issues in both cases. The numbers and proportions are very similar, but I think we need to dive into the details. - Let’s set aside regular bugs for a moment, such as edge cases in the TS type system (which account for most of them), and just talk about the crashes. However: -

TypeScript crashes occur during the compilation phase or as LSP errors, whereas Bun's crashes happen at running. The level of destructiveness is not in the same dimension. A TypeScript crash can be called a "bug," but a runtime crash can be called an "incident", the two are on different levels. If a piece of code causes TS to crash, a developer can use temporary workarounds to bypass it, however, if the issue is caused by a segmentation fault or GC, the difficulty for a developer to temporarily bypass it is much higher.

TypeScript also has a very high number of issues, and I believe that is also incorrect. I won't use double standards here; I will similarly maintain that TypeScript has quality issues.

Reacted by Gyen Abubakar Sadick, Witthawin Sirisiwaphak, Ruby Bui, Sijawusz Pur Rahnama and Pedro Sliuzas

Ny stance is entirely hypocritical. When bun introduced markdown I rejoiced because weeks earlier, I had been searching for a good package and did not find anything. The s3 and database packages on the other hand won't be used by myself and I do not see these modules to ever be as properly maintained as standalone solutions.

On the other hand, I would really wish linting / formatting would be part of the toolchain when talking about the one and only dependency we need, but looking at eslint / prettier / biome is realistically possible for bun?- In my opinion more communication and targeted marketing would be hugely beneficial at this stage instead of new features. We got build time macros, NextJS is the backbone of an entire company, but you barely find any mention about bake. - Whether you like it or not, many decisions are based on an emotional level. Technically bun is stable enough for productive use cases. I would not go back to NodeJS and as the technical decision maker in our company I am pushing the project. Anthropic wants AI / Claude to be viewed as the next good thing. Please keep us updated, tell us how great velocity increased, how issues are resolved quicker. Write blog posts and keep us in the loop and make us feel involved. The performance and speed narrative made bun big and was all over youtube and news. This is not novel anymore, you should proactively share your insight and make us feel involved to build confidence.

- So far Jared and his team has not disappointed yet. One of the major concerns I always had was that the project is being shouldered by just a few selected people and moving to Anthropic did not raise any confidence that this changed, quite the opposite due to the omnipresence of robobun. Reacted by Christian Emmer

- The number of issues is just one way to measure project health, a popular project such as bun is expected to have an ever-increasing number of open tickets. Overall, it is more surprising how oven can resolve the majority of requests without requiring any reproductions. Those are tickets that would be flat out closed in a lot of different repositories. The hurdle to open a ticket with the issue reporter is very low, this inflates the issue count even more. - But I found myself increasingly hesitant to update to new bun versions in our production system. There have been multiple revert commits on canary in the past weeks and similar worries as OP came up, that the sheer mass of merged code cannot be properly evaluated anymore. It is just by the nature of doing PR reviews that they follow more of a "does it look reasonable" instead of a thinking about the problem in depth approach. Again, bun has a good test coverage, and this is mostly a psychological issue on my side which is highly subjective. This is likely on me and nurukeu needing to get used to trusting AI agents. - The, "where does bun draw the line with feature" discussion is more nuanced and should be discussed. The http module receives a lot of fixes in every release. It is utilized in the wild by pretty much everyone using the runtime. On the flip side we just need to assume that the database layer has as many issues which no one bothered to report yet, it is worth the maintenance burden? Oven has telemetry data on usage so is it up to us to tell them about it? Ny stance is entirely hypocritical. When bun introduced markdown I rejoiced because weeks earlier, I had been searching for a good package and did not find anything. The s3 and database packages on the other hand won't be used by myself and I do not see these modules to ever be as properly maintained as standalone solutions. On the other hand, I would really wish linting / formatting would be part of the toolchain when talking about the one and only dependency we need, but looking at eslint / prettier / biome is realistically possible for bun? - In my opinion more communication and targeted marketing would be hugely beneficial at this stage instead of new features. We got build time macros, NextJS is the backbone of an entire company, but you barely find any mention about bake. - Whether you like it or not, many decisions are based on an emotional level. Technically bun is stable enough for productive use cases. I would not go back to NodeJS and as the technical decision maker in our company I am pushing the project. Anthropic wants AI / Claude to be viewed as the next good thing. Please keep us updated, tell us how great velocity increased, how issues are resolved quicker. Write blog posts and keep us in the loop and make us feel involved. The performance and speed narrative made bun big and was all over youtube and news. This is not novel anymore, you should proactively share your insight and make us feel involved to build confidence. - So far Jared and his team has not disappointed yet. One of the major concerns I always had was that the project is being shouldered by just a few selected people and moving to Anthropic did not raise any confidence that this changed, quite the opposite due to the omnipresence of robobun. - Honestly, I was in a very similar spot as you back then. Even though I wasn't a CTO, I had almost full decision-making power over the tech stack for several projects I was involved in. Not long after I first got my hands on Bun, I seriously considered migrating our production use cases over to it. - But there was one thing I just couldn't get past: JavaScriptCore. It’s mainly what powers Safari, and Safari’s compatibility with JSCore has never been great. Plus, running JavaScript on the server side has never really been Apple's priority. For me personally, from starting college to working until now, it’s been about 7 years, I’ve gone through three Macs on and off, but Safari has never been my default browser. - In contrast, V8 has Google constantly pouring resources into it. Both Node.js and Deno are built on it, the server-side ecosystem is more mature, and the community support is just better. I wasn't really willing to bet my production infrastructure on an engine where the server side isn't its core focus. So, I ended up sticking with Node.js, even though I really disliked CommonJS and was tired of how long it took for modern JavaScript features to arrive. For the sake of stability, I still chose Node.js. - Looking back, I think I made the right bet. Node.js has caught up a lot on modern features—native ESM, especially - require(esm), and partial support for running TypeScript directly.Reacted by Ruby Bui

- The AI @robobun very quickly called Claude Code and submitted a PR. I downloaded that PR to check it and found it didn't solve my problem, and I explicitly replied back then saying it didn't solve it. But unfortunately, this PR was still merged by the author. - Thank you for sharing that, yea it doesn't look like a healthy repository indicator. Does it happen on a regular basis?

- +1 on this. It’s also extremely hard to open an issue without it feeling like it has been forgotten. It seems like auto-generated PRs are not properly owned and quickly get forgotten as well. There is no clear ownership of issues or PRs, which makes asking for fixes or enhancements bothersome and tiring. Reacted by 190n, j7-Aski, BenjaBobs, Arnaldo Capo and Jon