早在2012年，我開始主要用JavaScript進(jìn)行編碼。我曾為一家本地企業(yè)從頭到尾做了一個(gè)PHP應(yīng)用，一個(gè)基本的CMS和網(wǎng)站，公司決定要重寫它并增加一些功能。

項(xiàng)目經(jīng)理希望我使用.NET，部分原因是這是他所知道的，但也因?yàn)樗Ｍ@個(gè)應(yīng)用感覺(jué)像一個(gè)本地應(yīng)用程序--沒(méi)有頁(yè)面刷新或操作動(dòng)作長(zhǎng)時(shí)間等待。經(jīng)過(guò)一番研究和原型設(shè)計(jì)，我說(shuō)服了經(jīng)理，可以使用當(dāng)時(shí)剛開始出現(xiàn)的全新JS框架，它能做到這些事項(xiàng)。

我選擇的第一個(gè)框架實(shí)際上是 Angular 1。在我遇到路由器的一些問(wèn)題之前，已經(jīng)建立了一個(gè)相當(dāng)大的應(yīng)用程序，并使用FuelPHP的后端--每當(dāng)重新渲染子路由/出口時(shí)，它就會(huì)閃爍，而且真的感覺(jué)它在設(shè)計(jì)時(shí)沒(méi)有考慮到這種場(chǎng)景。

?后面，有人向我推薦了Ruby on Rails + Ember，在試過(guò)之后，覺(jué)得效果很好。我也喜歡這兩個(gè)框架的理念，喜歡這些社區(qū)生態(tài)，而且與當(dāng)時(shí)的替代方案相比，總的來(lái)說(shuō)，它非常有成效。

從那時(shí)起，很多事情都發(fā)生了變化--框架層出不窮，并且有了很大的發(fā)展。去無(wú)可以在瀏覽器中用JavaScript構(gòu)建應(yīng)用程序的想法，從某種程度上的邊緣變成了一種標(biāo)準(zhǔn)做法。我們構(gòu)建的基礎(chǔ)設(shè)施已經(jīng)完全改變，實(shí)現(xiàn)了一系列新的可能性。

在這段時(shí)間里，各種想法之間也有相當(dāng)多的競(jìng)爭(zhēng)和沖突。使用哪種JavaScript框架，如何編寫CSS，函數(shù)式編程與面向?qū)ο缶幊?，如何最好地管理狀態(tài)，哪種構(gòu)建系統(tǒng)或工具最靈活、最快速，等等?；仡欉^(guò)去，這些覺(jué)得很有趣，我們經(jīng)常爭(zhēng)論的是錯(cuò)誤的事情，而忽略了一些前瞻性，當(dāng)然，這也是事后諸葛亮。

所以我想做一個(gè)回顧，回顧過(guò)去幾十年的JavaScript開發(fā)，看看我們已經(jīng)走了多遠(yuǎn)。我們可以把它大致分為四個(gè)主要時(shí)代。：

• 原始年代
• 第一個(gè)框架
• 以組件為中心的視圖層
• 全棧式框架

每一個(gè)時(shí)代都有自己的主題和核心矛盾，同時(shí)也都想到吸取關(guān)鍵教訓(xùn)，并穩(wěn)步前進(jìn)。

今天，爭(zhēng)論仍在繼續(xù)。web 是否變得過(guò)于臃腫？一般的網(wǎng)站真的需要用React編寫嗎？我們甚至應(yīng)該使用JavaScript嗎？當(dāng)然，當(dāng)前也不能代表未來(lái)，未來(lái)現(xiàn)有框架很大可能也會(huì)被替換，但是，也是從現(xiàn)有的一些觀點(diǎn)出來(lái)，幫助我們向前邁進(jìn)。

原始年代

