itHub 托管了大量的软件代码，

成为了开源繁荣的注脚。

它被称为全球最大同性交友网站……

陪伴我们已经走过 10 年时间

本文作者：光谱

1999 年上线的 SourceForge，因为免费一度是世界上最受欢迎的开源软件代码托管网站。然而 Google 担心它一家独大，上线了自家的代码托管网站 Google Code。

2005 年，Linux 的缔造者 Linus Torvalds 对现有的代码托管工具效率不满意，便自己做了一个名叫 Git 的版本控制工具。Git 颇具革命性，允许大量开发者同时为源代码贡献新代码，彼此间并不影响，最重要的在于它是开源的。

三个来自旧金山的年轻人认为 Git 的潜力巨大，在 2008 年正式推出了 GitHub，一个基于 Git 的代码托管网站。他们没想到，GitHub 后来击败了元老 SourceForge 和背景强大的 Google Code，成为了全世界最受欢迎的代码托管网站。

Google 的开源代码经理 Chris DiBona 对 GitHub 给予高度评价：

2008 年 4 月 10 日，GitHub 正式上线。

今天，GitHub 终于10 岁了！

去年 5 月底，GitHub 完成了第 1 亿个 pull request（PR 合并请求）命令。截至今天，GitHub 上已经拥有超过 8000 万个 repo（代码仓库），活跃用户达到 2700 万人，超过 150 万家公司和机构进驻。

由于程序员群体里缺少女性，拥有高纯度男性用户的 GitHub，也被戏称为全球最大的同性交友网站……

GitHub repo 按照语言划分的男女用户比例，最上面的绿色是确认的女用户（2014 年数据）

“10 年前的今天，GitHub 正式上线。最一开始，我们只有一个特别简单的目标：连接所有的开发者，让他们用 Git 更轻松地进行项目协作，”联合创始人 Chris Wanstrath 在博客里写道，“10 年过去了，我们作为公司，作为平台都有了很大的变化，但 GitHub 存在的意义从未改变。”

作为对十周年的纪念，GitHub 团队并没有选择回顾公司历史，而是整理了在他们眼中过去 10 年间的几大里程碑事件。这很 GitHub——这份光荣，其实不止属于平台自己，更属于那些为了让这个世界变得更好，通过 Git、GitHub，用 JS、Python 和各种语言贡献代码的人们。

以下，就是这些曾在计算机业界和 GitHub 的发展中创造历史的事件。

20080403: Rails 转移至 GitHub

Ruby on Rails (Rails)，是一个用 Ruby 语言编写的开源 web 应用框架。它提高了开发复杂网页的效率，是计算机界最受欢迎的开源项目之一。2008 年 4 月，Rails 做出了表率，将版本控制从 SVN 换成了 Git，并成为第一个进驻 GitHub 的大型开源项目。

当时，GitHub 还处在内测阶段，没有正式上线。GitHub 本身就是用 Rails 写的，这件事为 GitHub 带来了不小的影响力。

20090103：比特币诞生

2009 年诞生后，比特币于 2010 年正式开源，并托管在了 GitHub 上。比特币是世界上第一个去中心化的数字货币，它的诞生和开源更是引发了一场同时波及金融和科技，甚至更多行业的革命。

至今，比特币项目接受了超过 500 名用户贡献的代码。比特币的底层技术“区块链”被广泛视为下一个革命性的计算机技术，比特币项目已经被 fork （代码库复制）逾 1.8 万次，大量的区块链、数字货币项目在 GitHub 上开源，其中很多都来自比特币源代码。

20090521：Node.js 发布

你可能听说过网络开发分前端后端之说，前端管网页呈现，后端管数据输出。然而这两者不是孤立的，前端开发也会涉及到确保后端数据能够正确呈现出来，所以大量采用 JavaScript (JS) 语言的前端人士需要学习后端 PHP、Ruby 之类的后端语言，很麻烦。

Node.js 的主要意义是让前端用 JS 即可完成前端需要的大量开发任务，开发适配多种操作系统的复杂服务器端应用。简单来说，它同时把前端和后端工程师从各自不熟悉的领域内解放了出来。2009 年 5 月底，Node.js 正式在 GitHub 上发布，收到了不少前端和后端人士的追捧，被认为是未来趋势。

