Hi，大家好我 ssh，最近 Bun 被炒的火热，很多人都觉得我们又迎来了历史性的新工具，好用，快速！但是有人提出了反对意见，觉得 Bun 只不过是 yarn 和 npm 之间上演的故事的一个翻版：Bun 的炒作：我们是如何没有从 yarn 中学到任何东西。他预言，最终 bun 会失败，Node 会吸收它的一些优点，变得更好，接下来我来带大家一起看看这篇文章：

我们又要犯同样的错误了。我经常被提醒，每 5 年世界上的程序员数量就会翻一番，这意味着任何时候，有 50%的行业人员经验都不到 5 年。这可能就是为什么我们会一次又一次地被类似 Bun 这样的东西搅局的原因。我以前见过这种情况，能猜到结局。

第一部分 - Yarn 的故事

Yarn 和 Bun 有许多相似之处。它们都针对现有的开源系统，不是为这些系统做出贡献，而是单独去创造自己的技术。它们都宣称自己要快得多。它们的目标都是分裂生态系统。它们都没有很好的向后兼容性支持。而且它们都宣布正式发布 1.0 版本，可以用于生产环境了！……但是实际上都不支持 Windows（也就是说，根本还远远没准备好用于生产）。

那么 Yarn 发生了什么？它发布了 npm 所没有的十几个很牛掰的新特性。而且它们的速度比 npm 快很多。但随后...仅仅一年之后，npm 的速度就已经超过 Yarn 了。再过一年，Yarn 会发一篇博客解释为何它在速度上根本无法超过 npm，因为 npm CLI 是由同样负责 npm 服务器的人开发的，而那些服务器正是包下载和存储的地方。时至今日，这依然是事实。在 2023 年，npm 仍然比 Yarn 更快。它最初的卖点已经没了有 5 年之久了。

但是 Yarn 提供的其他特性呢？随着时间的推移，越来越多的特性被实现并发布在了 npm 中，而如今，所有Yarn 曾经独有的特性都已经内置于 npm 中了。当然，特性的实现会有细微的差异，对于那些真的在意 Yarn、Lerna、Turbo 和 npm 在 monorepo 管理上的细微差异的人来说，你可能更喜欢其中之一。但对于绝大多数用例来说，npm 实现这些特性的方式对几乎所有用户来说都非常好。

啊，但 Bun 肯定与众不同吧？是吧？我的意思是，它用ZIG编写的。而ZIG非常快...对吧？嗯，其实不太对。它并没有做什么神奇的事情，最终你能用它达到的任何性能都可以通过 C++（Node.js 使用的语言）实现。所以，就像旧的慢速 npm 的故事一样，一旦优先考虑性能，npm 就能跟上（甚至超过）竞争对手的速度。我可以看到在 Node 上会发生类似的事情。如果得到适当的关注，应该可以达到大致相当的速度，以至于差异可以忽略不计。当然...有点像这样。我的意思是，我们应该承认其中一些 Bun 吹嘘的基准测试是经过挑选的或不代表真相的。所以，即使是 Bun 自己也没能达到自己的营销炒作。但你懂我的意思。

回到 Yarn 的故事。当 Yarn 出现时，它说它支持 Windows。但在 Yarn 上工作的 Facebook 开发者都没有把 Windows 作为主要操作系统。所以当它发布时，他们很快发现 Yarn 事实上不支持那个平台。

一个小插曲: 嗨，Primagen（其他人可以跳过这部分）。现在我知道，你已经对 Windows 发表了挖苦的评论。但或许你应该真正珍视我们社会中的多样性，并接受不同的生活方式。我的意思是，我理解。我完全理解，Windows 用户只占了电脑用户的 90%的微不足道的少数。但也许...我们应该尊重那仅仅引起轻微注意的少数群体。:） 回到故事中。

所以在大约 2 周后，他们终于“修复”了它，Yarn 可以在 Windows 上安装和运行了...勉强可以。我自己实际上一直到它们切换到使用corepack之前都无法让 Yarn 在 Windows 上可靠地运行。一旦你可以通过 npm 安装corepack，然后在它之上安装 Yarn（或 pnpm），它终于以一种可靠、无 bug、不会崩溃的方式兼容 Windows 了。但在那时，Facebook 已经放弃了 Yarn，其他人也慢慢地跟进，到它能在 Windows 上运行的时候，它已经正在衰落了。