JavaScript是在1995年首次發(fā)布的。就像我上面提到的，我是在2012年開始寫JS的，差不多20年后，接近我稱之為第一框架的時(shí)代的開始。你可以認(rèn)為，我在這里可能會(huì)掩蓋很多歷史，而且這個(gè)時(shí)代可能會(huì)被分解成許多子時(shí)代，每個(gè)時(shí)代都有自己的模式、庫(kù)和構(gòu)建工具等等。

也就是說(shuō)，我不能寫我沒(méi)有經(jīng)歷過(guò)的事情。當(dāng)我開始編寫前端應(yīng)用程序時(shí)，新一代的框架剛剛開始走向成熟。Angular.js、Ember.js、Backbone，等等。

在這之前，最先進(jìn)的技術(shù)是jQuery和MooTools等庫(kù)。這些庫(kù)在它們的時(shí)代非常重要--它們幫助平滑了瀏覽器實(shí)現(xiàn)JavaScript的方式之間的差異，這些差異是非常重要的。

例如，IE 實(shí)現(xiàn)事件的方式與Netscape完全不同--冒泡事件與捕獲事件。這就是為什么我們今天的標(biāo)準(zhǔn)最終實(shí)現(xiàn)了這兩種方式，但在這之前，我們需要使用庫(kù)來(lái)編寫能在兩種瀏覽器上使用的代碼。

這些庫(kù)主要用于制作小型的、獨(dú)立的用戶界面組件。大多數(shù)應(yīng)用程序的業(yè)務(wù)邏輯仍然是通過(guò)表單和標(biāo)準(zhǔn)的HTTP請(qǐng)求進(jìn)行的--在服務(wù)器上渲染HTML并將其提供給客戶端。

在這個(gè)時(shí)代也沒(méi)有什么構(gòu)建工具可言，至少我知道的是。當(dāng)時(shí)的JavaScript還沒(méi)有模塊（至少?zèng)]有標(biāo)準(zhǔn)的模塊），所以沒(méi)有任何辦法導(dǎo)入代碼。所有的東西都是全局性的，要組織好這些東西是非常困難的。

在這種環(huán)境下，可以理解的是，JS通常被視為一種玩具語(yǔ)言，而不是你用它來(lái)寫一個(gè)完整的應(yīng)用程序。那時(shí)我們最常做的事情是加入 jQuery，為一些UI小部件編寫一些腳本，然后就可以了。

隨著時(shí)間的推移和XHR的引入和普及，人們開始把他們的UI流程的一部分放到一個(gè)頁(yè)面中，特別是對(duì)于需要在客戶端和服務(wù)器之間進(jìn)行多次來(lái)回交互的復(fù)雜流程，但應(yīng)用程序的大部分內(nèi)容還是留在服務(wù)器上。

這與移動(dòng)應(yīng)用開始出現(xiàn)時(shí)的情況形成了鮮明的對(duì)比。從一開始，iOS和Android上的移動(dòng)應(yīng)用就是用Objective C和Java等嚴(yán)肅語(yǔ)言?編寫的完整應(yīng)用。此外，它們是完全由API驅(qū)動(dòng)的--所有的UI邏輯都在設(shè)備上，與服務(wù)器的通信純粹是數(shù)據(jù)格式的。這導(dǎo)致了更好的用戶體驗(yàn)和移動(dòng)應(yīng)用的爆炸性增長(zhǎng)，直接導(dǎo)致了我們今天關(guān)于移動(dòng)和 web 哪個(gè)更好的爭(zhēng)論。

用JavaScript做這一切，起初被認(rèn)為是可笑的。但隨著時(shí)間的推移，應(yīng)用程序開始變得更加雄心勃勃。社交網(wǎng)絡(luò)增加了聊天、DM和其他實(shí)時(shí)功能，Gmail和Google Docs表明可以在瀏覽器中編寫相當(dāng)于桌面應(yīng)用，越來(lái)越多的公司轉(zhuǎn)向編寫 web應(yīng)用，因?yàn)?web 在任何地方都可以工作，而且更容易長(zhǎng)期維護(hù)。這推動(dòng)了整個(gè)行業(yè)的發(fā)展--現(xiàn)在很明顯，JS可以用來(lái)編寫非簡(jiǎn)單的應(yīng)用程序。