2014 年，Node.js 主要贡献者对这个项目的官方管理公司不满，于是自立门户，fork 原版代码做了一个社区驱动而不是公司化运营的替代品，名叫 io.js。这个项目一度比 Node.js 更受欢迎，但后来 Node.js 在开源治理上有了改善，两个项目再次合并。

在整个过程中，GitHub 的开放机制确保了社区拥有自主权力，不必服从于开源项目的所有者。在必要的时候，fork 是一种力量，也是一种态度。

20101126：Rails Girls 第一次线下聚会

2010 年，一群用 Rails 做开发的女程序员在芬兰赫尔辛基举办了第一次线下聚会。

三年后，他们专为女性和 LGBTQ 人士开设了一个夏令营 Rails Girls Summer of Code。这个开源培训项目帮助开源社区改善了性别多样性，为解决女性在科技行业内受到的结构性歧视做出了贡献。

20110101：Travis CI 持续集成的第一个 PR

持续集成 (CI) 从像 GitHub 这样的代码库里按照频率提取最新的代码，自动构建项目并进行测试。持续集成并不能消除 bug，而是让它们非常容易发现和改正。比如下面这个 build passing 就是持续集成工具显示的，它的大概意思是当前版本测试通过，没有出现 bug。

而 Travis CI 是最受欢迎的，开源的持续集成工具。2011 年元旦那天，它完成了第一个 PR。Travis CI 和 GitHub 的整合，让代码投入生产环境的整个过程变得更高效了

20120101：JS 成为 GitHub 第一大语言

最一开始是一种网页脚本语言，JS 和 HTML、CSS 并列网页开发三大语言。被 JS 坑过的程序员经常讽刺它是一种不完整的语言，有一个很古老的段子：写 C 的看不起写 C++ 的，写 C++ 的看不写 Java 的，写 Java 的看不起写 JS 的，写 JS 的看不起美工，周末大家都在加班，美工带着女朋友旅游去了。

然而编程语言的鄙视链，总是和受欢迎程度相反。从 2012 年开始，JS 超越了 Ruby、Java 和 Python，成为了 GitHub 上最受欢迎的语言，直至今天仍霸占王座。

2013：GitHub 用户破百万

开源社区的发展使 GitHub 获得了惊人的增速，在用户数和 repo 数上实现了两座里程碑：2013 年，用户数突破了 100 万；同年 12 月，GitHub 的 repo 总数超过了 1000 万，其中超过一半是当年创建的，仅 11 月就增加了 100 万个。

别光看数字多，这一年里增加的 repo 质量也很不错：白宫的 Project Open Data、Docker 等等。亚马逊 AWS、Facebook、Google、微软、Twitter、Netflix 等知名公司也上传了自家的项目。

20140609：Docker 1.0 发布

被视为革命性技术的开源容器引擎 Docker，2013 年在 GitHub 上创建了 repo，一年时间里下载量超过 275 万份。2014 年，Docker 1.0 终于正式发布了。

像 Docker 和 Kubernetes (K8S) 这样的开源项目开启了一场容器化运动。开发、投产和运维的难度降低，小型公司不再需要花费精力在基础架构上，可以更专注于核心业务开发。

20140721：Django Girls 第一次线下聚会

交友平台不是开玩笑……GitHub 的程序员社交特性使得很多开发者通过它实现了线下聚会。它让程序员们更容易结识彼此，而这对于女生尤为重要。

2014 年德国柏林，Django 女性开发者第一次在线下举办聚会，她们的组织仍在为改善性别多样性而努力着。

20140723：微软开源 .NET

虽然随着移动互联网的快速发展，没跟上时代的 .NET 已经走向衰落，微软向开源社区示好，仍然被视为开源业界的一个历史性事件。微软创立了一个开源行动，然后把所有的开源代码包括 .NET 都在 GitHub 上开源。数千名工程师也让微软成为了 GitHub 上最为活跃的公司。

.NET 的开源带起了一波节奏，随后越来越多的大公司迁移到了 GitHub，放弃了自己的代码托管网站或过时的代码库。

2015：虚幻引擎 4 免费和大量游戏相关开源

2015 年 3 月 2 日，虚幻引擎 4 完全免费了。Epic Games 放出了百分之百的 C++ 原始代码，虽然独立开发者想要开发 AAA 级别大作还是需要资金，但至少现在他们手上的虚幻引擎 4 和大厂手里的没有任何区别。