时至今日，我从未能够让一个 Yarn monorepo 在 Windows 上运行。我确信这是不可能的。任何说自己做到了的人都是在对你撒谎。当然，也许在某个 Windows 虚拟机上什么都没装（甚至没有 Windows 更新），可能有人让一个 Yarn monorepo 在 Windows 上运行了几秒钟。也许他们还在树林里看到了大脚怪。什么都有可能发生。但在一个真实的开发者笔记本上，PATH 中有各种随机东西，还安装了 Node、nvm-windows、volta 和知道还有什么其他随机东西，不，它不工作。

好的，Yarn 出现了，迫使 npm 变得更好，然后死去了。问题是什么呢？如果它只做了这些，那么 Yarn 会很完美，但遗憾的是事实并非如此。npm 致力于开发和发布绝大多数用户需要的特性。但 Yarn 关注的是Facebook需要的特性。其中许多对使用 npm 的 99%的人来说并不重要。然而，一旦人们开始使用 Yarn，npm 就不得不重新确定他们将开发和发布哪些功能。它们不得不快速赶上，增加与 Yarn 所提供的功能等效的功能，以避免生态系统分裂。但 Yarn 进行了非常好的营销，人们买账了这种炒作。即使是我，当 Yarn 出现时也对它很兴奋，直到我发现它实际上无法在 Windows 上运行。但其他人没有意识到这一点，或者不在乎这一点，并采用了它......于是......

...然后 Yarn 变得部落化了。愚蠢的人类。一切都必须变得部落化。在好几年的时间里，有成千上万的自述文件仅告诉你 Yarn 的安装说明才能安装这个项目。这让新开发者感到困惑。我无法告诉你有多少初级开发人员来询问我这个“Yarn 东西”是什么，他们是否需要它。认为只有用 Yarn 这个项目才能工作。多么浪费每个人的时间和精力。

我一直认为 Facebook 的某个人只是发现，说服老板让他花时间为一个他无法获得荣誉的开源项目添加功能是很难的。对他们来说，如果可以用于招聘的营销，那就更容易获得批准来开发这些功能。这总是感觉像NIH 综合征

（注：NIH 综合症（英文：Not Invented Here Syndrome），指的是社会、公司和组织中的一种文化现象，人们不愿意使用、购买或者接受某种产品、研究成果或者知识，不是出于技术或者法律等因素，而只是因为它源自其他地方。在国家范围内的 NIH 综合征是民族主义的一种形式，比如中国历史上曾经出现的抵制日货运动。from：百度百科）

如果 Facebook 只是向 npm 贡献他们想要的特性，那么他们的特性会和 npm 已经在开发的特性一起发布。但相反，它推迟了这些其他特性的发布多年，导致重复的工作。这一切又为了什么呢？Yarn 现在几乎已经死了，只有一些小众的极端情况除外。但我在过去一两年里都没有在自述文件中看到yarn add。这是过去时代的标志。

第二部分 - Bun 实际上更糟糕

与提供速度和十几个新特性的 Yarn 不同，Bun 提供了速度和 3 个左右的新特性。让我们简单过一遍。

1. 宏 - 用于构建过程中。有人称它是一个错误。我最大的担忧是，你的构建过程现在会受困于 Bun。除非它具有等效的宏系统，否则你无法切换到其他东西，或者你需要重新编写构建过程。你正在选择未来的技术债务。

2. bun.x api - 这些是字面上做同样事情的新的 API，“但更快”。这比宏更糟，因为现在你的代码是一个 Bun 病毒。如果我在 Node 中npm install然后运行你的包，在试图使用你的库时，我会得到ReferenceError: Bun is not defined。这迫使你的库的所有用户采用 Bun。这是与 Yarn 相似的另一次强制分割生态系统，但要糟糕得多。

• 我可以看到一些包装库，如果bun存在则使用更快的 API，如果不存在则回退到 Node。如果 Bun 稍微流行起来，我想这会非常常见。但这只是项目中需要维护的另一个依赖项，这在某种程度上打败了“一站式”系统的目的，该系统允许你跳过工具依赖项，如果每个人都使用它就不需要安装额外的工具库来使用它。