當(dāng)時(shí)的JavaScript還沒(méi)有今天的所有功能，所有的東西都是全局的，通常需要手動(dòng)下載并將每個(gè)外部庫(kù)添加到靜態(tài)文件夾中。當(dāng)時(shí)還沒(méi)有NPM，模塊也不存在，JS也沒(méi)有今天一半的功能。

在大多數(shù)情況下，每個(gè)應(yīng)用程序都是定制的，每個(gè)頁(yè)面都有不同的插件設(shè)置，每個(gè)插件都有不同的系統(tǒng)來(lái)管理狀態(tài)和渲染更新。為了解決這些問(wèn)題，最早的JavaScript框架開始出現(xiàn)了。

第一個(gè)框架

大約在2000年代末和2010年代初，第一批專門用于編寫完整客戶端應(yīng)用程序的JS框架開始出現(xiàn)。這個(gè)時(shí)代的幾個(gè)有名的框架：

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

當(dāng)然，還有很多其他的，可能還有一些在某些圈子里更大的。這些是我記得的，主要是因?yàn)樾∶饔盟鼈儊?lái)編碼，而且它們比較受歡迎。

這是一代框架，正在進(jìn)入未知的領(lǐng)域。一方面，他們?cè)噲D做的事情是非常雄心勃勃的，而且很多人認(rèn)為它永遠(yuǎn)不會(huì)真正成功。

有許多反對(duì)者認(rèn)為單頁(yè)JS應(yīng)用程序（SPA）從根本上來(lái)說(shuō)更糟糕，而且在很多方面他們是對(duì)的--客戶端渲染意味著機(jī)器人不能輕易抓取這些頁(yè)面，而且用戶甚至需要等待幾秒鐘才能開始繪制應(yīng)用程序。很多這些應(yīng)用程序都是無(wú)障礙的噩夢(mèng)，如果關(guān)閉了JavaScript，它們就根本無(wú)法工作。

另一方面，我們沒(méi)有在JS中構(gòu)建完整應(yīng)用程序的經(jīng)驗(yàn)，因此有大量關(guān)于最佳方法的競(jìng)爭(zhēng)性想法。大多數(shù)框架都試圖模仿其他平臺(tái)上的流行做法，所以幾乎所有的框架最后都是Model-View-*的某種迭代。Model-View-Controller，Model-View-Producer，Model-View-ViewModel等等。但從長(zhǎng)遠(yuǎn)來(lái)看，這些都不是真正意義上的成功--它們并不特別直觀，而且很快就變得非常復(fù)雜。

這也是一個(gè)我們真正開始嘗試如何編譯JavaScript應(yīng)用程序的時(shí)代。Node.js在2009年發(fā)布，NPM在2010年緊隨其后，為（服務(wù)器端的）JavaScript引入了包。

CommonJS和AMD爭(zhēng)奪如何最好地定義JS模塊，而像Grunt、Gulp和Broccoli這樣的構(gòu)建工具則爭(zhēng)奪如何將這些模塊組合成一個(gè)可交付的最終產(chǎn)品。

在大多數(shù)情況下，這些都是非常通用的任務(wù)運(yùn)行器式的工具，它們真的可以構(gòu)建任何東西，只是碰巧要構(gòu)建JavaScript--還有HTML、CSS/SASS/LESS，以及其他許多進(jìn)入web應(yīng)用的東西。

然而，我們從這個(gè)時(shí)代學(xué)到了很多東西:

• 基于URL的路由是基礎(chǔ)。沒(méi)有這種路由的應(yīng)用程序會(huì)破壞 web，因此需要在框架中從一開始就考慮到這一點(diǎn)。
• 通過(guò)模板化語(yǔ)言擴(kuò)展HTML是一個(gè)強(qiáng)大的抽象層。即使它有時(shí)會(huì)有點(diǎn)笨拙，但它使用戶界面與狀態(tài)保持同步變得更加容易。
• SPA的性能很差，而且web有許多原生應(yīng)用所沒(méi)有的額外限制。我們需要通過(guò) web 發(fā)布所有的代碼，讓它JIT，然后運(yùn)行來(lái)啟動(dòng)我們的應(yīng)用程序，而本地應(yīng)用程序已經(jīng)下載和編譯，這是一項(xiàng)艱巨的任務(wù)。
• 作為一種語(yǔ)言，JavaScript有很多問(wèn)題，它確實(shí)需要被改進(jìn)，以使事情變得更好--框架無(wú)法單獨(dú)做到這一點(diǎn)。
• 我們絕對(duì)需要更好的構(gòu)建工具、模塊和包裝，以便大規(guī)模地編寫應(yīng)用程序。

總的來(lái)說(shuō)，這個(gè)時(shí)代是富有成效的。盡管有缺點(diǎn)，但隨著應(yīng)用程序的復(fù)雜性增加，將客戶端與API分離的好處是巨大的，而且在許多情況下，所產(chǎn)生的用戶體驗(yàn)是驚人的。如無(wú)特殊情況，這個(gè)時(shí)代可能會(huì)繼續(xù)下去，我們到現(xiàn)在還在迭代MV*風(fēng)格的想法。

但后來(lái)一顆小行星突然出現(xiàn)，把現(xiàn)有的范式砸得四分五裂，造成了一次小規(guī)模的滅絕事件，把我們推進(jìn)了下一個(gè)時(shí)代--這顆小行星名叫React。

以組件為中心的視圖層

我不認(rèn)為React發(fā)明了組件，但說(shuō)實(shí)話，我也不太清楚它們最早來(lái)自哪里。但至少可以追溯到.NET中的XAML，而 web 組件也在那時(shí)開始作為一種規(guī)范發(fā)展。最終它并不重要——一旦這個(gè)想法出現(xiàn)了，每個(gè)主要的框架都很快地采用了它。

事后看來(lái)，這完全是有道理的--擴(kuò)展HTML，減少長(zhǎng)期存在的狀態(tài)，將JS業(yè)務(wù)邏輯直接與模板綁定（無(wú)論是JSX還是Handlebars還是Directives）。

基于組件的應(yīng)用程序消除了完成工作所需的大部分抽象概念，并且明顯地簡(jiǎn)化了代碼的生命周期--一切都與組件的生命周期而不是應(yīng)用程序的生命周期聯(lián)系在一起，這意味著作為一個(gè)開發(fā)人員，你要考慮的事情要少得多。

然而，當(dāng)時(shí)還有一個(gè)轉(zhuǎn)變：框架開始把自己吹噓成 "視圖層"，而不是成熟的框架。他們不再解決前端應(yīng)用所需的所有問(wèn)題，而是專注于解決渲染問(wèn)題。

其他問(wèn)題，如路由、API通信和狀態(tài)管理，則由用戶自己決定。這個(gè)時(shí)代著名的框架有：

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

還有很多其他的?，F(xiàn)在回過(guò)頭來(lái)看，我認(rèn)為這是第二代框架的一個(gè)流行框架，因?yàn)樗_實(shí)做了兩件主要的事情。

• 它極大地縮小了范圍。該框架的核心不是試圖在前期解決所有這些問(wèn)題，而是專注于渲染，許多不同的想法和方向可以在更廣泛的生態(tài)系統(tǒng)中探索其他功能。有很多糟糕的解決方案，但也有很好的解決方案，為下一代從精華中挑選最好的想法鋪平了道路。
• 這讓我們更容易接受它們。采用一個(gè)完整的框架來(lái)接管你的整個(gè)網(wǎng)頁(yè)意味著重寫你的大部分應(yīng)用程序，這對(duì)于現(xiàn)有的服務(wù)器端巨石來(lái)說(shuō)是不可能的。使用像React和Vue這樣的框架，你可以一次一個(gè)小部件或組件地將它們的一小部分放入現(xiàn)有的應(yīng)用程序中，允許開發(fā)人員增量地遷移他們現(xiàn)有的代碼。