Epic Games 对社区的恩惠得到了报答。在虚幻引擎最近一次 4.19 版本发布，包含了 128 个来自社区的贡献。

除了虚幻引擎，还有不少游戏引擎、库和游戏代码在 2015 年上了 GitHub，比如《毁灭战士》和《波斯王子》。最有趣的应该是 2048，它的开源带来了上百款类似的消除游戏……总的来说是件好事。

20150922：GitHub Classroom 发布

除了工业界，学术界，包括大学和高中也可以利用 GitHub 进行教育了。GitHub Classroom 改进了编程课代码管理、分发和作业收集。看上去是在做慈善，其实此举很聪明：GitHub 普及要从娃娃抓起，尽管它已经碾压了其它一切竞争对手。

20151203：苹果开源 Swift

苹果的新编程语言 Swift 具有函数式编程和面向对象编程的诸多特性，也兼容苹果平台之前的开发语言 C、Objective-C，也是一个强类型语言而非脚本语言，也很注重安全性……对于苹果开发者而言，Swift 是件大好事，而有什么比 Swift 开源更让人大快人心呢？

如果说微软带起了一波节奏，那么苹果 Swift 编程语言的开源才真的让其它科技公司都信服。老大哥都开源了，我们还有什么理由不跟随呢？

20160709：阿波罗 11 号代码开源

60 年代的程序员也有幽默感，不信就去 GitHub 上看看阿波罗 11 号的代码。比如这个：临时代码一直用到了月球上。

你可能会感兴趣，50 年前的程序员和代码是什么样的？隆重向你介绍阿波罗 11 号计算机系统工程师，MIT 的 Margaret Hamilton：

阿波罗 11 号代码开源地址：https://github.com/chrislgarry/Apollo-11

2017：Python 进驻 GitHub

Python 因数据科学和深度学习的爆发重新开始受到关注，在 2015 年它成为了 GitHub 上第三受欢迎的语言，2017 年升至第二。当各大公司和人工智能专家开始倡导“人工智能普及化”(democratize AI) 时，Python 也终于来到了 GitHub。

这使得 Python 在 GitHub 上的流行越发势不可挡，使用 Python 语言的新 repo 数量，环比增长达到了 70%。

20170215：TensorFlow 1.0 发布

革命性的深度学习库，就连非专业人士都听说过 TF——主要可能因为 AlphaGo 击败了李世乭和柯洁。2016 年，TensorFlow 成为了整个 GitHub 上 fork 最多的项目。

除了 TF，Caffe2、DeepSpeech 等大量深度学习工具也都相继开源。使用这些工具，研究者可以创建面向不同领域的深度学习模型，包括并不限于电子游戏、弈类游戏、音乐、绘画、医疗、金融等等，带来新的技术范式和商业模式，显著改善人们的生活。

20180410：十周年，再出发

在 2017 年，用户提交了超过 2.9 万亿条代码，GitHub 也合并的 PR 终于突破了 1 亿。2018 年，GitHub 用户总量达到 2700 万，项目总数超过了 8000 万。

人工智能、区块链、量子计算……许多全新的计算机技术和全新的计算范式已经或正在赶来，代码和数据在某种程度上已经取代了石油，成为了人类的新血液。

在这样的大背景下，GitHub 太重要了，但它也面临着和 10 年前 SourceForge 等前辈相同的命运：全世界的开源代码都在这里，过度的中心化会否增加风险？在享受 GitHub 带来便利的同时，越来越多人都会多一个心眼——代码上传之后，本地还是不要 rm 留个底吧。

最后，给一些 GitHub 整理的资料。首先，按照 PR 统计的受欢迎语言，JS、Python、Java、Ruby、PHP：

热门关键字，机器学习、游戏、iOS、API、博客、网站、深度学习、Ardiono：

fork 最多的项目，TF、Bootstrap、gitignore；贡献者最多的项目，VSCode、React Native、NPM：

review 最多的项目，DefinitelyTyped、K8S、Homebrew；讨论最多的 repo，K8S、Origin、CMSSW

注册用户最多的国家：中国排第二

引言

如今，Javascript 模块化规范非常方便、自然，但这个新规范仅执行了2年，就在 4 年前，js 的模块化还停留在运行时支持，10 年前，通过后端模版定义、注释定义模块依赖。对经历过来的人来说，历史的模块化方式还停留在脑海中，反而新上手的同学会更快接受现代的模块化规范。

