譯文 別再用 JS 框架了

原文《No more JS frameworks》

中文版翻译：老码农

翻译版: 日语

JS 框架看上去就像死亡和纳税，必然发生，没法避免。若是我能变成一只苍蝇趴在墙上，我就能肯定每次启动一个新项目的时候，他们讨论的第一个问题确定是：咱们要用哪一个 JS 框架？这种场景反映了当今 JS 框架的角色在行业里是多么根深蒂固不可动摇。但其实这种形势并不是是必需的，并且实际上，这种作法须要制止。

让咱们先回顾一下咱们是怎么一路走来的。

Angular 和 Backbone 还有 Ember，我滴个天哪。

长期以来，用最简洁的 HTML+CSS+JS 方式表述的web 平台，从技术栈的角度看是一场灾难。谁能忘记 IE 的盒子模型或者 layer 标签？我知道，那些例子会引出 web 开发中一些令你不堪回首的往事。

很长时间里，浏览器之间存在大量的不一致，而咱们做为一个行业，只能靠编写框架来糊裱一番。问题在于当时在不一样浏览器之间对于一些基本问题都存在争议，例如事件如何传播或支持哪些标签，致使每一个框架不只糊裱了缺陷，并且还设计了他们对于浏览器功能的模型。实际上他们本身的模型都是多个，由于你要发明事件传播的模型，还有与 DOM 交互的模型，等等。这里边有不少新发明。随之出现了一些框架，而后积少成多集腋成裘，就产生了大量诸如 jQuery 、Dojo、MochiKit 、ExtJS 、AngularJS 、Backbone 、Ember 和React 等等玩意儿。在过去的十年里，咱们不停地折腾出了成堆的框架。

可是过去的十年里还发生了其余一些事：浏览器愈来愈好了。它们改善了对标准的支持，如今出现了自动更新的常青浏览器，它们的每一个版本都比旧版本更适应和符合标准。这些新标准好比：

HTML Imports
Object.observe
Promises
HTML Templates

我认为如今是时候从新思考 JS 框架的模型了。作 Web 开发不必再发明其余的方法，只要使用 HTML+CSS+JS 就好了。

那么，为啥咱们还在编写 JS 框架呢？我以为这很大程度上是由于惯性，它成了一个习惯了。不过，有人要说，这种习惯有那么糟糕么？框架看起来也并非有害的，对不？嗯，让咱们先从我说的框架定义开始分析。实际上这些代码是有个加强的梯度，从代码小片断开始，例如 Gist，逐渐扩大到愈来愈大的代码集，造成了库，最终产生了框架:

gist -> library -> framework

量变引发质变，框架已经再也不仅仅是大型的库，它们有本身的一套与事件、DOM 等交互的模型。那么，为啥要避免用框架呢？

抽象 框架的一个问题每每也是它们的卖点，那就是它们把平台抽象了，这样你就能集中精力写你本身的软件。问题是，如今你须要学习两套开发系统，HTML+CSS+JS 和框架。固然了，假如某个框架能作到把 web 平台彻底抽象化，那你就永远不须要涉足到框架以外，可是你猜怎么着？抽象也会泄露。因此你须要了解 HTML+CSS+JS，由于某些状况下你的程序不会按你所指望的方式工做，你须要深刻框架内部的各个层直到 HTML+CSS+JS，才能找到出错的缘由。

绘制冰山图

一套框架就像一座冰山，浮在水面上的 10% 看起来并不危险，最终让你船毁人亡的是隐藏在下面的那 90%。实际上更合适的一个比喻是，学习一套框架就像对一座冰山绘图，也就是说，为了使用框架你必须学会框架里全部的内容，花精力去把全部的内容对应到传统的 HTML+CSS+JS，从长期来看这个过程毫无心义，由于冰山最终都会融化。

小组件 框架的另外一个卖点是你能够得到一个小组件的库。可实际上，你并非非要运用一套框架才能获得它们，它们应该是和框架无关的独立功能。这方面的一个好例子是 CodeMirror，这是一个用 Javascript 编写的语法标记代码编辑器。你能够在任何地方使用它，无需任何框架。

给某个框架编写小组件也是吃力不讨好的事。还记得你在MochiKit 框架下编写的那些小组件吗？如今你转移到 Ember或者 Angular后，它们还好用不？

数据绑定 老实说，我历来用不着它。不过若是你须要的话，它也应该以库的形式出现，而不是框架。

框架带来的更长期的问题是它们最后变成一个一个地窖，把整个版图分割成片，给A框架编写的小组件没法在 B 框架下使用。这就是事倍功半。

那么问题就来了：后框架时代的世界是什么样的呢？

HTML+CSS+JS 就是个人框架。

基本思路就是再也不须要框架，使用 HTML+CSS+JS 中已经包含的能力去编写你的小组件就好了。把一块块巨石打散成独立的、能够任意组合的组件。按这个原则最终划分出的各块组件都成为 Web 组件中的一部分。

HTML 引入, HTML 模板, 定制元素, 以及 Shadow DOM 都是有助于咱们砍断框架束缚的有力技术，使咱们可以产生可重用的元素和功能。要想更详细地了解这些技术的状况，请参阅如下文章和库：

