关于javascript:JavaScript框架的四个时代

有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。

本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。

本文为译文，原作者是 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 的引入和遍及，人们开始把他们的 UI 流程的一部分放到一个页面中，特地是对于须要在客户端和服务器之间进行屡次来回交互的简单流程，但应用程序的大部分内容还是留在服务器上。

这与挪动利用开始呈现时的状况造成了显明的比照。从一开始，iOS 和 Android 上的挪动利用就是用 Objective C 和 Java 等庄重语言™编写的残缺利用。此外，它们是齐全由 API 驱动的 – 所有的 UI 逻辑都在设施上，与服务器的通信纯正是数据格式的。这导致了更好的用户体验和挪动利用的爆炸性增长，间接导致了咱们明天对于挪动和 web 哪个更好的争执。

用 JavaScript 做这所有，起初被认为是可笑的。但随着工夫的推移，应用程序开始变得更加雄心勃勃。社交网络减少了聊天、DM 和其余实时性能，Gmail 和 Google Docs 表明能够在浏览器中编写相当于桌面利用，越来越多的公司转向编写 web 利用，因为 web 在任何中央都能够工作，而且更容易长期保护。这推动了整个行业的倒退 – 当初很显著，JS 能够用来编写非简略的应用程序。

过后的 JavaScript 还没有明天的所有性能，所有的货色都是全局的，通常须要手动下载并将每个内部库增加到动态文件夹中。过后还没有 NPM，模块也不存在，JS 也没有明天一半的性能。

在大多数状况下，每个应用程序都是定制的，每个页面都有不同的插件设置，每个插件都有不同的零碎来治理状态和渲染更新。为了解决这些问题，最早的 JavaScript 框架开始呈现了。

第一个框架

大概在 2000 年代末和 2010 年代初，第一批专门用于编写残缺客户端应用程序的 JS 框架开始呈现。这个时代的几个有名的框架：

1. Backbone.js
2. Angular 1
3. Knockout.js
4. SproutCore
5. Ember.js
6. Meteor.js

当然，还有很多其余的，可能还有一些在某些圈子里更大的。这些是我记得的，次要是因为小明用它们来编码，而且它们比拟受欢迎。

这是一代框架，正在进入未知的畛域。一方面，他们试图做的事件是十分雄心勃勃的，而且很多人认为它永远不会真正胜利。

有许多反对者认为单页 JS 应用程序（SPA）从根本上来说更蹩脚，而且在很多方面他们是对的 – 客户端渲染意味着机器人不能轻易抓取这些页面，而且用户甚至须要期待几秒钟能力开始绘制应用程序。很多这些应用程序都是无障碍的噩梦，如果敞开了 JavaScript，它们就根本无法工作。

另一方面，咱们没有在 JS 中构建残缺应用程序的教训，因而有大量对于最佳办法的竞争性想法。大多数框架都试图模拟其余平台上的风行做法，所以简直所有的框架最初都是 Model-View-* 的某种迭代。Model-View-Controller，Model-View-Producer，Model-View-ViewModel等等。但从久远来看，这些都不是真正意义上的胜利 – 它们并不特地直观，而且很快就变得非常复杂。

这也是一个咱们真正开始尝试如何编译 JavaScript 应用程序的时代。Node.js 在 2009 年公布，NPM 在 2010 年紧随其后，为（服务器端的）JavaScript 引入了包。

CommonJS 和 AMD 抢夺如何最好地定义 JS 模块，而像 Grunt、Gulp 和 Broccoli 这样的构建工具则抢夺如何将这些模块组合成一个可交付的最终产品。

在大多数状况下，这些都是十分通用的工作运行器式的工具，它们真的能够构建任何货色，只是碰巧要构建 JavaScript– 还有 HTML、CSS/SASS/LESS，以及其余许多进入 web 利用的货色。

然而，咱们从这个时代学到了很多货色:

• 基于 URL 的路由是根底。没有这种路由的应用程序会毁坏 web，因而须要在框架中从一开始就思考到这一点。
• 通过模板化语言扩大 HTML 是一个弱小的形象层。即便它有时会有点蠢笨，但它使用户界面与状态放弃同步变得更加容易。
• SPA 的性能很差，而且 web 有许多原生利用所没有的额定限度。咱们须要通过 web 公布所有的代码，让它 JIT，而后运行来启动咱们的应用程序，而本地应用程序曾经下载和编译，这是一项艰巨的工作。
• 作为一种语言，JavaScript 有很多问题，它的确须要被改良，以使事件变得更好 – 框架无奈独自做到这一点。
• 咱们相对须要更好的构建工具、模块和包装，以便大规模地编写应用程序。