但为什么要了解 Javascript 模块化发展的历史呢？因为凡事都有两面性，了解 Javascript 模块化规范，有利于我们思考出更好的模块化方案，纵观历史，从 1999 年开始，模块化方案最多维持两年，就出现了新的替代方案，比原有的模块化更清晰、强壮，我们不能被现代模块化方式限制住思维，因为现在的 ES2015 模块化方案距离发布也仅仅过了两年。

2 内容概要

直接定义依赖 (1999): 由于当时 js 文件非常简单，模块化方式非常简单粗暴 —— 通过全局方法定义、引用模块。这种定义方式与现在的 commonjs 非常神似，区别是 commonjs 以文件作为模块，而这种方法可以在任何文件中定义模块，模块不与文件关联。

闭包模块化模式 (2003): 用闭包方式解决了变量污染问题，闭包内返回模块对象，只需对外暴露一个全局变量。

模版依赖定义 (2006): 这时候开始流行后端模版语法，通过后端语法聚合 js 文件，从而实现依赖加载，说实话，现在 go 语言等模版语法也很流行这种方式，写后端代码的时候不觉得，回头看看，还是挂在可维护性上。

注释依赖定义 (2006): 几乎和模版依赖定义同时出现，与 1999 年方案不同的，不仅仅是模块定义方式，而是终于以文件为单位定义模块了，通过 lazyjs 加载文件，同时读取文件注释，继续递归加载剩下的文件。

外部依赖定义 (2007): 这种定义方式在 cocos2d-js 开发中普遍使用，其核心思想是将依赖抽出单独文件定义，这种方式不利于项目管理，毕竟依赖抽到代码之外，我是不是得两头找呢？所以才有通过 webpack 打包为一个文件的方式暴力替换为 commonjs 的方式出现。

Sandbox模式 (2009): 这种模块化方式很简单，暴力，将所有模块塞到一个 sanbox 变量中，硬伤是无法解决明明冲突问题，毕竟都塞到一个 sandbox 对象里，而 Sandbox 对象也需要定义在全局，存在被覆盖的风险。模块化需要保证全局变量尽量干净，目前为止的模块化方案都没有很好的做到这一点。

依赖注入 (2009): 就是大家熟知的 angular1.0，依赖注入的思想现在已广泛运用在 react、vue 等流行框架中。但依赖注入和解决模块化问题还差得远。

CommonJS (2009): 真正解决模块化问题，从 node 端逐渐发力到前端，前端需要使用构建工具模拟。

Amd (2009): 都是同一时期的产物，这个方案主要解决前端动态加载依赖，相比 commonJs，体积更小，按需加载。

Umd (2011): 兼容了 CommonJS 与 Amd，其核心思想是，如果在 commonjs 环境（存在 module.exports，不存在 define），将函数执行结果交给 module.exports 实现 Commonjs，否则用 Amd 环境的 define，实现 Amd。

Labeled Modules (2012): 和 Commonjs 很像了，没什么硬伤，但生不逢时，碰上 Commonjs 与 Amd，那只有被人遗忘的份了。

YModules (2013): 既然都出了 Commonjs Amd，文章还列出了此方案，一定有其独到之处。其核心思想在于使用 provide 取代 return，可以控制模块结束时机，处理异步结果；拿到第二个参数 module，修改其他模块的定义（虽然很有拓展性，但用在项目里是个搅屎棍）。

ES2015 Modules (2015): 就是我们现在的模块化方案，还没有被浏览器实现，大部分项目已通过 babel 或 typescript 提前体验。

3 精读

从语言层面到文件层面的模块化

从 1999 年开始，模块化探索都是基于语言层面的优化，真正的革命从 2009 年 CommonJS 的引入开始，前端开始大量使用预编译。

这篇文章所提供的模块化历史的方案都是逻辑模块化，从 CommonJS 方案开始前端把服务端的解决方案搬过来之后，算是看到标准物理与逻辑统一的模块化。但之后前端工程不得不引入模块化构建这一步。正是这一步给前端开发无疑带来了诸多的不便，尤其是现在我们开发过程中经常为了优化这个工具带了很多额外的成本。