這兩個(gè)因素導(dǎo)致第二代框架迅速發(fā)展，使第一代框架黯然失色，從遠(yuǎn)處看，這一切似乎很有意義，是一種合理的演變。但在當(dāng)時(shí)身處其中，是相當(dāng)令人沮喪的經(jīng)歷。

首先，當(dāng)我們?cè)诠ぷ髦袪?zhēng)論使用哪種框架，或者是否應(yīng)該重寫我們的應(yīng)用程序時(shí)，并不經(jīng)常遇到這樣的框架。相反，很多時(shí)候是 "它更快！"或 "它更??！"或 "它是你所需要的一切！"。

還有關(guān)于函數(shù)式編程和面向?qū)ο缶幊痰霓q論，很多人把FP作為我們所有問(wèn)題的解決方案。公平地說(shuō)，這些事情都是真的。僅有視圖層的框架更?。ㄆ鸪酰?、更快（起初），而且是你所需要的全部（如果你自己建立或縫合了很多東西）。

當(dāng)然，函數(shù)式編程模式解決了大量困擾JavaScript的問(wèn)題，我認(rèn)為平均而言，JS因?yàn)樗鼈兌兊酶谩?/p>

然而，現(xiàn)實(shí)是根本就沒(méi)有什么靈丹妙藥。應(yīng)用程序仍然龐大、臃腫和復(fù)雜，狀態(tài)仍然難以管理，路由和SSR等基本問(wèn)題仍然需要解決。

對(duì)于我們中的很多人來(lái)說(shuō)，人們想要的似乎是放棄試圖解決所有這些問(wèn)題的解決方案，而換成一個(gè)讓讀者自己去解決的解決方案。

根據(jù)我的經(jīng)驗(yàn)，這也是工程小組的普遍做法，他們會(huì)很高興地接受這種改變，以便交付一個(gè)新的產(chǎn)品或功能，然后又不資助完全開發(fā)所有這些額外功能所需的時(shí)間。

其結(jié)果是圍繞這些視圖層建立的自制框架，而這些框架本身是臃腫的、復(fù)雜的，而且非常難以操作。

我認(rèn)為人們?cè)谑褂肧PA時(shí)遇到的許多問(wèn)題都來(lái)自于這種分散的生態(tài)系統(tǒng)，而這種生態(tài)系統(tǒng)恰恰是在SPA使用爆炸性增長(zhǎng)的時(shí)候出現(xiàn)的。我仍然經(jīng)常遇到一個(gè)新的網(wǎng)站，它不能正確地做路由或很好地處理其他小細(xì)節(jié)，這絕對(duì)是令人沮喪的。

但另一方面，現(xiàn)有的第一代全服務(wù)框架在解決這些問(wèn)題方面也做得不是很好。部分原因是由于大量的技術(shù)債務(wù)包袱。第一代框架是在ES6之前，在模塊之前，在Babel和Webpack之前，在我們弄清楚許多事情之前建立的。

迭代進(jìn)化是非常困難的，而且完全重寫它們，就像Angular對(duì)Angular 2所做的那樣，扼殺了他們社區(qū)的發(fā)展勢(shì)頭。

因此，當(dāng)涉及到JavaScript框架時(shí)，開發(fā)人員處于兩難境地--要么選擇一個(gè)開始顯示其年齡的一體化解決方案，要么跳入自由競(jìng)爭(zhēng)中，DIY一半的框架，希望得到最好的結(jié)果。