总的来说，这个时代是富有成效的。只管有毛病，但随着应用程序的复杂性减少，将客户端与 API 拆散的益处是微小的，而且在许多状况下，所产生的用户体验是惊人的。如无非凡状况，这个时代可能会继续下去，咱们到当初还在迭代 MV* 格调的想法。

但起初一颗小行星忽然呈现，把现有的范式砸得支离破碎，造成了一次小规模的灭绝事件，把咱们推动了下一个时代 – 这颗小行星名叫React。

以组件为核心的视图层

我不认为 React 创造了组件，但说实话，我也不太分明它们最早来自哪里。但至多能够追溯到.NET 中的 XAML，而 web 组件也在那时开始作为一种标准倒退。最终它并不重要——一旦这个想法呈现了，每个次要的框架都很快地采纳了它。

预先看来，这齐全是有情理的 – 扩大 HTML，缩小长期存在的状态，将 JS 业务逻辑间接与模板绑定（无论是 JSX 还是 Handlebars 还是 Directives）。

基于组件的应用程序打消了实现工作所需的大部分抽象概念，并且显著地简化了代码的生命周期 – 所有都与组件的生命周期而不是应用程序的生命周期分割在一起，这意味着作为一个开发人员，你要思考的事件要少得多。

然而，过后还有一个转变：框架开始把本人吹牛成 “ 视图层 ”，而不是成熟的框架。他们不再解决前端利用所需的所有问题，而是专一于解决渲染问题。

其余问题，如路由、API 通信和状态治理，则由用户本人决定。这个时代驰名的框架有：

1. React.js
2. Vue.js
3. Svelte
4. Polymer.js

还有很多其余的。当初回过头来看，我认为这是第二代框架的一个风行框架，因为它的确做了两件次要的事件。

1. 它极大地放大了范畴。该框架的外围不是试图在后期解决所有这些问题，而是专一于渲染，许多不同的想法和方向能够在更宽泛的生态系统中摸索其余性能。有很多蹩脚的解决方案，但也有很好的解决方案，为下一代从精髓中筛选最好的想法铺平了路线。
2. 这让咱们更容易接受它们。采纳一个残缺的框架来接管你的整个网页意味着重写你的大部分应用程序，这对于现有的服务器端巨石来说是不可能的。应用像 React 和 Vue 这样的框架，你能够一次一个小部件或组件地将它们的一小部分放入现有的应用程序中，容许开发人员增量地迁徙他们现有的代码。

这两个因素导致第二代框架迅速倒退，使第一代框架黯然失色，从远处看，这所有仿佛很有意义，是一种正当的演变。但在过后身处其中，是相当令人丧气的经验。

首先，当咱们在工作中争执应用哪种框架，或者是否应该重写咱们的应用程序时，并不常常遇到这样的框架。相同，很多时候是 “ 它更快！” 或 “ 它更小！” 或 “ 它是你所须要的所有！”。

还有对于函数式编程和面向对象编程的答辩，很多人把 FP 作为咱们所有问题的解决方案。偏心地说，这些事件都是真的。仅有视图层的框架更小（起初）、更快（起初），而且是你所须要的全副（如果你本人建设或缝合了很多货色）。

当然，函数式编程模式解决了大量困扰 JavaScript 的问题，我认为均匀而言，JS 因为它们而变得更好。

然而，事实是基本就没有什么灵丹妙药。应用程序依然宏大、臃肿和简单，状态依然难以治理，路由和 SSR 等根本问题依然须要解决。

对于咱们中的很多人来说，人们想要的仿佛是放弃试图解决所有这些问题的解决方案，而换成一个让读者本人去解决的解决方案。

依据我的教训，这也是工程小组的广泛做法，他们会很快乐地承受这种扭转，以便交付一个新的产品或性能，而后又不赞助齐全开发所有这些额定性能所需的工夫。

其后果是围绕这些视图层建设的自制框架，而这些框架自身是臃肿的、简单的，而且十分难以操作。

我认为人们在应用 SPA 时遇到的许多问题都来自于这种扩散的生态系统，而这种生态系统恰好是在 SPA 应用爆炸性增长的时候呈现的。我依然常常遇到一个新的网站，它不能正确地做路由或很好地解决其余小细节，这相对是令人丧气的。

但另一方面，现有的第一代全服务框架在解决这些问题方面也做得不是很好。局部起因是因为大量的技术债权包袱。第一代框架是在 ES6 之前，在模块之前，在 Babel 和 Webpack 之前，在咱们弄清楚许多事件之前建设的。

