Matteo Collina是Platformatic.dev的CTO，同时他也是Node.js Stream主要负责人，著名的Fastify框架作者，mqtt，msgpack，pino等知名模块的作者。
以下内容来自Matteo Collina的订阅邮件《My thoughts on Bun and other Adventures》
大家好！
我写这篇文章的时候正在飞往伦敦，在那里我将与我的联合创始人Luca Maraschi一起工作整整一周。自上次写作以来，发生了很多新闻。
Bun 1.0
Bun发布了1.0版本，我既兴奋又失望。我非常喜欢Jarred Sumner正在构建的Bun，但他们声称与Node.js兼容性的问题让我有些沮丧。根据我的经验，它并不能完全替代Node.js，很多内部细节也有所不同。这导致了许多随机问题，我的代码库被要求修复Bun不兼容性的问题，而人们试用它。我更希望他们等待更大程度地与生态系统兼容后再发布1.0版本。
为什么Bun比Node.js更快？
原因如下：
- Node.js没有预算，一个小团队维护npm。大多数投资都是在添加功能或更安全的东西上，而不是让东西更快。让东西更快并不会让任何人赚更多的钱；这有点像公地悲剧（公共财产的悲哀）。此外，云提供商（现在是真正赚钱的人）对提高任何东西的性能没有兴趣，因为这意味着他们的收入会减少。
- Bun不关心与npm生态系统的重大部分的向后兼容性。他们使事情变快，并正在努力保留向后兼容性：这就是构建快速软件的方法。相反，Node.js流程是围绕保护生态系统而建立的。我们知道如何使Node.js更快，但这样做会为最终用户带来很多摩擦。
- 我相信开放标准和开放治理。运行时和基础设施更好（参见terraform的惨败）。拥有开放的治理意味着更广泛的决策过程，这使每个人都被听到，但这也需要更多的时间来做出决策。
Bun目前不支持Pino和Fastify
我写这篇文章时，Bun不支持Fastify或Pino。两者都是Node.js社区影响非常大模块，其中pino与Next.js一样受欢迎。Bun团队正在积极研究如何添加缺失的API和行为，我期望他们在未来几个月内追赶上来。鉴于有多少人要求支持，以下变体的消息最终出现在我的GitHub已保存回复中：
最终，Bun并没有实现所有的Node.js API。尽管他们声称是干净的替代品，但它并不能完全替代Node.js。有关此类问题，请参阅Bun Discord或Issue Tracker。
如果我的任何代码库在Bun上运行不良，请在Bun上报告错误。这也是Jarred要求每个人遵循的方法。
Bun安装速度的代价
Bun最令人印象深刻的事情之一是bun install的性能。然而，它以开发人员体验为代价。npm、pnpm和yarn默认会检查是否有新版本可用，并从注册表中获取它。相反，bun会首先选择本地版本。实际上，pnpm --prefer-offline标志的行为与bun install大致相同，并且它们的性能相当：在我的系统上，分别为750ms和150ms（请参见Evan You的这条推文）。尽管这种差异很重要，但这两个数字是可比较的，希望差距会缩小。
有趣的是，最终用户会如何评价这种行为上的差异。您会使用最新和最好的版本，还是使用已安装的本地版本，知道您可能会失去错误或安全修复？
我也对在Mac OS X上聪明地使用写时复制印象深刻，使其几乎在热缓存下瞬间完成。这部分是由于clonefile，它告诉操作系统只在第一次修改文件时复制文件，节省了宝贵的时间。我希望所有其他JavaScript包管理器都能复制这种技术。
Node.js接下来会怎么样？
几年来，Node.js在改进运行时性能方面投入了非常少的资源。去年，Yagiz Nizipli启动了性能团队，现在它是一个战略性的倡议。这导致了相当多的重大性能改进，由Rafael Gonzaga在“Node.js性能状况2023”中描述。每次发布，Node.js都会变得更快，而没有大规模的破坏性变化。
你想让Node.js变得更快吗？加入性能团队并做出贡献…或者找到一种资助Node.js开发的方式。
扫码关注“NPM学习”，选择“星标”公众号
重磅干货，第一时间送达！