从 CommonJS 之前其实都只是封装，并没有一套模块化规范，这个就有些像类与包的概念。我在10年左右用的最多的还是 YUI2，YUI2 是用 namespace 来做模块化的，但有很多问题没有解决，比如多版本共存，因此后来 YUI3 出来了。

YUI().use('node', 'event', function (Y) {
 // The Node and Event modules are loaded and ready to use.
 // Your code goes here!
});

YUI3 的 sandbox 像极了差不多同时出现的 AMD 规范，但早期 yahoo 在前端圈的影响力还是很大的，而 requirejs 到 2011 年才诞生，因此圈子不是用着 YUI 要不就自己封装一套 sandbox，内部使用 jQuery。

为什么模块化方案这么晚才成型，可能早期应用的复杂度都在后端，前端都是非常简单逻辑。后来 Ajax 火了之后，web app 概念的开始流行，前端的复杂度也呈指数级上涨，到今天几乎和后端接近一个量级。工程发展到一定阶段，要出现的必然会出现。

前端三剑客的模块化展望

从 js 模块化发展史，我们还看到了 css html 模块化方面的严重落后，如今依赖编译工具的模块化增强在未来会被标准所替代。

原生支持的模块化，解决 html 与 css 模块化问题正是以后的方向。

再回到 JS 模块化这个主题，开头也说到是为了构建 scope，实则提供了业务规范标准的输入输出的方式。但文章中的 JS 的模块化还不等于前端工程的模块化，Web 界面是由 HTML、CSS 和 JS 三种语言实现，不论是 CommonJS 还是 AMD 包括之后的方案都无法解决 CSS 与 HTML 模块化的问题。

对于 CSS 本身它就是 global scope，因此开发样式可以说是喜忧参半。近几年也涌现把 HTML、CSS 和 JS 合并作模块化的方案，其中 react/css-modules 和 vue 都为人熟知。当然，这一点还是非常依赖于 webpack/rollup 等构建工具，让我们意识到在 browser 端还有很多本质的问题需要推进。

对于 css 模块化，目前不依赖预编译的方式是 styled-component，通过 js 动态创建 class。而目前 css 也引入了与 js 通信的机制 与 原生变量支持。未来 css 模块化也很可能是运行时的，所以目前比较看好 styled-component 的方向。

对于 html 模块化，小尤最近爆出与 chrome 小组调研 html Modules，如果 html 得到了浏览器，编辑器的模块化支持，未来可能会取代 jsx 成为最强大的模块化、模板语言。

对于 js 模块化，最近出现的 <script type="module"> 方式，虽然还没有得到浏览器原生支持，但也是我比较看好的未来趋势，这样就连 webpack 的拆包都不需要了，直接把源代码传到服务器，配合 http2.0 完美抛开预编译的枷锁。

上述三中方案都不依赖预编译，分别实现了 html、css、js 模块化，相信这就是未来。

模块化标准推进速度仍然缓慢

2015 年提出的标准，在 17 年依然没有得到实现，即便在 nodejs 端。

这几年 TC39 对语言终于重视起来了，慢慢有动作了，但针对模块标准制定的速度，与落实都非常缓慢，与 javascript 越来越流行的趋势逐渐脱节。nodejs 至今也没有实现 ES2015 模块化规范，所有 jser 都处在构建工具的阴影下。

Http 2.0 对 js 模块化的推动

js 模块化定义的再美好，浏览器端的支持粒度永远是瓶颈，http 2.0 正是考虑到了这个因素，大力支持了 ES 2015 模块化规范。

幸运的是，模块化构建将来可能不再需要。随着 HTTP/2 流行起来，请求和响应可以并行，一次连接允许多个请求，对于前端来说宣告不再需要在开发和上线时再做编译这个动作。

几年前，模块化几乎是每个流行库必造的轮子（YUI、Dojo、Angular），大牛们自己爽的同时其实造成了社区的分裂，很难积累。有了 ES2015 Modules 之后，JS 开发者终于可以像 Java 开始者十年前一样使用一致的方式愉快的互相引用模块。

不过 ES2015 Modules 也只是解决了开发的问题，由于浏览器的特殊性，还是要经过繁琐打包的过程，等 Import，Export 和 HTTP 2.0 被主流浏览器支持，那时候才是彻底的模块化。

Http 2.0 后就不需要构建工具了吗？

