我听说这个世界上曾经有一批非常神奇的程序员，他们一言不合就爆改核心系统，快速发布，给产品打上自己的烙印。
例如Brendan Eich，仅用 10 天就开发出 JavaScript 原型，为网页交互式内容奠定标准。
Ken Thompson，老婆离家三周，他就写了个操作系统：Unix。
Ryan Dahl， 开发了Node.js，几乎凭借一己之力把JavaScript带到了服务器端。
John Carmack，将游戏拆解成引擎+内容，并且通过在Doom和Quake引擎中极端的性能优化，让3D游戏成功运行在消费PC之上。
5年前，我也有幸成为了他们中的一员。
01
高中辍学
我非常幸运，生活在加州湾区，从小到大，几乎所有时间都泡在电脑前，学习了各种计算机知识。
高中的时候，我自学Ruby on Rails，并且写了一个应用，老师们还觉得挺不错的。
当时我就想，我都能独立完成应用了，是不是也可以找到工作了？
我学习成绩不咋地，很讨厌学校，于是就给湾区的公司发邮件，没想到真有一家让我去实习了。
于是，我高中辍学，开始了程序员的生涯。
14岁时我就看Hacker News，上面的各种创业故事深深地影响了我，所以也搞了一些零散的“创业”：
一个 Pokémon Go 地图，2016年Pokémon Go 爆火,有 490 万人使用。
一个 Chrome 扩展程序，可以让用户在不分享密码的情况下访问网站，也有几百万人使用。
后来我加入了Stripe 担任前端开发，积累了大规模前端架构经验和高性能 Web 应用开发经验。
02
难以忍受的45秒
2021年，我正在开发一款对性能要求极高的多人浏览器游戏，它有点像 Minecraft，但用的是 JavaScript。
开发这款游戏非常困难，代码库越来越庞大，每次我在编辑器中保存代码，到在浏览器中看到更改效果，竟然得等45秒！
这种糟糕的“开发-反馈”循环实在是不能忍，我必须要做点儿什么事情了。
首先，我尝试用Zig这个编程语言重写了esbuild的JSX和TypeScript转译器。
效果非常惊人，比esbuild快3倍，比swc快94倍，比babel快197倍。
接下来我又尝试让 Next.js 跑起来，这次就难了，因为必须得实现服务器端页面渲染（SSR）。
没错，就是需要一个JavaScript运行时环境。
我测试了JavaScriptCore 和Chrome V8，发现在所有基准测试中，JavaScriptCore 的启动速度都更快。
那就用JavaScriptCore重写一个JS运行时吧。
悲催的是，JavaScriptCore这个JS引擎是WebKit的一部分，而WebKit是一个超级庞大，耦合严重的大型代码库，里边除了JS引擎，还有HTML Parser，CSS Engine，Layout Engine等等。
所有东西搅成一团，官方只有一些简单的C API文档，让你实现一些简单的功能，想把JavaScriptCore单独“拿”出来，充当JavaScript的运行时是在太难了。
我算是理解当初Ryan Dahl为啥选择V8来做Node.js了.....
我没有办法，只好疯狂地去阅读WebKit的源代码，一个月后，我终于把JavaScriptCore给剥离出来了。
另外我对npm也极为不爽，npm install 由于小文件太多，速度巨慢，node_modules简直是依赖地狱。
既然都重写runtime了，那顺便把npm也重写了吧！
这一年真是疯狂，大部分时间，我都待在奥克兰一间非常狭小的公寓里，每天除了写代码就是在推特上发关于 Bun 的内容。
是的，我把我写的打包器、转译器、运行时、包管理器叫做Bun，就是兔子的意思。
03
兔子来了
在互联网文化中，Bun经常表示：敏捷，快速，高繁殖速度（疯狂增长）。
很多人说，看到bun install 就想笑，因为看起来像npm install的萌化版，有种“Node世界太沉重了，来只兔子把它撞翻的感觉”。
2022年7月，我正式发布了Bun v0.1.0 。
这个消息立刻在JavaScript圈引发了一场地震，开源第一周，Bun就获得了2万的GitHub Star。
用户纷至沓来，我根本没法写代码，每天的工作就是回复用户的消息。
网上疯传着类似这样的图：
可以说，Bun的工具链对Node产生了碾压般的优势。
很多人看到Bun源码时惊呼：“这玩意儿居然是一个人写的！”。
确实，v0.1.0的时候我没有团队，我一个人：
读 WebKit 源码
实现JavaScript runtime
实现Node compatibility
写 package manager
这种风格确实有点像John Carmack和Ryan Dahl等人，在程序员圈传播力极强。
更重要的是，2022年的JavaScript生态，很多人已经进入了一个工具链疲劳的状态，每天面对着巨慢的npm install，爆炸的node_modules，前端程序员已经受不了了。
Bun就像一股清新的风吹进了JS圈，让人神清气爽。
04
终极解脱
但是Bun依然是个不太完善的产品，比如不支持Windows，和Node.js的兼容性还不太好。
不过，风险投资像鲨鱼闻到了血腥，蜂拥而来，Bun相继完成了种子轮和A轮两次融资，我在旧金山建立了一个十几个人的团队，开足马力完善Bun，相继发布了V1.0, 1.1,1.2,1.3 .......
但是，不论Bun有多么火，它的收入一直为0。
像Bun这样的工具，如果要赚钱，必须走 “开源+托管服务” 的模式。
这意味着我必须分出大量精力去开发云平台、处理计费系统、寻找付费客户，而不是专注于优化运行时（Runtime）的性能。
过早的变现欲望也会引发开发者的警惕：我能把公司的技术栈压在Bun上吗？它5年和10年后还存在吗？
但是世界在迅速变化，2024 年底，人工智能编码工具已经从“炫酷演示”变成了“真正实用”。
大家突然发现，Bun 作为一个运行时（Runtime），在处理 AI 生成的高频、碎片化任务（如瞬间启动、执行测试、自动修复代码）时具有天然的性能优势。
Bun还是一个天生的CLI分发工具，运行速度飞快，这简直是很多AI Coding Agent梦寐以求的基础设施工具。
比如Claude Code，就逐渐从Node.js转向了Bun，还有FactoryAI，OpenCode。
我们一直优先处理Claude Code提出的问题，我和Claude Code的核心负责人Boris Paskalev 也有过多次长谈，探讨AI编程的发展方向，达成了很多共识。
2025年12月，Anthropic 收购了Bun，承诺 Bun 将继续作为开源项目（采用 MIT 协议）存在。
我终于解脱了，不用再去苦苦寻找盈利模式，完全跳过了“变现”章节，专注于构建最优质的 JavaScript 工具链。
我是Jarred Sumner，这就是我和Bun在过去五年的故事。
最初，我只是想让 JavaScript 快一点，没想到撞翻了半个前端世界。
Bun这只兔子能跑多远？ 让时间回答，让代码说话吧。
码农翻身后记：
写完这篇文章，我一直在想，AI编程时代来临以后，像Jarred Sumner这样“一个人爆改整个系统”的程序员，以后还会出现吗？
理论上来说，应该会越来越多，因为AI赋予了程序员更强大的编程能力，但是我又觉得能做出这样创新工作的人，必须得敢想敢干，能挑战一切权威才行（就像Bun挑战了Node庞大的生态），而大多数人都是习惯于用别人发明的工具，默默忍受这些工具的缺点，最多吐槽几句。
所以，即使到了AI时代，创新型的程序员依然会非常稀缺的，你觉得呢？
热门跟贴