不要再使用JS框架了
原文：No more JS Frameworks byJoe Gregorio
停止编写Javascript框架吧。
我们来看看我们都有些什么。
非常长一段时间内网页平台、技术堆栈对于HTML+CSS+JS最简洁的描写叙述就是灾难（缺少一个更好的解释）。谁能忘记IE的盒子模型或层标签？我相信我仅仅用了这几个词就让你们当中一些人一下子回到了那个不堪回首的网页开发时代。
在非常长一段时间里浏览器之间有一大堆的不一致。作为业内人士的我们不得不编写框架来掩盖这些问题。问题是连一些根本性问题。各浏览器之间都不一致，比方事件是如何传播的或者支持什么标签。所以每个框架不不过弥补这些漏洞。还要设计他们自己的浏览器执行模型。实际上他们的模型，很多模型，由于你必须为事件传播发明一个模型。为DOM发明一个模型等等。很多模型的发明创造还在继续。所以编写了一个个框架，每个都如同一片雪花，上千上万的花朵绽放了，给我们带来了jQuery和Dojo和MochiKit和Ext JS和AngularJS和Backbone和Ember和React！
在过去的十年里。我们已经炮制了一大堆JS框架。
可是在过去的十年中还有非常多其它事情发生了；浏览器比之前更好了。
浏览器对于标准的支持有了非常大的改善。如今有些持续发展的浏览器：它们能够自己主动更新浏览器，每个新版本号都有更好的性能和对标准更好的适应。新标准例如以下：
那么为什么我们还要编写JS框架呢？我觉得原因大概是惯性，这是种习惯。可是它的确不好使。它不像框架是有主动危害性的。对吗？好吧。我们先来看看用网页框架定义我所说的。
实际上这是一个有梯度的代码，它以一小段代码開始，如同代码的主旨，然后是大段大段的代码汇总，再上升至库，最后是框架。
框架不仅仅是一个比較大的库，框架还有与事件和DOM等互动的模型。
那么为什么不用框架呢？
抽象性，框架的一个问题是他们的卖点，框架从平台中抽象出来，所以你能够关注在构建你的软件上。问题是如今你有两个系统须要学习。HTML+CSS+JS和框架。假设框架是一个完美的从网页中抽离出来的如同平台一样，你就不用越过框架，可是猜猜怎么着，框架不是那么完美。
所以你必须知道HTML+CSS+JS。由于某些情况下你的程序不会像你想象中那样执行，那么你就要一层一层的检查框架，去查出哪出错了。
直到检查到HTML+CSS+JS。
框架就像个冰山。10%漂浮在水上面，开起来并不危急，那隐藏的90%才会要了你的命。其实还有很多其它的apt。学习一个框架就像绘制一座冰山，为了使用框架你须要学习整座冰山，但终于执行的进程都是没有意义的，由于冰山会融化的。
小部件，还有一个框架的卖点就是你能够读取訪问小部件的库。但你的确不须要通过框架来訪问小部件。它们都应该是独立的。一个非常好的样例就是CodeMirror。一个用Javascript做的语法高亮显示代码编辑器。
你能够在不论什么地方使用它，不须要框架。
用框架做小部件也会失去你之前所做的努力。记得全部那些你写的MochiKit小部件吗？对的。如今将其转移到Ember或Angular。那些小部件还好使吗？
数据绑定，说实话我从来没须要过它。可是假设你须要。那么应该是库，而不是框架。
框架的一个更长期的问题是框架终结时会成为silos，他们为框架A切割的landscape和小部件不能在框架B下执行。你的努力都白费了。
那么后框架世界是什么样的？
基本理念是框架是不须要的，用HTML+CSS+JS的内部功能创建你的小部件。
将整块的材料分成正交分量，并能够随意组合。终于的碎片都能够在web组件的大伞下。
HTML导入、HTML模板、定制元素和Shadow DOM都是同意我们切断框架核心、创建可再次使用的元素和功能的技术。
更具体、更好的介绍请參考下面文章和库：
不，用Web组件你须要做的第一件事就是针对此功能的腻子膏，如X-Tag和Polymer。对于这部分的需求随着时间降低，由于浏览器将这些规格的实施详细化。
强调一点，这些腻子膏不是框架。採用他们自己的模型开发网页，腻子膏能够使用HTML5模型。
可是这并非唯一须要的，在同一平台下还是有些细小的差异，由于现行标准，浏览器会在一些细小的方面产生偏差，这就须要腻子膏。MDN貌似须要非常多代码。由于文件常常包括短小的每一个功能的腻子膏。
所以一个巨大的HTML 5的腻子膏库是非常好的，但更好的是我所谓的html-5-polyfill-o-matic，一组同意我通过bog标准HTML+JS写Web组件。通过静态分析或执行时的Object.observe分析完我的代码后，它为我的项目产生一个精确的完整的HTML 5 腻子膏子集。
当我開始试着混合和匹配多个资源的Web组件和库时。这类功能将会更为重要，比方一个X-Tag的<x-foo>和Polymer的<core-bar>。这意味着我要include这两个腻子膏库？（结果是不用）我究竟该如何做才干得到这些定制元素？X-Tag和Brick都有定制捆绑生成器：
这可能实际上意味着改变我们如何打开资源；一个“小部件”不是个项目，所以我们处理这些事情的方法要改变。
的确，还是要把代码放进Git，但你须要负担一个GitHub项目吗？假设有个东西比方今项目更小、更接近Gist是更合适的。
我如何为我的项目最小化/硬化全部这些代码成正确的格式？如同Asset
Graph的东西可能是个非常好的開始。
那么我们如今须要什么？
1、建立可反复使用的组件的习语和指导。
2、在这些习语下编译、崩溃、执行等的工具。全部HTML、CSS和JS。
3、一个可扩展的HTML 5腻子膏(polyfill)，基于实际使用的所有或按比例缩小的。
这就是创建一个不须要学习最新的框架的最新模型的未来我们须要的，取而代之的，我们仅仅直接与平台工作，拉入定制元素和库来满足特定需求，消耗时间创建应用。而不是标记冰山。
问答
问：为什么你讨厌框架的作者。
答：我不讨厌他们。我的一些最好的朋友也是框架作者。我承认有点灵感来自于你们已经毁了Javascript。开玩笑啦，可是。再一次重申。没有嘲笑框架作者的意思。
问：在HTML 5里你不能做XXX，为了这个。你须要个框架。
问：可是XXX不是个框架，是个库。
答：是的。正如我说的。它是个有梯度的代码，从主旨到框架，你可能会画下一条与我的稍有不同的界限。
这是能够的。这不是关于某一种特定软件的分类，是关于从框架中挪走。
问：我已经用了XXX和XXX非常多年了。
答：再说一次，这不是个问题。可是无所谓了。这是对你好啊，你应该以良好的状态来帮助别人。
问：所以每一个人都须要重写下拉菜单、表格、滑块和触发？
答：绝对不用，要点是有一种方法来创建这些元素，一种不用买一种特定框架的方法。
问：哥们，全部那些HTML导入都会减少我的网站的性能。
答：是的，假设你非常天真的使用这些东西，它会的，这就是我为什么提到须要一个HTML、CSS和JS的编译和崩溃的工具。
问：那么不建议我使用不论什么库？
答：不是的，这不是我说的，我非常细致的描绘了库和框架的分界线。一个库提供可供其它库使用的功能的正交。
库是能够用的，只是框架是我希望看见大家不再使用的。
问：可是我喜欢数据绑定！
答：很多人都喜欢，我仅仅是表达一下我自己个人的喜好。
我并没有说你不应该使用数据绑定，可是你不须要使用一整个框架来获得数据绑定，有单独的库来做这个。
