作者 | Denis Pushkarev

译者 | 核子可乐

策划 | 刘燕

大家好，我是 @zloirock （Denis Pushkarev），一名全职开源开发者。

其实我不爱写长文，这篇文章原本只想聊聊 core-js 的后续主要版本和发展路线图。但受到近期一系列事件的影响，这篇文章变得这么长。

我就直说了……我烦透了，免费开源软件的根基已经崩塌了。其实我可以直接转身离去，但面对这片自己曾经倾注了热情的社区，我还是想最后说点什么。

Core-js 是什么？

它是 JavaScript 标准库中最流行也最常用的 polyfill，为最新的 ECMAScript 标准和提案提供支持，包括古老的 ES5 功能到迭代器助手等前沿选项；就连与 ECMAScript 密切相关的 structureClone 等 Web 平台功能也离不开它的协助。

它是目前最复杂也最全面的 polyfill 项目。截至本文撰稿时，core-js 包含约 5000 个复杂度各异且彼此协同的 polyfill 模块 — 包括 Object.hasOwn、Array.prototype.at 到 URL、Promise 和 Symbol 等等。虽然在其它架构中，大家也可以把各模块作为单独的包来使用，但总归不如 core-js 这么方便。

它高度强调模块化——大家可以轻松、甚至自动选择只加载要用到的功能，而且 core-js 能在不污染全局命名空间的前提下起效（有人称这类用例为「ponyfill」）。

它在设计上充分考虑到了工具集成需求，并提供所需的一切支持——@babel/preset-env、@babel/transform-runtime 以及基于 core-js 的类 SWC 功能等。

就是因为有了 core-js，开发人员多年以来才能随意使用现代 ECMAScript 功能，只是大多数人并不知道背后的功臣就是它。 因为 core-js 在间接起效，所以用起来让人感觉支持是由转译器 / 框架 / 中间包（例如 babel-polyfill 等）实现的。

Core-js 并不是框架或者库，所以开发者不用了解相应的 API 或者说明文档就能享受它的好处。即使是直接使用，开发者也只需要导入某些行或者配置，之后就可以撒手不管了。深藏身与名的 core-js 会默默提供 Web 标准中的各类功能，包括开发工作中必不可少的各种 JS 标准库功能。

Core-js 的月均 NPM 下载量为 2.5 亿次，总下载量高达 90 亿次，1900 万次 GitHub 仓库依赖 — 这些都是相当惊人的数字。但这仍不足够概括 core-js 的真正热度。

我写了个简单的脚本，用来检查 Alexa 热门网站列表中 core-js 的使用情况。可以看到，这里包含的都是最明确的 core-js 用例和相应版本（仅限较新的几个版本）。

目前，在对全球 TOP 1000 网站进行统计后，脚本发现有 52% 的测试对象在使用 core-js。根据月度波动，实际结果可能会有几个百分点的变化。但这还只是使用现代浏览器在初始页面上进行的粗糙检测，有很多用例没有被真正纳入统计。人工检查后，数字还能再增加百分之几十。例如，以上截图中有很多公司的初始页面中包含 core-js 但却被我这脚本给漏掉了，例如：

在手动检查之后，前百大网站中有 75 到 80 个中包含 core-js，而脚本给出的数字则只有 55 到 60 个。把样本量进一步放大，统计缺失也会更加严重。

Wappalyzer 可以使用浏览器插件来检测技术使用情况，也包括 core-js。之前我做过测试，但现在他们的网站只提供约 500 万条公开结果。从现在的 Wappalyzer 来看，core-js 在 800 万个移动页面和 500 万个桌面页面当中，分别占比 41% 和 44%。而根据 Built With 的调查，core-js 在 TOP 10000 站点中的覆盖率为 54%。同样的，我并不确定这两项检查是否完整。

总而言之，我们可以自信地说，大多数流行网站都在使用 core-js。对部分大公司，即使他们的主站点上没用 core-js，它的身影也一定存在于某些项目当中。