當(dāng)時(shí)這讓人非常沮喪，但最后還是產(chǎn)生了大量的創(chuàng)新。隨著這些框架找出它們的最佳實(shí)踐，JavaScript生態(tài)系統(tǒng)的發(fā)展非常迅速，還發(fā)生了一些其他的關(guān)鍵變化。

• 像 Babel 這樣的轉(zhuǎn)譯器成為常態(tài)，并有助于使語(yǔ)言現(xiàn)代化。與其等待多年的功能標(biāo)準(zhǔn)化，不如今天就能使用，而語(yǔ)言本身也開始以更快、更迭代的速度增加功能。
• ES模塊被標(biāo)準(zhǔn)化，使我們最終開始圍繞它們構(gòu)建現(xiàn)代構(gòu)建工具，如Rollup、Webpack和Parcel?；趯?dǎo)入的 bundling 慢慢成為規(guī)范，即使是樣式和圖片等非JS資源也是如此，這極大地簡(jiǎn)化了構(gòu)建工具的配置，使它們變得更精簡(jiǎn)、更快速、更全面。
• 隨著越來(lái)越多的API被標(biāo)準(zhǔn)化，Node和 web 標(biāo)準(zhǔn)之間的差距也在緩慢但穩(wěn)步地縮小。SSR開始成為一種真正的可能性，然后是每個(gè)嚴(yán)肅的應(yīng)用程序都在做的事情，但每次都是一種定制的設(shè)置。
• 釋放了Edge Computing，為基于JavaScript的服務(wù)器應(yīng)用程序提供了SPA在分布/響應(yīng)時(shí)間方面的好處（Spas以前由于在CDN上是靜態(tài)文件，因此通?？梢愿斓亻_始加載加載，即使它們花了更長(zhǎng)的時(shí)間才能完全加載并在結(jié)束）。

在這個(gè)時(shí)代結(jié)束的時(shí)候，一些問(wèn)題仍然存在。狀態(tài)管理和響應(yīng)性仍然是（現(xiàn)在也是）棘手的問(wèn)題，盡管我們有比以前更好的模式。

性能仍然是一個(gè)困難的問(wèn)題，盡管情況正在改善，但仍然有很多很多臃腫的SPA在那里。

可訪問(wèn)性的情況也有所改善，但對(duì)于許多工程機(jī)構(gòu)來(lái)說(shuō)，它仍然經(jīng)常是一個(gè)事后的想法。但這些變化為下一代框架鋪平了道路，我想說(shuō)的是，我們現(xiàn)在正在進(jìn)入下一代框架。

全棧式框架

就我個(gè)人而言，上一個(gè)框架時(shí)代真的悄悄來(lái)臨了。我想這是因?yàn)槲以谶^(guò)去4年左右的時(shí)間里深入到Ember渲染層的內(nèi)部，試圖解決前面提到的影響它作為第一代框架的技術(shù)債務(wù)（仍然）。但這也是因?yàn)樗游⒚?，因?yàn)樗羞@些第三代框架都是圍繞上一代的視圖層框架建立的。這些框架包括：

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

這些框架是隨著視圖層的成熟和鞏固而開始的。既然我們都同意組件是建立在核心基礎(chǔ)之上的，那么開始標(biāo)準(zhǔn)化應(yīng)用程序的其他部分--路由器、構(gòu)建系統(tǒng)、文件夾結(jié)構(gòu)等，就很有意義了。

慢慢地，這些元框架開始建立起與第一代多合一解決方案開箱即用的相同功能，從各自的生態(tài)系統(tǒng)中挑選最佳模式，并隨著它們的成熟而將其納入。

然后他們又進(jìn)一步。

在這之前，SPA一直只專注于客戶端。SSR是每個(gè)框架都希望解決的問(wèn)題，但只是作為一種優(yōu)化，一種獲得渲染的方式，最終會(huì)在數(shù)兆字節(jié)的JS最終加載完畢后被取代。

只有一個(gè)第一代框架敢于想得更遠(yuǎn)，即Meteor.js，但它同構(gòu)JS的想法從未真正實(shí)現(xiàn)。