看到大家基本都提到了 HTTP/2，对这项技术解决前端模块化及资源打包等工程问题抱有非常大的期待。很多人也认为 HTTP/2 普及后，基本就没有 Webpack 什么事情了。

不过 Webpack 作者 @sokra 在他的文章 webpack & HTTP/2 里提到了一个新的 Webpack 插件 AggressiveSplittingPlugin。简单的说，这款插件就是为了充分利用 HTTP/2 的文件缓存能力，将你的业务代码自动拆分成若干个数十 KB 的小文件。后续若其中任意一个文件发生变化，可以保证其他的小 chunck 不需要重新下载。

可见，即使不断的有新技术出现，也依然需要配套的工具来将前端工程问题解决方案推向极致。

模块化是大型项目的银弹吗？

只要遵循了最新模块化规范，就可以使项目具有最好的可维护性吗？ Js 模块化的目的是支持前端日益上升的复杂度，但绝不是唯一的解决方案。

分析下 JavaScript 为什么没有模块化，为什么又需要模块化：这个 95 年被设计出来的时候，语言的开发者根本没有想到它会如此的大放异彩，也没有将它设计成一种模块化语言。按照文中的说法，99 年也就是 4 年后开始出现了模块化的需求。如果只有几行代码用模块化是扯，初始的 web 开发业务逻辑都写在 server 端，js 的作用小之又小。而现在 spa 都出现了，几乎所有的渲染逻辑都在前端，如果还是没有模块化的组织，开发过程会越来越难，维护也是更痛苦。

本文中已经详细说明了模块化的发展和优劣，这里不准备做过多的赘述。但还有一个问题需要我们去关注，那就是在模块化之后还有一个模块间耦合的问题，如果模块间耦合度大也会降低代码的可重用性或者说复用性。所以也出现了降低耦合的观察者模式或者发布/订阅模式。这对于提升代码重用，复用性和避免单点故障等都很重要。说到这里，还想顺便提一下最近流行起来的响应式编程（RxJS），响应式编程中有一个很核心的概念就是 observable，也就是 Rx 中的流（stream）。它可以被 subscribe，其实也就是观察者设计模式。

总结

未来前端复杂度不断增加已成定论，随着后端成熟，自然会将焦点转移到前端领域，而且服务化、用户体验越来越重要，前端体验早不是当初能看就行，任何网页的异常、视觉的差异，或文案的模糊，都会导致用户流失，支付中断。前端对公司营收的影响，渐渐与后端服务宕机同等严重，所以前端会越来越重，异常监控，性能检测，工具链，可视化等等都是这几年大家逐渐重视起来的。

我们早已不能将 javascript 早期玩具性质的模块化方案用于现代越来越重要的系统中，前端界必然出现同等重量级的模块化管理方案，感谢 TC39 制定的 ES2015 模块化规范，我们已经离不开它，哪怕所有人必须使用 babel。

话说回来，标准推进的太慢，我们还是把编译工具当作常态，抱着哪怕支持了 ES2015 所有特性，babel 依然还有用的心态，将预编译进行到底。一句话，模块化仍在路上。js 模块化的矛头已经对准了 css 与 html，这两位元老也该向前卫的 js 学习学习了。

未来 css、html 的模块化会自立门户，还是赋予 js 更强的能力，让两者的模块化依附于 js 的能力呢？目前 html 有自立门户的苗头（htmlModules），而 css 迟迟没有改变，社区出现的 styled-component 已经用 js 将 css 模块化得很好了，最新 css 规范也支持了与 js 的变量通信，难道希望依附于 js 吗？这里希望得到大家更广泛的讨论。

我也认同，毕竟压缩、混淆、md5、或者利用 nonce 属性对 script 标签加密，都离不开本地构建工具。

据说 http2 的优化中，有个最佳文件大小与数量的比例，那么还是脱离不了构建工具，前端未来会越来越复杂，同时也越来越美好。

至此，对于 javascript 模块化讨论已接近尾声，对其优缺点也基本达成了一致。前端复杂度不断提高，促使着模块化的改进，代理（浏览器、node） 的支持程度，与前端特殊性（流量、缓存）可能前端永远也离不开构建工具，新的标准会让这些工作做的更好，同时取代、增强部分特征，前端的未来是更加美好的，复杂度也更高。