3. 元语言支持 - Node.js 应该内置 vue 模板编译器吗？这听起来绝对不可思议。Markdown 呢？Sass 呢？CoffeeScript 呢？是啊，这会非常愚蠢，一个一切都建立在其之上的平台内置这些东西。这会看起来非常短视。

   最后一点，内置元语言，更多地体现了 Bun 真正的本质。它只是一个技术的抽象层。它不是一个实际的替代品或竞争对手，它字面上就是一样的东西，只是已经内置了。这在理论上听起来不错，但最终非常糟糕。

   抽象可以很棒，能简化事情。我们来看看 webpack 的例子。Webpack 是...非常糟糕的。没有人喜欢处理它。这也是为什么每个 JS 框架都不得不为它构建一个抽象层，因为没有人想接触 Webpack。像 angular CLI、Create react App、Svelte CLI 或惊人的 Vue CLI（甚至有个 GUI）。我们把 Vue 作为例子，因为它在所有这些抽象中做得最好。vue.config.js 文件是一个简单的配置，隐藏了 Webpack 的所有复杂性，同时如果需要，仍然给你完全相同的控制级别。它还将依赖项数量从大约 30 减少到了 3。但然后 Vue 的创造者 Evan You 创建了 Vite。vite.config.js 的复杂性基本上与 vue.config.js 相同，除了他们不必维护一个完整的独立项目（Vue CLI）来实现这一点。从 Vue CLI 切换到 Vite，我最终获得了相同数量的依赖项和相同数量的配置代码。结果是 Vite 是一个抽象层，使用起来和它要取代的最佳抽象层一样简单。

• 元语言存在是为了填补原始语言中的差距，它们本质上是短暂和灵活的。就像在原始语言的坑洞上添加非常好的悬挂系统一样。直到原始语言可以填平那些坑洞。我们不再使用 CoffeeScript 的原因是，它提供的大多数功能在 ES6 中被添加了进来。css 已经慢慢地添加了“足够好”的等效物来代替一些高价值的 Sass 特性，我们第一次看到 Sass 使用量下降。但在这里，我们用最糟糕的模板系统 JSX 和最有争议的所有前端工具 TypeScript 内置到了 Bun 中。

• TypeScript 的使用率在 2020 年左右达到峰值（略超过 JS 生态系统的三分之一），并在过去一年终于出现首次衰退，因为它被类似eslint-plugin-jsdocs（[从这里开始]（https://github.com/tjw-lint/eslint-config-tjw-import#using-this））的更好、更简单的替代品取代，以及一个潜在的基于注释的 ES202X 官方类型系统，这可能会导致创建.ts文件的需求急剧下降。随着这些坑洞的修补，TypeScript 将需要找到新的坑洞来尝试填平并证明它的存在价值，或者接受它的工作已完成，慢慢消退。从不真正消亡，就像 CoffeeScript 仍在使用一样，但最终成为一个旧时代的标志。就像我们已经进化超越其效用的所有曾经有用的技术一样（LESS、Stylus、Sass、CoffeeScript、Yarn、Grunt 等）。

• Sass 是一个很好的例子。它曾一度[被约 96%的前端开发者使用，满意度超过 90%]（https://i.imgur.com/cEo358S.png）（《2019 年 CSS 状态》）。但随着元语言的 API 发展变得更复杂以解决更复杂的问题，它的使用和满意度有所下降。它不再专注于作为每个人的简单工具，而是专注于作为进行非常高级操作的人的非常高级工具。一个更小众的用途。

• 我不断地猜测，如果 Bun 在前一年推出，它会由什么样古怪的技术组合而成，以及它今天会被迫维护什么古怪的遗留代码。如果它在 Sass 使用率巅峰的 2019 年推出，几乎人人都在使用，把它内置到 Bun 中听起来很有意义，对吗？但是当 Sass API 全部更改且旧的导入系统完全被废弃时，你该怎么办呢？通常，你只需要为项目npm install所需版本的 Sass，并在代码与之兼容的情况下固定旧版本。但如果你在这方面使用 Bun，然后几年后回过头来，由于 Bun 中的 Sass 版本与你编写的 Sass 代码不兼容，项目现在无法构建，你需要花一天时间来确定你的代码实际需要哪个版本，并手动安装正确版本的 Sass 才能让你的项目再次运行。这就是为什么将元语言内置到 Node.js 或 Bun 中是疯狂的。但这就是他们所做的，我预见那些依赖它而不是将其作为一个简单的方便工具的人未来会遇到痛苦。