但隨著應(yīng)用程序的規(guī)模和復(fù)雜性的增加，這個(gè)想法被重新審視。

我們注意到，將后端和前端搭配在一起實(shí)際上是非常有用的，這樣你就可以做一些事情，比如為某些請(qǐng)求隱藏API秘密，在返回頁(yè)面時(shí)修改頭文件，代理API請(qǐng)求。隨著Node和Deno實(shí)現(xiàn)了越來(lái)越多的 web 標(biāo)準(zhǔn)，服務(wù)器端JS和客戶端JS之間的差距每年都在縮小，它開始看起來(lái)畢竟不是一個(gè)瘋狂的想法。將其與 edge-computing和驚人的工具結(jié)合起來(lái)，就會(huì)有一些令人難以置信的潛力。

最新一代的框架充分利用了這種潛力，將客戶端和服務(wù)器無(wú)縫地融合在一起，我無(wú)法強(qiáng)調(diào)這種感覺(jué)有多么令人驚訝。在過(guò)去9個(gè)月與SvelteKit的合作中，我不知道有多少次坐下來(lái)對(duì)自己說(shuō)："這就是我們應(yīng)該一直做的事情。"

以下是我最近遇到的一些任務(wù)，通過(guò)這種設(shè)置，這些任務(wù)變得異常簡(jiǎn)單。

• 將服務(wù)器端的OAuth添加到我們的應(yīng)用程序中，這樣認(rèn)證令牌就不會(huì)離開服務(wù)器，同時(shí)還有一個(gè)API代理，在向我們的API發(fā)送請(qǐng)求時(shí)添加令牌。
• 將某些路由直接代理到我們的CDN，這樣我們就可以托管在任何其他框架中構(gòu)建的靜態(tài)HTML頁(yè)面，允許用戶制作自己的定制頁(yè)面（我們?yōu)橐恍┛蛻籼峁┑姆?wù)）。
• 當(dāng)我們需要使用一個(gè)需要密匙的外部服務(wù)時(shí)，添加幾個(gè)不同的一次性API路由（不需要為我們的API添加一個(gè)全新的路由并與后端人員協(xié)調(diào)）。
• 將我們對(duì)LaunchDarkly的使用轉(zhuǎn)移到服務(wù)器端，這樣我們就可以加載更少的JS，從而降低整體成本。
• 通過(guò)后端路由代理我們的Sentry請(qǐng)求，這樣我們就可以捕捉到由于廣告屏蔽器而未被報(bào)告的錯(cuò)誤。

而這僅僅是冰山一角。這種模式真的有很多很酷的地方，其中最大的一點(diǎn)是它如何重振漸進(jìn)式增強(qiáng)的理念，利用服務(wù)器和客戶端的組合特性，允許客戶端在用戶禁用JavaScript的情況下回退到基本的HTML + HTTP。

當(dāng)我開始從事SPA工作時(shí)，我自己已經(jīng)完全放棄了這種做法，認(rèn)為它們是未來(lái)的趨勢(shì)，但我們有可能看到它卷土重來(lái)的世界，這真的很酷。

這些是新的功能，從經(jīng)驗(yàn)上看，我把這些框架歸為新一代的框架。以前難以解決或不可能解決的問(wèn)題現(xiàn)在變得微不足道，只需改變一點(diǎn)點(diǎn)的響應(yīng)處理邏輯。

可靠的性能和用戶體驗(yàn)是開箱即用的，不需要任何額外的配置。我們不需要建立整個(gè)新的服務(wù)，而是能夠根據(jù)需要添加一些額外的端點(diǎn)或中間件。這已經(jīng)改變了生活。

我認(rèn)為這一代也解決了第一代和第二代框架及其用戶之間的一些主要矛盾點(diǎn)。