那网站上普及度最高的 JS 库是什么？答案既不是 React 或者 Lodash，也不是其他备受关注的库或框架，而是“已显陈旧”的 jQuery。

而且 core-js 负责支持的不只是网站前端，同时也被广泛应用在一切跟 JavaScript 有关的场景下。

但因为不显山、不露水，几乎没人意识到自己正在使用 core-js。我为什么要强调这一点？这可不是想邀功，而是向大家证明目前的开源生态有多恶劣。

2012 年，我开始把自己的开发堆栈转为全栈 JavaScript。那时候的 JS 还太过原始，IE 也仍是市场上份额最高的浏览器。ES3 时代的浏览器拥有不小的比例，最新的 Node.js 刚刚来到 0.7 版。必须承认，这时的 JS 还不适合编写严肃应用程序，开发人员需要使用 CoffeeScript 等语言的编译器解决 JS 在语法、标准库和 Underscore 等库的缺失问题。当然，这些慢慢都成了历史，关注未来的我决定全面拥抱即将发布的 ECMAScript 6 标准。

但陈旧的 JS 引擎太流行了，加上用户并不急于忙着更新换代，所以即使在实质上已经没有任何采用门槛，ECMAScript 在之后的很多年里也仍然依赖于 JS 引擎。但我们也可以尝试借助某些工具，挖掘出 ECMAScript 标准中的支持特性。那时候，解决语法问题还得靠转译器，标准库问题则依赖 polyfill。而各种现在大家离不开的工具包当时也才刚刚出现。

在此期间，ECMAScript 转译器大行其道并蓬勃发展。但与此同时，polyfill 则没能跟上用户和项目的实际需求。它们缺乏模块化特性，必须得污染全局命名空间才能正常起效，所以并不适合搭配库来使用。虽然选择由不同作者编写的 polyfill 库并搭配使用并不算特别复杂，但在很多场景下仍然阻碍重重。总之，其中缺少大量必要的基本语言功能。

为了解决这些问题，我从 2012 年开始为自己的项目开发起了解决方案，这就是后来的 core-js。我希望能让所有 JS 开发者工作起来更省心，所以在 2014 年 11 月，我把 core-js 发布为开源项目。而这，也许是我一生中最大的错误。

我显然不是唯一受语言功能缺失困扰的开发者，所以短短几个月后，core-js 就成了 JS 标准库实现 polyfill 的最优选项。当时的 core-js 被集成至 Babel 当中，而 Babel（当时还叫 6to5）的诞生比 core-js 只早几个月。

之前提到的问题同样困扰着这个年轻的项目。经历了更名，core-js 开始以 -babel-polyfill 的名义接受贡献。经过几个月的合作，出现了另外一款工具，并最终深化成了 bael-runtime。又过了几个月，core-js 被整合进核心框架当中。

我犯的第二个错误，就是没有认真推销自己或者项目。

Core-js 没有网站或者媒体账户，只有 GitHub 代码仓库。我没在开源会议上搞宣传，甚至连帖子都很少发。我只想做个既实用、又能支持现代开发堆栈的工具，这样就挺好。在它的帮助下，开发人员能够享受到最现代、最实用的 JS 功能，不用再坐等这一切被缓缓纳入 JS 引擎。另外，core-js 也消除了兼容性和 bug 隐患，于是项目开始广泛传播，很快得到几十个流行网站的采用。

但这还仅仅只是开始。

接下来就是持续多年的艰苦工作，我每天都要花几个小时来维护 core-js 和相关项目（主要是 Babel 和 compat-table）。

Core-js 绝不是那种写完之后就万事大吉的小库。 跟绝大多数库不同，它会受到 Web 状态的约束，需要对 JS 标准或提案中的变更、新的 JS 引擎版本、JS 引擎中的 bug 检测等做出反应。

