注* 作者 Bio ，现在Google工作。 作者不希望我们过多的依赖框架，最多使用一些库。 PS: 库用着不爽了可以换一个，框架能随便换吗？
JavaScript框架看起来像死亡和税收一样不可避免。我敢肯定每次有人开始一个新的web项目时，他们问的第一个问题的肯定是： 我们用的是什么JS框架?这真让我着急上墙。 这就是JS框架在当今业界根深蒂固的现像。实际上，框架并不是非有不可，它需要停下来。
让我们来先看看我们现在都有什么？
在相当长的一段时间内。网络平台的技术栈可以简洁地描述为HTML + CSS + JS，是由于缺乏一个更好的词吗？谁也不会忘记IE浏览器模型造成的一场灾难。我敢肯定，所有的Web开发者都会为这些黑暗的日子抽搐。
在很长一段时间出现了一大堆的浏览器，和我们之间产生大量的矛盾，作为产业的前提，必须编写框架，来绕过他们。问题是，在一些浏览器中，有一些根本问题也不一致，如事件是如何传播的，或者是标签的支持。所以每一个框架，不仅掩盖了这些不同，也实现了专属于自己的浏览器的工作模式。其实这种模式是必然的，因为你必须发明一种事件工作的通用模式，和如何与DOM交互的统一模型。因此，很多框架就这样产生了，百花齐放，给我们带来了jQuery，Dojo，MochiKit和Ext JS 和 AngularJS 和 Backbone 和 Ember 和 React.。在过去的十年里，我们一直在生产大量JS框架。
注* 旧版IE的事件模型与标准冒泡模型是不一样的
但过去的十年也有发生着一些别的事情;浏览器变得更好。他们对标准支持得更好，现在也有四季常青的浏览器：自动更新的浏览器，每个版本的功能更强大，支持更新的标准，如：
HTML Imports
Object.observe
Promises
HTML Templates
注* HTML Imorts 导入复用HTML代码段的新特性， 参见规范（起草阶段） ，示例：
我认为现在是重新思考的JS框架模型的时候了。有必要去创造另一种做事的方式吗？ 还是只需要使用纯HTML+CSS+JS。
那么，为什么我们仍然写新的JS框架？我认为很大一部分原因是因为惯性，这是习惯。但是，这不像框架有害的理由，对吧？好吧，让我们首先确定什么是web框架。首先是一些简单的代码例子，到列出一些要点，再移动到越来越大的代码集合，然后变成一个库，最后形成框架：
框架不只是库，他们有自己的模式，并且与DOM交互有统一的方式，所以为什么要避免框架？
嗯，这是框架通常的卖点之一，它们是抽象出来的平台，这样你就可以集中精力建设自己的软件。问题是，现在你需要学习两个系统： HTML + CSS + JS和框架。当然，如果该框架是Web平台的一个抽象，你只需要会这个框架就够了。但是有完美的抽象吗？abstractions leak抽象泄漏 。所以，你还是需要知道HTML+ CSS+ JS，因为在某些时候你的程序将无法正常工作，你希望了解它实现的方式，你必须向下挖掘，通过该框架的所有层，然后弄清楚哪错了，最终到达HTML + CSS + JS。
注* 抽象是面向对象分类所依据的原则，提取特殊/共性以便继承复用，但做好的抽象永远无法完全满足以后变化的需求，目前面向接口/方面，模块化，组件化的发展都在尝试解决这个问题。 相关： 痛苦的Java程序员， 面向对象的缺陷
框架就像是一座冰山，有10％浮在水面上看起来并不危险，但下面却隐藏着90％。事实上，这个比喻很贴切，学习框架就像是映射一座冰山，你需要了解整个过程才能使用，映射所有事情的努力可能是没有意义的，因为冰山可能有一天就会融化化。
框架的另一个卖点，你可以访问小工具库。不过说真的，你不应该采用一个框架，来访问这些小部件，他们都应该是正交的，独立的。今天的一个很好的例子是CodeMirror，基于JavaScript的语法高亮代码编辑器。你可以用在任何地方，任何框架里。
还记得你写的那些基于MochiKit的小部件吗？是啊，当时他们看上去多么美好呀。现在呢？迁移到Ember 或 AngularJS怎么样？
老实说，我从来没有需要过它，但如果你想使用他们，你应使用一个库，而不是一个框架。
从长期来，框架的问题的问题是，他们最终会成为孤岛，专为框架A设计的部件无法在框架B上工作。这样会浪费精力。
那么一个后架构的世界会是什么样子？
我的基本的观点是我们不需要框架，使用已经内置在HTML + CSS + JS中的能力，建立自己的小部件（Widgets）。没有任何依赖，掰开任何一个都可以独立工作。最后的步骤是，将他们在 Web Componetns中启用。
注* HTML/CSS/JS不正是纯天然的MVC结构吗？ HTML -> Template, CSS -> View, JS -> Controler, JSON -> Model
HTML Imports, HTML Templates, Custom Elements 和 Shadow DOM 都是有利的技术，应该让我们减小对框架的依赖，允许创建可重复使用的元素和功能。下面这些技术可以更好地实现这一点：
HTML Imports
Polymer
X-Tag
Bosonic
所以，我们都创建<X-flipbox>类似的东西，宣告胜利，然后回家？
注* brick-flipbox是一个创建自定义Web Componetns的示例项目， 示例， 使用这个Web组件的方法：
不，其实，你需要确保Web组件工作的第一件事是用polyfills来实现该功能，如X-Tag和Polymer。避免那些旧版浏览器不支持的情况。
注* polyfill指是开发者希望浏览器能原生支持的一些新特性而写的代码(或者插件)。
有一点这里要强调的是，这些polyfills都不是介绍自己的模型来开发Web上的框架，它们在使用HTML5模型。但是，这并不是真正的唯一的需要，各个浏览器对标准的执行还有一些差异，这是我们需要polyfill的地方。 MDN ，是一个很有趣的社区，没有太多的不必要的代码，提供大量的文档，和少量代码实现的polyfills。
问：你为什么恨框架作者。
答：我不恨他们。我的一些最好的朋友也是写框架的。你可以看看这篇文章： 你已经毁了JavaScript ， 再次强调，真的没有嘲笑那些写框架的。
问：在HTML5中你无法____，因此你需要一个框架。
答：首先，这不是一个问题。其次，感谢您指出了这一点。现在，让我们携手合作，将功能添加到HTML5中，允许实现____。
问：但是___不是一个框架，这是一个库！
答：是的，就像我说的，这是从 gist -> framework 的渐变，可能跟我画的线条略有不同。没关系，这不是任何一个特定软件的分类，只是关于不依赖框架的故事。
问：我已经使用___和___和___ 很多年了
答：同样，这不是一个问题，但无论如何，对你都有好处，可以帮助其他人。
问：所以每个人都需要重写下拉菜单，标签，滑块和然后换成自己的？
答：绝对不是，问题是不需要依赖一个特定的框架的来创建这些元素。
问：哥们，所有的HTML imports会毁了我网站的性能。
答：是的，如果你天真地实施了所以这些东西，那就会的。这就是为什么我建议你需要工具来编译所有的HTML，CSS和JS。
问：所以我不应该使用任何库？
答：不，这不是我说的，我很谨慎地界定库和框架之间的区别，库（Library）提供一个个正交的功能，可与其他库结合使用。库是好的，我100％支持，我只希望你离开框架。
问：但我喜欢数据绑定！
答： 很多人都喜欢，我只是表达个人喜好。我不是说，你不应该使用数据绑定，而只是说你不需要采用整个框架来获取数据绑定，也有独立的绑定库呀。
停止写JavaScript框架
JavaScript框架看起来像死亡和税收一样不可避免。我敢肯定每次有人开始一个新的web项目时，他们问的第一个问题的肯定是： 我们用的是什么JS框架?这真让我着急上墙。 这就是JS框架在当今业界根深蒂固的现像。实际上，框架并不是非有不可，它需要停下来。
让我们来先看看我们现在都有什么？
Angular 和 Backbone 和 Ember, 唉天哪
在相当长的一段时间内。网络平台的技术栈可以简洁地描述为HTML + CSS + JS，是由于缺乏一个更好的词吗？谁也不会忘记IE浏览器模型造成的一场灾难。我敢肯定，所有的Web开发者都会为这些黑暗的日子抽搐。
在很长一段时间出现了一大堆的浏览器，和我们之间产生大量的矛盾，作为产业的前提，必须编写框架，来绕过他们。问题是，在一些浏览器中，有一些根本问题也不一致，如事件是如何传播的，或者是标签的支持。所以每一个框架，不仅掩盖了这些不同，也实现了专属于自己的浏览器的工作模式。其实这种模式是必然的，因为你必须发明一种事件工作的通用模式，和如何与DOM交互的统一模型。因此，很多框架就这样产生了，百花齐放，给我们带来了jQuery，Dojo，MochiKit和Ext JS 和 AngularJS 和 Backbone 和 Ember 和 React.。在过去的十年里，我们一直在生产大量JS框架。
注* 旧版IE的事件模型与标准冒泡模型是不一样的
但过去的十年也有发生着一些别的事情;浏览器变得更好。他们对标准支持得更好，现在也有四季常青的浏览器：自动更新的浏览器，每个版本的功能更强大，支持更新的标准，如：
HTML Imports
Object.observe
Promises
HTML Templates
注* HTML Imorts 导入复用HTML代码段的新特性， 参见规范（起草阶段） ，示例：
<link rel="import" href="/imports/heart.html">我认为现在是重新思考的JS框架模型的时候了。有必要去创造另一种做事的方式吗？ 还是只需要使用纯HTML+CSS+JS。
那么，为什么我们仍然写新的JS框架？我认为很大一部分原因是因为惯性，这是习惯。但是，这不像框架有害的理由，对吧？好吧，让我们首先确定什么是web框架。首先是一些简单的代码例子，到列出一些要点，再移动到越来越大的代码集合，然后变成一个库，最后形成框架：
gist（要点） -> library（库） -> framework（框架）
框架不只是库，他们有自己的模式，并且与DOM交互有统一的方式，所以为什么要避免框架？
Abstractions 抽象
嗯，这是框架通常的卖点之一，它们是抽象出来的平台，这样你就可以集中精力建设自己的软件。问题是，现在你需要学习两个系统： HTML + CSS + JS和框架。当然，如果该框架是Web平台的一个抽象，你只需要会这个框架就够了。但是有完美的抽象吗？abstractions leak抽象泄漏 。所以，你还是需要知道HTML+ CSS+ JS，因为在某些时候你的程序将无法正常工作，你希望了解它实现的方式，你必须向下挖掘，通过该框架的所有层，然后弄清楚哪错了，最终到达HTML + CSS + JS。
注* 抽象是面向对象分类所依据的原则，提取特殊/共性以便继承复用，但做好的抽象永远无法完全满足以后变化的需求，目前面向接口/方面，模块化，组件化的发展都在尝试解决这个问题。 相关： 痛苦的Java程序员， 面向对象的缺陷
Mapping the iceberg （映射的冰山）
框架就像是一座冰山，有10％浮在水面上看起来并不危险，但下面却隐藏着90％。事实上，这个比喻很贴切，学习框架就像是映射一座冰山，你需要了解整个过程才能使用，映射所有事情的努力可能是没有意义的，因为冰山可能有一天就会融化化。
Widgets（部件）
框架的另一个卖点，你可以访问小工具库。不过说真的，你不应该采用一个框架，来访问这些小部件，他们都应该是正交的，独立的。今天的一个很好的例子是CodeMirror，基于JavaScript的语法高亮代码编辑器。你可以用在任何地方，任何框架里。
还记得你写的那些基于MochiKit的小部件吗？是啊，当时他们看上去多么美好呀。现在呢？迁移到Ember 或 AngularJS怎么样？
Data Binding(数据绑定)
老实说，我从来没有需要过它，但如果你想使用他们，你应使用一个库，而不是一个框架。
从长期来，框架的问题的问题是，他们最终会成为孤岛，专为框架A设计的部件无法在框架B上工作。这样会浪费精力。
那么一个后架构的世界会是什么样子？
HTML + CSS + JS我的框架
我的基本的观点是我们不需要框架，使用已经内置在HTML + CSS + JS中的能力，建立自己的小部件（Widgets）。没有任何依赖，掰开任何一个都可以独立工作。最后的步骤是，将他们在 Web Componetns中启用。
注* HTML/CSS/JS不正是纯天然的MVC结构吗？ HTML -> Template, CSS -> View, JS -> Controler, JSON -> Model
HTML Imports, HTML Templates, Custom Elements 和 Shadow DOM 都是有利的技术，应该让我们减小对框架的依赖，允许创建可重复使用的元素和功能。下面这些技术可以更好地实现这一点：
HTML Imports
Polymer
X-Tag
Bosonic
所以，我们都创建<X-flipbox>类似的东西，宣告胜利，然后回家？
注* brick-flipbox是一个创建自定义Web Componetns的示例项目， 示例， 使用这个Web组件的方法：
<brick-flipbox>
<div>Front</div>
<div>Back</div>
</brick-flipbox>
不，其实，你需要确保Web组件工作的第一件事是用polyfills来实现该功能，如X-Tag和Polymer。避免那些旧版浏览器不支持的情况。
注* polyfill指是开发者希望浏览器能原生支持的一些新特性而写的代码(或者插件)。
有一点这里要强调的是，这些polyfills都不是介绍自己的模型来开发Web上的框架，它们在使用HTML5模型。但是，这并不是真正的唯一的需要，各个浏览器对标准的执行还有一些差异，这是我们需要polyfill的地方。 MDN ，是一个很有趣的社区，没有太多的不必要的代码，提供大量的文档，和少量代码实现的polyfills。
Q/A 问答
问：你为什么恨框架作者。
答：我不恨他们。我的一些最好的朋友也是写框架的。你可以看看这篇文章： 你已经毁了JavaScript ， 再次强调，真的没有嘲笑那些写框架的。
问：在HTML5中你无法____，因此你需要一个框架。
答：首先，这不是一个问题。其次，感谢您指出了这一点。现在，让我们携手合作，将功能添加到HTML5中，允许实现____。
问：但是___不是一个框架，这是一个库！
答：是的，就像我说的，这是从 gist -> framework 的渐变，可能跟我画的线条略有不同。没关系，这不是任何一个特定软件的分类，只是关于不依赖框架的故事。
问：我已经使用___和___和___ 很多年了
答：同样，这不是一个问题，但无论如何，对你都有好处，可以帮助其他人。
问：所以每个人都需要重写下拉菜单，标签，滑块和然后换成自己的？
答：绝对不是，问题是不需要依赖一个特定的框架的来创建这些元素。
问：哥们，所有的HTML imports会毁了我网站的性能。
答：是的，如果你天真地实施了所以这些东西，那就会的。这就是为什么我建议你需要工具来编译所有的HTML，CSS和JS。
问：所以我不应该使用任何库？
答：不，这不是我说的，我很谨慎地界定库和框架之间的区别，库（Library）提供一个个正交的功能，可与其他库结合使用。库是好的，我100％支持，我只希望你离开框架。
问：但我喜欢数据绑定！
答： 很多人都喜欢，我只是表达个人喜好。我不是说，你不应该使用数据绑定，而只是说你不需要采用整个框架来获取数据绑定，也有独立的绑定库呀。
因为不喜欢一大堆依赖的express，虽然express也很方便，但看着头疼，所以我用了websvr这个只有一个文件的超轻量级框架，它的依赖根本只是几个必须的，哈哈哈哈
@zkwap #0
:)
也许代码维护才是我们最重要关心的
代码最重要的是阅读性吗？
该译文不符合我国国情。
AngularJS和React太高大上了，一看就没有欲望。
只用jQuery的飘过。
@丘旧牙 #3
差不多是这样，好读的代码也好维护
添加链接
这是年纪测试贴么？对于jq诞生前就写前端的同学来讲，还是很苦恼的，不是业务逻辑复杂，而是兼容性问题！你懂的，靠谱的框架经过严格测试自然可以节省很多开发时间。即使是今天，我们依然可以选择用 mootools ，可以用spin，可以自己做mvc，只是别太钻牛角尖就好
感觉作者确实不喜欢框架的限制，但是框架开发，确实可以节省不少工作量。还是有点作用的。比如，angular的页面自组装，React的生命周期之类的，如果自己写，还是需要一定工作量的，javascript本身太裸，如果没有框架，就相当于每次都从头来，这样开发进度，和效率都会受到一定影响的。
-
--
*`
标题 ##
js的各种框架还是需要的，最终好用的还是会留下来，不好用的或者太难学习的逐渐就会被淘汰了。ExtJS如果是一款不收费的框架，用的人会非常多的。
框架、框架、我学原生JS干嘛！？
写得好。框架束缚了不少人们的思想，现在很多程序员，只了解一些框架的规则，对于基础实现根本不会。框架最多只能兼容相当的场景，肯定不能全覆盖。遇到例外或蹩脚的时候，只会框架的人就要麻爪。