迭代进化是十分艰难的，而且齐全重写它们，就像 Angular 对 Angular 2 所做的那样，扼杀了他们社区的发展势头。

因而，当波及到 JavaScript 框架时，开发人员处于两难地步 – 要么抉择一个开始显示其年龄的一体化解决方案，要么跳入自由竞争中，DIY 一半的框架，心愿失去最好的后果。

过后这让人十分丧气，但最初还是产生了大量的翻新。随着这些框架找出它们的最佳实际，JavaScript 生态系统的倒退十分迅速，还产生了一些其余的要害变动。

• 像 Babel 这样的转译器成为常态，并有助于使语言现代化。与其期待多年的性能标准化，不如明天就能应用，而语言自身也开始以更快、更迭代的速度减少性能。
• ES 模块被标准化，使咱们最终开始围绕它们构建古代构建工具，如 Rollup、Webpack 和 Parcel。基于导入的 bundling 缓缓成为标准，即便是款式和图片等非 JS 资源也是如此，这极大地简化了构建工具的配置，使它们变得更精简、更疾速、更全面。
• 随着越来越多的 API 被标准化，Node 和 web 规范之间的差距也在迟缓但稳步地放大。SSR 开始成为一种真正的可能性，而后是每个庄重的应用程序都在做的事件，但每次都是一种定制的设置。
• 开释了 Edge Computing，为基于 JavaScript 的服务器应用程序提供了 SPA 在散布 / 响应工夫方面的益处（Spas 以前因为在 CDN 上是动态文件，因而通常能够更快地开始加载加载，即便它们花了更长的工夫能力齐全加载并在完结）。

在这个时代完结的时候，一些问题依然存在。状态治理和响应性依然是（当初也是）辣手的问题，只管咱们有比以前更好的模式。

性能依然是一个艰难的问题，只管状况正在改善，但依然有很多很多臃肿的 SPA 在那里。

可拜访性的状况也有所改善，但对于许多工程机构来说，它依然常常是一个预先的想法。但这些变动为下一代框架铺平了路线，我想说的是，咱们当初正在进入下一代框架。

全栈式框架

就我集体而言，上一个框架时代真的轻轻降临了。我想这是因为我在过来 4 年左右的工夫里深刻到 Ember 渲染层的外部，试图解决后面提到的影响它作为第一代框架的技术债权（依然）。但这也是因为它更加奥妙，因为所有这些第三代框架都是围绕上一代的视图层框架建设的。这些框架包含：

1. Next.js (React)
2. Nuxt.js (Vue)
3. Remix (React)
4. SvelteKit (Svelte)
5. Gatsby (React)
6. Astro (Any)

这些框架是随着视图层的成熟和坚固而开始的。既然咱们都批准组件是建设在外围根底之上的，那么开始标准化应用程序的其余局部 – 路由器、构建零碎、文件夹构造等，就很有意义了。

缓缓地，这些元框架开始建设起与第一代多合一解决方案开箱即用的雷同性能，从各自的生态系统中筛选最佳模式，并随着它们的成熟而将其纳入。

而后他们又进一步。

在这之前，SPA 始终只专一于客户端。SSR 是每个框架都心愿解决的问题，但只是作为一种优化，一种取得渲染的形式，最终会在数兆字节的 JS 最终加载结束后被取代。

只有一个第一代框架敢于想得更远，即Meteor.js，但它同构 JS 的想法从未真正实现。

但随着应用程序的规模和复杂性的减少，这个想法被从新扫视。

咱们留神到，将后端和前端搭配在一起实际上是十分有用的，这样你就能够做一些事件，比方为某些申请暗藏 API 机密，在返回页面时批改头文件，代理 API 申请。随着 Node 和 Deno 实现了越来越多的 web 规范，服务器端 JS 和客户端 JS 之间的差距每年都在放大，它开始看起来毕竟不是一个疯狂的想法。将其与 edge-computing 和惊人的工具联合起来，就会有一些令人难以置信的后劲。

最新一代的框架充分利用了这种后劲，将客户端和服务器无缝地交融在一起，我无奈强调这种感觉有如许令人诧异。在过来 9 个月与 SvelteKit 的单干中，我不晓得有多少次坐下来对本人说：” 这就是咱们应该始终做的事件。”

以下是我最近遇到的一些工作，通过这种设置，这些工作变得异样简略。

