JavaScript框架的四个时代

本文为译文，原作者是 Chris ,它是Bitski的首席前端工程师，Ember.js核心团队成员，曾任LinkedIn、Addepar、Ticketfly（现为EventBrite）的前端工程师，反正是个厉害大佬就是了，本文的第一人称都指是的该大佬。

早在2012年，我开始主要用JavaScript进行编码。我曾为一家本地企业从头到尾做了一个PHP应用，一个基本的CMS和网站，公司决定要重写它并增加一些功能。

项目经理希望我使用.NET，部分原因是这是他所知道的，但也因为他希望这个应用感觉像一个本地应用程序–没有页面刷新或操作动作长时间等待。经过一番研究和原型设计，我说服了经理，可以使用当时刚开始出现的全新JS框架，它能做到这些事项。

我选择的第一个框架实际上是 Angular 1。在我遇到路由器的一些问题之前，已经建立了一个相当大的应用程序，并使用FuelPHP的后端–每当重新渲染子路由/出口时，它就会闪烁，而且真的感觉它在设计时没有考虑到这种场景。

后面，有人向我推荐了Ruby on Rails + Ember，在试过之后，觉得效果很好。我也喜欢这两个框架的理念，喜欢这些社区生态，而且与当时的替代方案相比，总的来说，它非常有成效。

从那时起，很多事情都发生了变化–框架层出不穷，并且有了很大的发展。去无可以在浏览器中用JavaScript构建应用程序的想法，从某种程度上的边缘变成了一种标准做法。我们构建的基础设施已经完全改变，实现了一系列新的可能性。

在这段时间里，各种想法之间也有相当多的竞争和冲突。使用哪种JavaScript框架，如何编写CSS，函数式编程与面向对象编程，如何最好地管理状态，哪种构建系统或工具最灵活、最快速，等等。回顾过去，这些觉得很有趣，我们经常争论的是错误的事情，而忽略了一些前瞻性，当然，这也是事后诸葛亮。

所以我想做一个回顾，回顾过去几十年的JavaScript开发，看看我们已经走了多远。我们可以把它大致分为四个主要时代。：

• 原始年代
• 第一个框架
• 以组件为中心的视图层
• 全栈式框架

每一个时代都有自己的主题和核心矛盾，同时也都想到吸取关键教训，并稳步前进。

今天，争论仍在继续。web 是否变得过于臃肿？一般的网站真的需要用React编写吗？我们甚至应该使用JavaScript吗？当然，当前也不能代表未来，未来现有框架很大可能也会被替换，但是，也是从现有的一些观点出来，帮助我们向前迈进。

原始年代

JavaScript是在1995年首次发布的。就像我上面提到的，我是在2012年开始写JS的，差不多20年后，接近我称之为第一框架的时代的开始。你可以认为，我在这里可能会掩盖很多历史，而且这个时代可能会被分解成许多子时代，每个时代都有自己的模式、库和构建工具等等。

也就是说，我不能写我没有经历过的事情。当我开始编写前端应用程序时，新一代的框架刚刚开始走向成熟。Angular.js、Ember.js、Backbone，等等。

在这之前，最先进的技术是jQuery和MooTools等库。这些库在它们的时代非常重要–它们帮助平滑了浏览器实现JavaScript的方式之间的差异，这些差异是非常重要的。

例如，IE 实现事件的方式与Netscape完全不同–冒泡事件与捕获事件。这就是为什么我们今天的标准最终实现了这两种方式，但在这之前，我们需要使用库来编写能在两种浏览器上使用的代码。

这些库主要用于制作小型的、独立的用户界面组件。大多数应用程序的业务逻辑仍然是通过表单和标准的HTTP请求进行的–在服务器上渲染HTML并将其提供给客户端。

在这个时代也没有什么构建工具可言，至少我知道的是。当时的JavaScript还没有模块（至少没有标准的模块），所以没有任何办法导入代码。所有的东西都是全局性的，要组织好这些东西是非常困难的。

在这种环境下，可以理解的是，JS通常被视为一种玩具语言，而不是你用它来写一个完整的应用程序。那时我们最常做的事情是加入 jQuery，为一些UI小部件编写一些脚本，然后就可以了。

随着时间的推移和XHR的引入和普及，人们开