不要再使用JS框架了

浏览数：120 / 时间：2015年06月09日

　停止编写Javascript框架吧。

　　Javascript框架就好像死亡和税收一样：终究不可避免它的存在。我确信如果我是那面墙上的一只苍蝇，每次有人开始一个新的网页项目时，第一个问题肯定是我们用的是哪个JS框架？这就是当今业内对JS框架的根深蒂固的思维模式。但事实上并不需要如此，相反的，需要停止使用JS框架。

　　我们来看看我们都有些什么。

　　Angular、Backbone和Ember，哎哟妈呀

　　很长一段时间内网页平台、技术堆栈对于HTML+CSS+JS最简洁的描述就是灾难（缺少一个更好的解释）。谁能忘记IE的盒子模型或层标签？我相信我只用了这几个词就让你们其中一些人一下子回到了那个不堪回首的网页开发时代。

　　在很长一段时间里浏览器之间有一大堆的不一致，作为业内人士的我们不得不编写框架来掩盖这些问题。问题是连一些根本性问题，各浏览器之间都不一致，比如事件是怎样传播的或者支持什么标签，所以每个框架不仅仅是弥补这些漏洞，还要设计他们自己的浏览器运行模型。实际上他们的模型，许多模型，因为你必须为事件传播发明一个模型，为DOM发明一个模型等等。许多模型的发明创造还在继续。所以编写了一个个框架，每一个都如同一片雪花，上千上万的花朵绽放了，给我们带来了jQuery和Dojo和MochiKit和Ext JS和AngularJS和Backbone和Ember和React！在过去的十年里，我们已经炮制了一大堆JS框架。

　　但是在过去的十年中还有很多其他事情发生了；浏览器比之前更好了。浏览器对于标准的支持有了很大的改善，现在有些持续发展的浏览器：它们可以自动更新浏览器，每一个新版本都有更好的性能和对标准更好的适应。新标准如下：

　　我认为是时候重新思考下JS框架模型了。现在已经不再需要创造另一种方式了，使用HTML+CSS+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是我的框架

　　基本理念是框架是不需要的，用HTML+CSS+JS的内部功能创建你的小部件。将整块的材料分成正交分量，并可以任意组合。最终的碎片都可以在web组件的大伞下。

　　HTML导入、HTML模板、定制元素和Shadow DOM都是允许我们切断框架核心、创建可再次使用的元素和功能的技术。更详细、更好的介绍请参考以下文章和库：

　　那么，我们创建<x-flipbox>，宣布胜利，然后回家？

　　不，用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)，基于实际使用的全部或按比例缩小的。

　　这就是创建一个不需要学习最新的框架的最新模型的未来我们需要的，取而代之的，我们只直接与平台工作，拉入定制元素和库来满足特定需求，消耗时间创建应用，而不是标记冰山。