• 将服务器端的 OAuth 增加到咱们的应用程序中，这样认证令牌就不会来到服务器，同时还有一个 API 代理，在向咱们的 API 发送申请时增加令牌。
• 将某些路由间接代理到咱们的 CDN，这样咱们就能够托管在任何其余框架中构建的动态 HTML 页面，容许用户制作本人的定制页面（咱们为一些客户提供的服务）。
• 当咱们须要应用一个须要密匙的内部服务时，增加几个不同的一次性 API 路由（不须要为咱们的 API 增加一个全新的路由并与后端人员协调）。
• 将咱们对 LaunchDarkly 的应用转移到服务器端，这样咱们就能够加载更少的 JS，从而升高整体老本。
• 通过后端路由代理咱们的 Sentry 申请，这样咱们就能够捕捉到因为广告屏蔽器而未被报告的谬误。

而这仅仅是冰山一角。这种模式真的有很多很酷的中央，其中最大的一点是它如何重振渐进式加强的理念，利用服务器和客户端的组合个性，容许客户端在用户禁用 JavaScript 的状况下回退到根本的 HTML + HTTP。

当我开始从事 SPA 工作时，我本人曾经齐全放弃了这种做法，认为它们是将来的趋势，但咱们有可能看到它卷土重来的世界，这真的很酷。

这些是新的性能，从教训上看，我把这些框架归为新一代的框架。以前难以解决或不可能解决的问题当初变得微不足道，只需扭转一点点的响应解决逻辑。

牢靠的性能和用户体验是开箱即用的，不须要任何额定的配置。咱们不须要建设整个新的服务，而是可能依据须要增加一些额定的端点或中间件。这曾经扭转了生存。

我认为这一代也解决了第一代和第二代框架及其用户之间的一些主要矛盾点。

它始于向零配置术语的转变，但我认为它最终是由围绕第二代框架的生态系统的成熟和稳固所驱动的，这也是一种文化转变。

第三代框架当初正试图再次成为一体化的解决方案，试图解决咱们作为前端开发者须要解决的所有根本问题 – 不仅仅是渲染。

当初比以往任何时候都感觉到社区在解决所有困扰 SPA 的许多问题方面是统一的，而且重要的是，独特解决了这些问题。

咱们接下来要去哪里？

总的来说，我认为 JavaScript 社区正朝着正确的方向倒退。咱们终于开发出了成熟的解决方案，能够从头开始构建残缺的应用程序，这些解决方案并不是 “ 仅仅是一个视图层 ”。

咱们终于开始与原生利用的 SDK 在同一起跑线上竞争，提供一个开箱即用的残缺工具包。

咱们在这方面仍有很多工作要做。在 SPA 畛域，可拜访性长期以来始终是一个预先的想法，而在 GraphQL 之外，我依然认为 data story 能够应用一些工作（不论你喜爱与否，大部分的 web 依然运行在 REST 上）。

但趋势是正确的，如果咱们持续朝着共享解决方案的方向倒退，我认为咱们能够用比以前更好的形式解决这些问题。

我还对将这些模式进一步晋升到 web 平台自身背地的后劲感到兴奋。Web 组件仍在悄悄地迭代，致力于解决 SSR 和解脱全局注册等问题，这将使它们与这些第三代框架更加兼容。

在另一个方向，WebAssembly 能够以一种令人难以置信的形式迭代这种模式。设想一下，可能用任何语言编写一个全栈框架。

同构的 Rust、Python、Swift、Java 等语言最终能够将前台和后盾之间的阻碍缩小到简直为零 – 只是在你的零碎边缘有一点 HTML 模板（这讥刺地使咱们简直绕了一圈，只管有更好的用户体验）。

我在这里最大的心愿是，咱们正在走过碎片化的时代，走过每天都有新的 JS 框架的时代。自在和灵便孕育了翻新，但它们也导致了 web 体验的凌乱、不连贯，而且经常是根本性的毁坏。

当开发者不得不在 50 多个选项中做出抉择，并在无限的资源和紧迫的期限内将它们拼凑在一起时，这就是咱们看到的体验，这也是正当的。一些应用程序十分疾速、统一、牢靠，应用起来也很乏味，而另一些则令人丧气、困惑、迟缓和破损。

如果咱们能给开发者提供更容易应用的工具，默认地做正确的事件，兴许个别的网站会变得更好一些，个别的体验会更顺畅一些。

它不会修复每个网站 – 没有多少代码能够解决蹩脚的用户体验设计。但它会奠定一个独特的根底，所以每个网站开始时都会好一点，每个开发人员都有更多的工夫专一于其余事件。

编辑中可能存在的 bug 没法实时晓得，预先为了解决这些 bug, 花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。

作者：Chris 译者：小智 起源：pzuraq

原文：https://www.pzraq.com/blog/fo…

交换

有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。

本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。