现在，JavaScript框架已成为Web项目开发不可或缺的一部分。那是因为很长一段时间以来，各种浏览器之间有很大的差别，人们不得不编写框架对此进行屏蔽。问题在于，各种浏览器甚至在基本问题上都难以取得一致，以致框架还要针对浏览器该如何工作设计自己的模型，比如如何传播事件、如何与DOM交互等。于是出现了许多框架，常见的有jQuery、Dojo、MochiKit、Ext JS、AngularJS、Backbone 、Ember、React等。对于这种情况，谷歌工程师Joe Gregorio在博文中写道：
我认为是时候重新考虑JS框架模型了。没有必要发明另外一种做事方式，只要使用HTML+CSS+JS就行了。
Joe认为，在过去的十年中，浏览器变得更好了，它们对标准的支持也得到了改善，每个版本的功能都比上一个版本强大，而且还支持一些新标准，如HTML Imports、Object.observe、Promises、HTML Templates。而人们之所以还在编写JS框架，可能是出于惯性和习惯。
在进一步阐述观点之前，他对Web框架相关的三个概念进行了简单的区分。Gist是一段简单的代码，库是一个更大代码的集合，而框架不只是库的简单集合，它还有自己的事件、DOM交互模型。接下来，他说明了不需要JS框架的原因：
- 框架是对Web平台的抽象，但由于存在“抽象漏洞（abstraction leak）”，开发人员有时候必须诉诸于HTML+CSS+JS，而且有时候还需要深入研究框架才能找出问题所在。这样一来，开发人员除了要学习HTML+CSS+JS之外，还需要花费大量的时间学习和研究框架。
- 框架的另一个卖点是可以利用Widgets库，而实际上，框架并不是必须的，每个Widget都应该是独立的。语法高亮代码编辑器CodeMirror就是一个很好的例子。它用JavaScript构建，可以用在任何地方，而不需要框架。
- 框架提供的数据绑定特性并不是必须的，即使需要，也应该以库的形式出现，而不是框架。
- 框架最终会发展成为一个筒仓，为A框架创建的Widgets不能用于框架B，这会造成浪费。
Joe提出，后JS框架时代的基本思路是，开发人员应该使用HTML+CSS+JS的功能构建Widgets。这些Widgets相互独立，可以组合使用。Web组件为这一切提供了可能。HTML Imports、HTML Templates、Custom Elements和Shadow DOM等技术允许开发人员创建可重用的元素和功能。要了解更多信息，请查看下列文章和库：
而使用Web组件首先要有针对相关功能的Polyfills。他特别强调，Polyfills并不是框架，它们没有引入自己的Web开发模型，而是使HTML 5模型可用。同时，它们也弥补了浏览器实现与现有标准在某种程度上的偏离。MDN上经常有一些简短的、单功能的Polyfills。
构建一个大型的HTML 5 Polyfill库是有好处的，但更好地是能有一套工具可以根据项目需要生成一个完整HTML 5 Polyfill库的子集。这样，开发人员就可以混合和匹配不同来源的Web组件和库，如X-Tag的<x-foo>和Polymer的<core-bar>。关于如何获取这些自定义元素，感兴趣的读者可以查看Brick的GitHub页面和X-Tag下载页面。Joe指出，这并不是说创建自定义元素就需要创建自定义的打包器，那不是一个具有可扩展性的思路，而是说需要改变开源方式，一个Widget可以不是一个项目，一种更加轻量级的、类似Gist的共享方式可能更合适。在这方面，项目Asset Graph也许是个不错的开端。所以，他认为，现在需要三样东西：
- 构建可重用组件的习惯做法和指南；
- 可以遵循这些习惯做法编译HTML、CSS和JS的工具；
- 可扩展的HTML 5 Polyfill，可以根据需要进行裁剪。
按照Joe的观点，将来，开发人员不再需要学习最新的框架，只需要引入能够满足特定需求的自定义元素或库来构建他们的应用。