HTML Imports
Polymer
X-Tag
Bosonic
那么，是否是说咱们均可以建立 而后就万事大吉了呢？

不，并非这样。运用 Web 组件 须要作的第一件事是填补那些功能，例如 X-Tag 和 Polymer。不过随着浏览器逐渐填补对于这些规范的实现，这些工做的必要性会逐渐减小。

在这里须要强调的一点是这些补丁并非指那些自创一套 Web 开发模型的框架，它们只须要应用 HTML 5 模型就好了。可是那并非真正惟一的需求，在 Web 平台上仍然有微小的缺口，每一个浏览器都在一些细节上偏离当前的标准，这才是咱们须要填补的地方。MDN 看起来已经有不少所需的代码了，由于其中的文档常常包含了短小的针对每一个功能的补丁。

那么，一个巨大的 HTML 5 补丁库也许不错，可是更好的办法是我称之为 html-5-polyfill-o-matic 的一套工具，它让我能经过标准 HTML+JS 来编写 Web 组件，而后分析个人代码 — 经过静态分析或者运行时的 Object.observe ，使它能够精准地从完整 HTML 5 补丁中产生个人项目所需的一套子集。

若是我开始尝试混合和匹配来自多个来源的 Web 组件 — 例如来自 X-Tag 的 和来自Polymer 的 ，这种功能会变得更加剧要。是否是这就意味着我必须引入它们二者的补丁库呢？ (看起来答案是否认的。) 我又要如何获取这些定制元素呢？ X-Tag 和 Brick 二者都有定制绑定生成器：

Brick 下载
X-Tag 下载

若是我开始生成定制元素，我是否须要生成我本身的定制绑定器呢？我不认为那是个可扩展的思路，我相信咱们须要能更好处理这类问题的惯例和工具。这实际上可能意味着改变咱们进行开源项目的方式，一个小工具并非一个项目，全部咱们处理这类问题的方法须要改变。固然了，仍是要把代码放到 Git 里，可是你是否须要一个 GitHub 项目的总体开销呢？可能更好的办法是更轻量级、接近 Gist 的方式。我如何才能把vulcanize 里全部这些代码压缩成合适的形式用到个人项目里去？相似于 Asset Graph 的例子也许是个合适的起点。

那么，咱们如今须要的是什么？

编写可重用组件的惯例和指南。
在这些惯例下用来编译和压缩的工具。全部都是 HTML, CSS, 和 JS。
可扩展的 HTML 5 补丁，根据实际须要来肯定用完整的仍是精简版。
这就是咱们在将来构建Web应用时所须要的一切。在那时，咱们再也不须要学习最新框架的最新模型，而是直接针对 Web 平台工做，引入定制元素和库来知足特定需求，把时间花在编写应用上，而不是去绘制冰山图。

Q&A
Q: 你为啥憎恨框架做者呢？

A: 我不憎恨他们。我有些最好的朋友就是框架做者。我认可从搞笑文章《你糟蹋了 Javascript》中获得了一点灵感，不过我要再次说明，我无心嘲笑框架做者。

Q: 你能够用 HTML 5 实现 ____ 功能，但为了这么作你须要一套框架

A: 首先，那不是一个问题。其次，感谢指出这一点。如今让咱们一块儿努力加强 HTML 5 的能力，让____ 功能能够不用框架就能实现。

Q: 可是 ___ 并非框架，它是一个库!

A: 是的，正如我所说，它是从 gist 渐进到框架的，可能你的划分方式和我稍有区别。不要紧，这篇文章的重点不是对特定软件的分类，而是远离框架。

Q: 我这么干活已经不少年了，用了 ___ 和 ___ 还有 ___。

A: 这也不是一个问题。不过不管如何，这对你是有好处的，你应该处在了帮助其余人的有利位置。

Q: 这么说每一个人都须要重写下拉菜单、标签页、滑动条，并本身实现切换功能？

A: 绝对不是这样，关键是应该用一种不限定在某个框架的方式来建立这些元素。

Q: 伙计，全部这些 HTML 引入会把我网站的性能搞死的。

A: 是的，若是你在本地实现全部这些功能的话，这也是我前面 提到用来编译和压缩 HTML+CSS+JS 的工具的必要性 的缘由。

Q: 那么我就不要用 任何 库喽？

A: 不，那不是我表达的意思。我在区分库和框架这方面很是谨慎。库提供的是能够配合其余库使用的独立功能块。库很好啊，我但愿看到你们一致赞同远离的是 框架。

Q: 但是我喜欢数据绑定！

A: 不少人都喜欢，我只是表达我的喜爱罢了。我也没有说 你 不该该使用数据绑定，我只是说你不须要为了实现数据绑定而运用一整个框架而已，有一些独立的库就能够作到了。

2014-05-09 by Joe Gregorio

相关文章
给网页设计师和前端开发者看的前端性能优化
前端框架你究竟选什么
十大前端开发框架（上）
十大前端开发框架（下）
20个值得一试的JavaScript框架
LESS介绍及其与Sass的差别
关于前端框架的一些观点
14个支持响应式设计的前端框架
编写出色CSS代码的13个建议
Web前端开发规范文档你须要知道的事
【译文】别再用JS框架了，首发于博客 - 伯乐在线。