于是乎，ECMAScript 2015 发布新提案、ECMAScript 推出新版本、新的非 ECMAScript Web 标准 / 引擎 / 工具等出现之后，core-js 也一直在随之变化。项目的演进、改造和对 Web 现状的适应从未停止，而普通用户几乎完全感受不到这一切。

只有工作规模在不断扩大，不断扩大……

长久以来，我一直在用各种方式寻找其他维护者，至少能找几位持续贡献者也行。但所有尝试，无一例外全部失败。

几乎每位 JS 开发者都间接用到过 core-js，也知道 babel-polyfill、babel-runtime 或者框架 polyfill 的各种功能，但却没人听说过 core-js。在部分关于 polyfill 的帖子里倒是提到过 core-js，但用的表述是“一个小库”。

反正 core-js 没啥人气、也没啥讨论热度，既然它就在那静悄悄地干活呢，何必要费劲去帮忙维护？随着时间推移，我终于对整个社区绝望了，剩下就完全是凭着一股责任感继续独自工作。

几年之后，我发现全职做开源开发已经彻底没戏了——既没人愿意向开源贡献者付钱，也没多少人愿意拿出业余时间参与其中。

但我没办法，有时候 core-js 会整整耗上我几个礼拜的时间，但为了让社区能继续有强大的 polyfill 可用，我只能把经济问题先放在一边。

这就是我，不仅辞去了原本的高薪工作，后来还拒绝了好几份相当诱人的邀约。因为一旦接受，我知道自己就再没精力从事开源工作了。这就是我的全职开源生存状态，没有任何人愿意掏钱支持。

我其实还抱有一点期待，希望早晚能找到一份可以全身心投入的开源 Web 标准工作。为了撑起开源开发和日常工作，我只能定期找几份短工。

我回到了俄罗斯，这边生活成本比较低，所以我对收入的容忍度也就更强了。但这又是另一个错误——钱很重要，我稍后会具体向大家解释。

到 2019 年 4 月，我已经参与 core-js 项目一年半了，全职做开源也有半年左右。我心无旁骛地开发 core-js@3，对 polyfill 相关的 Babel 工具做了全方位改进，让它真正成为几乎无处不在的重要工具包。

在 core-js@3 发布的三周之后，我遇上了重大变故。

那是四月的一个晚上，我凌晨 3 点开车回家，路上遇到两个喝得烂醉、穿着深色衣服的年轻女孩，她们当时正摇摇晃晃穿过一条昏暗的高速公路。我撞上了她们，后面的事情记不太清楚了。

有目击者说其中一个直接躺在车底，另一个在使劲想把她拽出来。虽然证人证明之前这两个人确实是在高速路上打闹，但这里是俄罗斯，只要你不是那种达官显贵的子女，那撞人者几乎必然要被判有罪。

行人是弱势群体，开车的人有责任注意路况。这就是我，一瞬间被打落谷底的普通人……检察官最终要求入狱 7 年，或者用钱跟“受害者”私下和解。事故之后又过了几周，我收到了“受害者”亲属给出的条件，按当时汇率计算赔款是 8 万美元。这还不算聘请律师的费用。

其实对于优秀的软件工程师来说，8 万美元也不能算是特别大的一笔钱。但那段时间，我一直埋头于 core-js@3 的发布，期间不光没人付钱给我，反倒把我之前的积蓄给掏空了。 所以我拿不出那么多钱，也想不到能从哪里快速筹钱。我的时间不多了。

当时，core-js 已经全面铺开。虽然我一直没能给 core-js 找到贡献者，但这毕竟是个需要主动维护的项目，不能一直停留在原地。一旦入狱，不光我自己完蛋了，core-js 也会成为那么多用户的大麻烦。那可是世界上一半的网站，必须重视起来。

在之前几个月，我曾经尝试筹集资金来支持 core-js 的开发（主要是在 GitHub 和 NPM 上发布了 README）。结果是……每月进账 57 美元。是的，这就是开源社区愿意给一位保障网络兼容性的全职开发者开出的报酬