它始于向零配置術(shù)語(yǔ)的轉(zhuǎn)變，但我認(rèn)為它最終是由圍繞第二代框架的生態(tài)系統(tǒng)的成熟和穩(wěn)定所驅(qū)動(dòng)的，這也是一種文化轉(zhuǎn)變。

第三代框架現(xiàn)在正試圖再次成為一體化的解決方案，試圖解決我們作為前端開發(fā)者需要解決的所有基本問(wèn)題--不僅僅是渲染。

現(xiàn)在比以往任何時(shí)候都感覺(jué)到社區(qū)在解決所有困擾SPA的許多問(wèn)題方面是一致的，而且重要的是，共同解決了這些問(wèn)題。

我們接下來(lái)要去哪里？

總的來(lái)說(shuō)，我認(rèn)為JavaScript社區(qū)正朝著正確的方向發(fā)展。我們終于開發(fā)出了成熟的解決方案，可以從頭開始構(gòu)建完整的應(yīng)用程序，這些解決方案并不是 "僅僅是一個(gè)視圖層"。

我們終于開始與原生應(yīng)用的SDK在同一起跑線上競(jìng)爭(zhēng)，提供一個(gè)開箱即用的完整工具包。

我們?cè)谶@方面仍有很多工作要做。在SPA領(lǐng)域，可訪問(wèn)性長(zhǎng)期以來(lái)一直是一個(gè)事后的想法，而在GraphQL之外，我仍然認(rèn)為 data story 可以使用一些工作（不管你喜歡與否，大部分的 web 仍然運(yùn)行在REST上）。

但趨勢(shì)是正確的，如果我們繼續(xù)朝著共享解決方案的方向發(fā)展，我認(rèn)為我們可以用比以前更好的方式解決這些問(wèn)題。

我還對(duì)將這些模式進(jìn)一步提升到 web平臺(tái)本身背后的潛力感到興奮。Web組件仍在悄悄地迭代，致力于解決SSR和擺脫全局注冊(cè)等問(wèn)題，這將使它們與這些第三代框架更加兼容。

在另一個(gè)方向，WebAssembly可以以一種令人難以置信的方式迭代這種模式。想象一下，能夠用任何語(yǔ)言編寫一個(gè)全棧框架。

同構(gòu)的Rust、Python、Swift、Java等語(yǔ)言最終可以將前臺(tái)和后臺(tái)之間的障礙減少到幾乎為零--只是在你的系統(tǒng)邊緣有一點(diǎn)HTML模板（這諷刺地使我們幾乎繞了一圈，盡管有更好的用戶體驗(yàn)）。

我在這里最大的希望是，我們正在走過(guò)碎片化的時(shí)代，走過(guò)每天都有新的JS框架的時(shí)代。自由和靈活孕育了創(chuàng)新，但它們也導(dǎo)致了 web 體驗(yàn)的混亂、不連貫，而且常常是根本性的破壞。

當(dāng)開發(fā)者不得不在50多個(gè)選項(xiàng)中做出選擇，并在有限的資源和緊迫的期限內(nèi)將它們拼湊在一起時(shí)，這就是我們看到的體驗(yàn)，這也是合理的。一些應(yīng)用程序非?？焖?、一致、可靠，使用起來(lái)也很有趣，而另一些則令人沮喪、困惑、緩慢和破損。

如果我們能給開發(fā)者提供更容易使用的工具，默認(rèn)地做正確的事情，也許一般的網(wǎng)站會(huì)變得更好一些，一般的體驗(yàn)會(huì)更順暢一些。

它不會(huì)修復(fù)每個(gè)網(wǎng)站--沒(méi)有多少代碼可以解決糟糕的用戶體驗(yàn)設(shè)計(jì)。但它會(huì)奠定一個(gè)共同的基礎(chǔ)，所以每個(gè)網(wǎng)站開始時(shí)都會(huì)好一點(diǎn)，每個(gè)開發(fā)人員都有更多的時(shí)間專注于其他事情。?