但 Bun 不是在做这件事。它没有采取一些困难的事情并对其进行更简单的抽象。它采取了 ESBuild 并像 Vite 一样对其进行了抽象。这并不是一个改进，它基本上是同样的东西。测试也是如此。它们甚至没有假装提供一些新东西，而是告诉你像平时一样用 Jest 或 Vitest 编写代码，它们会劫持导入并在后台用自己更快的代码替换它们。

Bun 只是在现有工具之上添加一个抽象层。这意味着它将永远落后，并且可以在该层面引入额外的 bug。这对于像安装依赖项、测试代码和构建要发送到生产的代码这样关键任务系统来说并不理想。

但是我们还没有谈到 Bun 做的两件最糟糕的事情，还有真正可怕的部分。

Windows

我吐槽 Yarn 在 Windows 上的糟糕支持。但是与 Bun 相比，它们看起来棒极了。起码它们在发布时有点Windows 支持。它只是偶尔勉强工作。但 Bun 吹嘘的几十个功能中，甚至一个也不支持 Windows 发布的“1.0 版本”。

“Windows 构建还在高度实验性阶段，不可用于生产。仅启用了 JavaScript 运行时；包管理器、测试运行器和打包器已被禁用。性能未经优化。” - 官方 Bun 1.0 博客文章

所以想象一下，他们刚刚启动，正在展示所有这些很牛掰的他们很兴奋的功能，并希望人们使用它们。更可能发生的事情是：

随着成千上万的人开始使用它并提供反馈、发现 bug、请求功能、需要支持，你认为他们会：

A. 在未来一年完全忽略所有新用户，专注于实现完整的功能平等并制作精心设计的、可靠的、超快速的 Windows 兼容版本。这可能会消除他们从最初的炒作周期中获得的势头，甚至可能让他们失去靠风投生存的资金。

B. 通过改进 Linux/OSX 版本使现有用户满意，因为它们已经基本上可以工作，这样产品就会看起来维护良好，可以在这些社区内慢慢获得采用，同时通过有意创建不可移植代码的部落开发者进行病毒式传播，他们知道它在 Node 上不会工作，甚至在 Windows 上也不会。

我真诚地相信他们有意让 Windows 版本正常工作。我只是一点都不相信，在发布 1.0 版本一年后，他们会在 Windows 版本上实现功能平等。**也许**到那时 Windows 版本会与 1.0 版本实现功能平等，但我怀疑他们不会在一年内停止对 Linux 版本的所有工作。到那时，两种风味的 Bun 会变得不协调，导致困惑。

这引出了 Bun 最大的缺失功能。

没有 Bun 版本管理器

在 Bun 内置的所有工具中，它们没有构建一个版本管理器，这在我看来是疯狂的。我认为 Node.js 本身不带版本管理器也很疯狂。让我们分解一下这个问题。在 Node.js 上，我有:

• nvm - 在 linux/osx 上大部分工作正常，但有些令人讨厌。
• nodist - 很不错，但只支持旧版本的 Windows。
• nvm-windows - 用于较新版本的 Windows，但几乎不起作用且 bug 缠身。
• volta - 它们中的 API 最差，但也是最稳定和可靠的，并且运行在所有的操作系统上，甚至是非常旧版本的 Windows。

为什么我必须了解这 4 个工具？这很愚蠢。但比处理做同一件事的 4 个工具更糟糕的是根本没有任何工具。

Node.js 比 Bun更关注向后兼容性。但随着时间的推移，即使 Node 也废弃了其 API 的一些部分。许多时候这是 V8 引擎本身废弃功能的结果。Node.js 现在在某种程度上参与指导 V8 的方向，即使对其有一定的影响，它也不可能避免所有中断性变更和废弃，这导致旧的 Node.js 代码在较新版本的 Node 上完全无法工作。

所以我一点都不相信 Bun 在第一次尝试中就做对了一切，它的任何东西都不会随时间而改变，你在其中编写的所有代码都将永远工作。特别是因为它们将继承他们使用的苹果 WebKit JS 引擎带来的任何废弃。

再过一年，当 Linux 上的 Bun 1.8 版本发布时，但 Windows 才达到 1.0 时怎么办？我的团队中的开发人员使用不同的操作系统（Linux、OSX、Windows）。如果我们不能自由切换 Bun 的版本，那么我们的 Linux 用户将无法降级到 1.0 版本，这样我们都可以使用相同的功能工作（慷慨地假设到那时 Windows 版本会发布）。

作为 Web 开发人员，我们使用 Grunt 作为构建工具。然后 Gulp 出现，使过程更简单，我们转向使用它。然后 Gulp 4 发布，完全改变了 API，没有人想处理它，所以我们切换到 npm 脚本进行基本的构建自动化。但随后我们想要实际的打包能力和 tree shaking。所以，作为整个 JS 社区，我们转向了 Webpack（或者更准确地说，它之上的抽象）。但 Webpack 缓慢且讨厌，所以 Vite 出现时我们都转向了它。

但是，你知道吗？我并不热爱 Vite。它现在是最好的工具吗？是的。但是我希望它在某些方面会更好。在未来的几年里会发现越来越多这样的事情，而且不可避免地会有人制造出比 Vite 更好的新工具，我会很高兴切换到它。并不是因为我喜欢改变工具，而是从实际角度来看，它会更好，我会看到其中的价值并切换。就是这样。

即使你认为“不，我们的工具没有可改进的地方了，我们已经完美实现了代码最小化”。你认为我们已经完善了 Web 上的一切吗？10 年前不存在而今天存在的 Web 特性有哪些？假设 10 年后我们终于有了某种代替 Web 组件并且不糟糕的东西。我们是否需要某种新的构建工具来转换我们的代码并利用这些本机功能？就像我们今天所拥有的那样？随着网络和互联网协议的变化和改进，我们优化包的方式也会改变。Web 一直在变化和发展。它从未停止。它将继续改变，我们的工具也将继续响应这些变化。

Bun 正在抽象化的所有内容也都是如此。它何时决定放弃其 ESBuild 抽象并切换到随后会出现的新事物？如果它太早切换，而社区选择了其他东西，它就需要再次切换？你可以做的防范用户 API 更改的事情只有这么多。如果所有 Bun 用户都需要维护大量 ESBuild 插件来与 Bun 一起使用，然后 ESBuild 被移除并在后台被替换，那么这些用户就会被困在旧版本的 Bun 上。

当你使用 Bun 来处理构建流程，并且也用它来处理核心 JS 运行时和测试工具时会发生什么？然后 Bun 对这些系统之一进行重大中断性更改，需要大量技术债务来更新代码库以切换到新版本。也许你所有的测试都需要升级才能与新系统一起工作（我在工作代码中已经进行了 3 次重大测试重构，最长的花费了大约 6 个月才完成，这种事时有发生）。这可能需要几个月，甚至一年的时间来升级所有代码。在此期间，你会被困在旧版本的 Bun 上，直到一切与新版本一起工作。但是哎呀！在 JS 运行时中发现一个大安全问题。所以你需要升级 JS 运行时，但你不能这样做，因为你的 JS 运行时、构建工具和测试工具都是相同的东西。在你的重大测试重构完成之前，你的代码都是脆弱的。在某些行业中，你需要在一定时间内解决安全问题。对于这些人来说，Bun 是不行的。

他们有方法可以处理这些问题，比如发布多个构建工具或测试工具，并通过 CLI 参数让你切换到新旧版本。但是他们能支持内置的多个替代工具多长时间呢？他们能负担得起支持它们全部吗？

随着他们在 Bun 中内置的各种工具抽象的增加，维系这一切的粘合剂迟早会成为太大的负担。Node、npm、Jest、Vite 等都是非常大且复杂的问题空间，每个工具都在单独解决。即使 Vitest，在后台有大约 80%的代码与 Jest 共享，仅尝试处理剩余的 20%也是一个重大努力。

当 JavaScript [Shadow Realms]（https://github.com/tc39/proposal-shadowrealm）发布时会发生什么？Vitest 已经计划采用 Shadow Realms 作为一种隔离 JavaScript 测试的方式，而不必启动新的 Node 进程。如果我的 Vitest 代码依赖于在这种隔离模式下运行，而 Bun 决定劫持我的导入而不是使用实际的 Vitest 导入，我的测试可能会开始随机失败，而我几乎没有什么可做的，只能从方程中删除 Bun，直到它们可以更新底层代码以使用 Shadow Realms。但是如果领域添加到 V8 中，然后苹果拖延几年时间才在 Safari 中添加支持会怎么样（他们经常这样做）。在这种情况下，Bun 字面上什么也做不了，只能制作自己的本机 shadow realms 实现，直到该功能内置到 Webkit 中。这将是一个相当大的承诺，长期来看也不是一个可扩展的解决方案。

所有这些原因都说明 Bun 版本管理为何如此重要。以及为什么将这么多工具组合在一起听起来在理论上不是那么好。

第三部分 - 随想

• 如果 Bun 在 2012 年推出，它会内置 Grunt。
• 如果 Bun 在 2014 年推出，它会内置 Gulp。
• 如果 Bun 在 2016 年推出，它会内置 Webpack。
• 如果 Bun 在 2018 年推出，它会内置 Rollup。
• 如果 Bun 在 2020 年推出，它会内置 ESBuild。
• 2026 年会发生什么？
• 2014 年，Meteor JS 推出，承诺将一切打包成一个前端/后端框架。它会为你处理 Websocket，以及反应式更新 dom 并在请求失败时自动回滚 UI，以使 UI 感觉非常快速和敏捷。它让多个人可以在同一页面上实时交互内容。你所要做的就是使用他们的一站式 CLI 在本地运行项目并将其部署到使用你自己的自定义项目名称的免费在线测试平台。
• 2023 年，我尝试再次运行我的 2014 年 Meteor 项目，与该项目兼容的 CLI 版本不再存在，如果不完全重写整个项目到最新版本的 Meteor，该项目无法本地运行或部署。所有 2014 版本的文档都消失了。
• 我见过这部电影，我知道结局。

第四部分 - 最后思考

在这篇文章中，我非常严厉地批评了 Bun，不是因为它很糟糕，而是因为它几乎很好。人们会兴奋地去试用它，而不会意识到所有缺点。同样，就像 Yarn 一样，一开始我对 Bun 也相当兴奋。但后来我平息了兴奋，从实用和历史的角度来看待它。

如果 Bun 真的做到了它声称的一切，那么我会 100%支持它。但是不可移植的代码、完全缺乏 Windows 支持以及他们做出的一些短视选择让我回到现实。

我希望这些批评会导致 Bun 的改进。我希望这种思考过程能让其他人以更谨慎和深思熟虑的角度来看待 Bun。我希望这些关于 Yarn 和 Meteor 的故事能让我们作为一个社区从过去中吸取教训。

第五部分 - 我对未来的预测

• 在未来一年左右，Bun 针对的大多数项目将获得性能改进，缩小它们与 Bun 之间的差距。

• 你会开始看到越来越多仅在 README 中提到 Bun 的仓库，可能专门说明 Bun。

• 所有在第一份开发工作后 6 个月就辞职成为 YouTube 编码推手的开发者都会制作一个“BUN 是未来，天啊！”视频，缩略图类似[这样]（https://i.imgur.com/pSJeVMu.jpg）。希望它能欺骗人们观看他们关于 Bun 的 12 部分教程系列。喜欢和订阅。

• 我们还没有完善我们的工具。随着我们继续发展和发明新的更好的选择，Bun 将难以跟上，当人们不耐烦并愿意安装一个依赖项时，它的使用量会慢慢减少，因为这意味着一个比他们拥有的解决问题的更好、更实用的解决方案。

• Bun 可能会存在大约 5 年。这似乎是大多数类似工具的生命周期。

• Bun 最终会有非常非常好的 Windows 支持...可能就在人们停止使用它的时候。

• 出于某种原因，Bun 从未添加版本管理器，而是出现了 4 个竞争的选择，每个都以不同的方式存在问题。

• 今年是 20XX 年，我们终于将最后一个 CJS Node 模块转换为 ESM。这只有在人类最终屈服并让 AI 接管之后才有可能。这是值得的吗？

• 乔布斯拜登将获得第二个任期，但没有人对此感到高兴。

• 原来那个 Yarn 开发者真的见过大脚怪。现在我觉得取笑他很糟糕。老实说，《Harry and the Hendersons》值得重温。

• Vue 仍然比其他任何东西都好，但人们只会使用 youtube 程序员所说的热门新事物，如果不是的话，他们为什么要制作 20 个关于它的教程视频？

• 他们要重拍《绝命毒师》，但估计不咋样。

作者 ssh，工作 6 年+，阿里云、字节跳动 Web infra 一线拼杀出来的资深前端工程师 + 面试官，非常熟悉大厂的面试套路，Vue、React 以及前端工程化领域深入浅出的文章帮助无数人进入了大厂。

来源：ssh前端

链接: https://fly63.com/article/detial/6728