早在2012年，我就開始用JavaScript進行編碼。

我曾為一家當(dāng)?shù)氐钠髽I(yè)從頭到尾開發(fā)了一款PHP應(yīng)用程序，這是一個簡單的CMS網(wǎng)站。后來，他們決定要重新編寫它并增加一些功能。這個項目的經(jīng)理希望我使用.NET來開發(fā)，其中的部分原因是他比較了解這項技術(shù)，同時他也希望能夠?qū)⑦@個項目做成一個類似本地的應(yīng)用程序——減少頁面加載的時間。經(jīng)過一番研究和原型設(shè)計，我說服他用網(wǎng)頁的方式做同樣的事情，也就是在這個時候，全新的JS框架出現(xiàn)了。

我選擇的第一個框架實際上是Angular 1。彼時，我基于FuelPHP后端開發(fā)了一個相當(dāng)大的應(yīng)用程序。在功能上，每當(dāng)重新渲染子路由/出口時，路由器就會閃爍，這一點是我們在開發(fā)過程中沒有考慮過的突發(fā)情況。后來，有人向我推薦了Ruby on Rails + Ember的解決方案，在試過之后，我覺得效果很好。我喜歡這兩個框架的理念，喜歡構(gòu)建它們的社區(qū)。

從那時起， 很多事情都發(fā)生了變化 ， 許多新的框架出現(xiàn)，舊的框架淘汰。 用JavaScript 在瀏覽器中 構(gòu)建應(yīng)用程序的想法，從 少數(shù)開發(fā)者的嘗試逐漸 變成了 前端領(lǐng)域中 一種標(biāo)準(zhǔn) 的操作方式 。 隨著開發(fā)者所構(gòu)建 的基礎(chǔ)設(shè)施 的 改變， 帶來 了 許多 新的可能。

在這段時間里，不少開發(fā)者的很多想法陷入糾結(jié)、自相矛盾的迷茫中。我想很多在前端領(lǐng)域工作了一段時間的人可能都有過這樣的經(jīng)歷，糾結(jié)使用哪種JavaScript框架、如何編寫CSS、使用函數(shù)式編程還是面向?qū)ο缶幊獭⑷绾巫詈玫毓芾頎顟B(tài)、哪種構(gòu)建系統(tǒng)或工具最靈活、最快速等等。 

回顧過去，我覺得很有趣，因為我們經(jīng)常為小的錯誤爭論不休，而忽略了更有意義的事情，當(dāng)然這也是“事后諸葛亮”了。所以我想做一個回顧，總結(jié)過去幾十年的JavaScript開發(fā)，看看我們已經(jīng)走了多遠。我認為我們可以把它粗略地分為四個主要時代：

1. 前世
2. 第一代框架
3. 以組件為中心的視圖層
4. 全棧式框架 (← 這也是我們當(dāng)前所處的位置)

每個時代都有自己標(biāo)志性的特點和亟待解決的矛盾，每一個時代也賦予了我們不同的經(jīng)驗與教訓(xùn)，最終讓我們?nèi)〉昧诉M步。

關(guān)于JavaScript開發(fā)，直到今天爭論仍在繼續(xù)：網(wǎng)站是否變得過于臃腫？普通網(wǎng)站真的需要用React編寫嗎？我們甚至應(yīng)該使用JavaScript嗎？我不認為我們能在這里看到未來，而且最后我懷疑我們可能會再次發(fā)現(xiàn)，我們在互相討論的過程中，沒有關(guān)注到更廣泛與有意義的技術(shù)。但是，回看過去，也許其中的一些觀點也能夠幫助我們更好地走向未來。

前世

JavaScript是在1995年首次發(fā)布的。就像我上面提到的，我是在2012年開始寫JS的，差不多是 JavaScript 誕生的20年后，也就是我稱之為 First Frameworks 時代的開始。你可以想象，這個時代可能會被分解成許多子時代，每個時代都有自己的模式、庫和構(gòu)建工具等。

也就是說，我不能寫自己沒有經(jīng)歷過的事情。當(dāng)我開始編寫前端應(yīng)用程序時，新一代的框架剛剛開始成熟，像Angular.js、Ember.js、Backbone等等。

在這之前，最先進的是jQuery、MooTools等庫。這些庫在他們的時代是非常重要的，它們幫助消除瀏覽器實現(xiàn)JavaScript方式之間的差異，這些差異非常重要。例如，IE實現(xiàn)事件的方式與Netscape（網(wǎng)景瀏覽器）完全不同，其方式分別為事件冒泡與事件捕獲。這就是為什么我們今天的標(biāo)準(zhǔn)最終實現(xiàn)了這兩種方式的原因，但在這之前，你需要使用庫來編寫能在兩種瀏覽器上使用的代碼。這些庫主要用于制作小型的、獨立的用戶界面部件。大多數(shù)應(yīng)用程序的業(yè)務(wù)邏輯仍然是通過表單和標(biāo)準(zhǔn)的HTTP請求進行的，即在服務(wù)器上渲染HTML并將其提供給客戶端。

在這個時代，也沒有很多構(gòu)建工具可言（至少我了解到的沒有）。當(dāng)時的JavaScript還沒有模塊（至少沒有標(biāo)準(zhǔn)的模塊）功能，所以沒有任何辦法導(dǎo)入代碼。所有的東西都是全局性的，要組織好這些東西是非常困難的。

在這種環(huán)境下，可以理解JS通常被視為一種用來點綴的語言，而不是能用它來寫一個完整的應(yīng)用程序。那時開發(fā)者最常做的事情是使用jQuery，為一些UI小部件編寫一些腳本就可以了。隨著時間的推移和XHR的引入及普及，開發(fā)者開始把他們的UI流程的一部分放到一個頁面中，特別是對于需要在客戶端和服務(wù)器之間進行多次來回交互的復(fù)雜流程，但應(yīng)用程序的大部分內(nèi)容還是留在服務(wù)器上。

這與移動應(yīng)用開始出現(xiàn)時的情況形成了鮮明的對比。從一開始，iOS和Android上的移動應(yīng)用程序就是用Objective-C和Java等高級語言編寫的完整應(yīng)用。此外，它們是完全由API驅(qū)動——所有的UI邏輯都存在設(shè)備上，而與服務(wù)器的通信則純粹是以數(shù)據(jù)形式進行。這帶來了更好的用戶體驗和移動應(yīng)用程序的爆炸性增長，直接導(dǎo)致了我們今天關(guān)于移動設(shè)備和Web 網(wǎng)絡(luò)哪個更好的爭論。

最初，用JavaScript來做所有這些事，被很多人認為是可笑的。但隨著時間的推移，應(yīng)用程序開始變得更加雄心勃勃。很多社交網(wǎng)絡(luò)平臺增加了聊天、DM和其他實時功能，Gmail和Google Docs驗證了在瀏覽器端也能實現(xiàn)與桌面一樣的用戶體驗，越來越多的公司開始提供Web應(yīng)用開發(fā)服務(wù)，因為在他們看來，Web在任何地方都可以使用，而且更容易長期維護。這推動了Web整個行業(yè)的發(fā)展。

很明顯，現(xiàn)在JS可以用來編寫更為復(fù)雜的應(yīng)用程序。然而，當(dāng)時環(huán)境下，想要實現(xiàn)這一點還是有些困難的，因為那時的JavaScript并不具備今天的所有功能。就像我說的，所有東西都是全局性的，你通常需要手動下載并將每個外部庫添加到你的靜態(tài)資產(chǎn)文件夾中。當(dāng)時還沒有NPM，模塊也不存在，JS也沒有今天一半的功能。在大多數(shù)情況下，每個應(yīng)用程序都是需要定制的，每個頁面都有不同的插件設(shè)置，每個插件都有不同的系統(tǒng)來管理狀態(tài)和渲染更新。為了解決這些問題，最早的JavaScript框架出現(xiàn)了。

第一代框架

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

• Backbon e.js
• Angul a r 1
• Kno c ko ut.js
• S prou t Cor e
• Em be r.js
• Me t eo r .js

當(dāng)然，還有很多其他或是在某些圈子里更知名一些的框架。不過，以上這些是我記得的，我也常用它們來做原型或進行構(gòu)建。

這是第一代框架，也正式開啟了未知領(lǐng)域的大門。一方面，這些框架試圖做的事情是非常超前的，很多人認為它們不會真的成功。有許多反對者認為單頁JS應(yīng)用程序（SPA）從根本上來說很糟糕，而且后來在時間的驗證過程中，證明了這些批判者在很多方面是對的，例如，客戶端渲染意味著自動程序不能輕易抓取這些頁面，而且用戶甚至需要等待幾秒鐘才能開始繪制應(yīng)用程序。很多這些應(yīng)用程序都是噩夢般的存在，如果你關(guān)閉了JavaScript，它們就根本無法工作。

另一方面，我們沒有在JS中構(gòu)建完整應(yīng)用程序的經(jīng)驗，因此關(guān)于最佳方法上，很多開發(fā)者有許多不同的想法。大多數(shù)框架都試圖模仿其他平臺上的流行做法，所以幾乎所有的框架最后都是「Model-View-*」的迭代方式，如Model-View-Controller、Model-View-Producer、Model-View-ViewModel等。從長遠來看，其中的一些問題的確被解決了，但是解決方案往往不太直觀，而且在應(yīng)用過程中越來越復(fù)雜。

這也是一個我們真正開始嘗試如何編譯JavaScript應(yīng)用程序的時代。

Node.js在2009年發(fā)布，NPM在2010年緊隨其后，將包的概念引入（服務(wù)器端的）JavaScript中。CommonJS和AMD就如何定義最好的JS模塊展開競爭，而像Grunt、Gulp和Broccoli這樣的構(gòu)建工具則爭奪如何將這些模塊組合成一個可交付的最終產(chǎn)品。

在大多數(shù)情況下，這些都是非常通用的類似于任務(wù)運行器的工具，可以真正構(gòu)建任何東西，只是碰巧與HTML、CSS/SASS/LESS等技術(shù)結(jié)合，基于JavaScript開發(fā)出很多適用于Web端的產(chǎn)品。

從這個時代，我們學(xué)到了很多東西，收獲了寶貴的經(jīng)驗，包括：

• URL路由是基礎(chǔ)。沒有它的應(yīng)用程序往往會出現(xiàn)Bug，開發(fā)者需要從一開始就在框架中考慮它。
• 通過模板語言擴展HTML是一個強大的抽象層。即使有時它可能有點笨拙，但它可以讓你的UI與狀態(tài)保持同步且更容易。
• SPA（單頁面應(yīng)用）的性能很差，而且Web開發(fā)有許多原生應(yīng)用沒有的額外限制。我們需要通過Web發(fā)布所有代碼，讓它即時編譯（JIT），然后運行以啟動我們所開發(fā)的應(yīng)用程序，而原生應(yīng)用程序已經(jīng)下載和編譯。這是一項艱巨的任務(wù)。
• JavaScript作為一種語言有很多問題，它確實需要改進以使事情變得更好——框架無法單獨做到這一點。
• 我們絕對需要更好的構(gòu)建工具、模塊和包裝來編寫大規(guī)模的應(yīng)用程序。

總的來說，這個時代碩果累累。盡管存在這些缺點，但隨著應(yīng)用程序復(fù)雜性的增加，將客戶端與API分離的好處是巨大的，并且在許多情況下，讓用戶體驗有了飛速提升。如果情況有所不同，這個時代可能還會繼續(xù)，我們可能直到今天還在重復(fù)MV*的風(fēng)格。

但后來，一顆“小行星”的突然出現(xiàn)，把現(xiàn)有的范式砸得粉碎，造成了一個小的滅絕事件，把我們推進了下一個時代——這顆“小行星”名為React。

以組件為中心的視圖層

我不認為React發(fā)明了組件，但說實話，我不太確定它們最初是從哪里來的。我知道現(xiàn)有技術(shù)至少追溯到.NET中的XAML，并且Web組件也在那時開始作為一種規(guī)范開始普及。

現(xiàn)在每個主流的框架都使用了組件。事后看來，它的流行也完全是有道理的——擴展HTML，減少長期存在的狀態(tài)，將JS業(yè)務(wù)邏輯直接與模板聯(lián)系起來（無論是JSX還是Handlebars還是Directives）?；诮M件的應(yīng)用程序消除了完成工作所需的大部分抽象概念，并且明顯地簡化了代碼的生命周期，一切都與組件的生命周期而不是應(yīng)用程序的生命周期聯(lián)系在一起，這意味著作為一個開發(fā)人員，你要考慮的事情要少得多。                                      

然而，當(dāng)時還有一變化：框架開始把自己吹噓成 "視圖層"，而不是完整的框架。他們不再解決前端應(yīng)用所需的所有問題，而只是專注于解決渲染問題，其他問題如路由、API通信和狀態(tài)管理，則由用戶自己決定。這個時代著名的框架包括：

• React.js
• Vue.js
• Svelte
• Polymer.js

當(dāng)然還有很多很多其他的框架?，F(xiàn)在回頭看，我認為這是第二代框架中流行的框架，因為它主要做了兩件事情:

1. 它極大地縮小了范圍。這些框架的核心不是試圖解決前端所有問題，而是專注于渲染，關(guān)于實現(xiàn)其他功能的許多不同的想法和方向可以在更廣泛的系統(tǒng)中探索。盡管有很多糟糕的解決方案，但也有好的解決方案，這也為下一代從精英中挑選最好的創(chuàng)意鋪平了道路。
2. 這讓開發(fā)人員更容易接受。采用一個完整的框架來接管你的整個網(wǎng)頁，意味著你需要重寫大部分應(yīng)用程序，這對于現(xiàn)有的服務(wù)器端來說是不可能的。使用像React和Vue這樣的框架，你可以把它們中的一小部分放到一個現(xiàn)有的應(yīng)用程序中，每次只遷移一個小部件或組件，允許開發(fā)人員逐步遷移他們現(xiàn)有的代碼。

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

首先，在工作中關(guān)于框架選擇的爭論，不會是我們應(yīng)該使用哪種框架來開發(fā)，或者我們是否應(yīng)該重寫我們的應(yīng)用程序。 相反，經(jīng)常是 "它更快！ "或 "它更??！ "或 "它是你需要的一切！ " 。 還有關(guān)于函數(shù)式編程和面向?qū)ο缶幊痰霓q論，很多人把FP作為我們所有問題的解決方案。 平心而論，這些事情都是真的。 僅有視圖層的框架起初更小、更快，而且是你所需要的全部（如果你自己建立或縫合了很多東西）。 當(dāng)然，函數(shù)式編程模式解決了大量困擾JavaScript的問題，而且我認為總體來說，JS因為它們而變得更好。

然而現(xiàn)實是，根本就沒有什么靈丹妙藥。應(yīng)用程序仍然變得龐大、臃腫和復(fù)雜，狀態(tài)仍然難以管理，路由和SSR等基本問題仍然需要解決。對于我們很多人來說，似乎人們想要的是拋棄試圖解決所有這些問題的解決方案，而把這個問題留給讀者。在我的經(jīng)驗里，開發(fā)團隊中普遍會很高興地接受這種想法，以便快速發(fā)布一個新產(chǎn)品或新功能。然而他們卻沒有足夠的時間來充分開發(fā)所有額外的功能。

結(jié)果，根據(jù)我的經(jīng)驗，開發(fā)更多的時候是圍繞這些視圖層建立的自制框架，這些框架本身就很臃腫、復(fù)雜，而且非常難以操作。我認為人們在SPA上遇到的許多問題都來自于這個支離破碎的框架系統(tǒng)，而這個框架系統(tǒng)恰好出現(xiàn)在SPA使用量激增的時候。我仍然經(jīng)常遇到一個新網(wǎng)站不能很好地處理路由或其他小細節(jié)，這絕對是令人沮喪的。

但另一方面，現(xiàn)有的全服務(wù)第一代框架也不能很好地解決這些問題。部分原因在于依然有大量的科技債務(wù)負擔(dān)。第一代框架是在ES6之前，同時也在模塊以及Babel和Webpack之前，是在我們弄清楚許多事情之前建立的。迭代進化是非常困難的（作為前Ember核心團隊成員，我對此深有體會），而且完全重寫它們，就像Angular對Angular 2所做的那樣，扼殺了他們的發(fā)展勢頭。因此，當(dāng)涉及到JavaScript框架時，開發(fā)人員處于兩難境地——要么選擇一個過時的一體化解決方案，要么選擇自由發(fā)揮，并DIY一半的框架，以此希望得到最好的結(jié)果。

就像我說的，當(dāng)時這讓人非常沮喪，可到最后還是涌現(xiàn)了大量的創(chuàng)新。隨著找出這些框架的最佳實踐，JavaScript的整個系統(tǒng)都發(fā)展得非?？欤€發(fā)生了一些其他的關(guān)鍵變化：

• 像Babel這樣的轉(zhuǎn)譯器成為常態(tài)，并有助于使語言現(xiàn)代化。與其等待數(shù)年才能實現(xiàn)功能的標(biāo)準(zhǔn)化，不如今天就能使用，而且語言本身也開始以更快、更多的迭代速度增加功能。
• ES模塊被標(biāo)準(zhǔn)化，使我們最終能夠開始圍繞它們構(gòu)建現(xiàn)代的構(gòu)建工具，如Rollup、Webpack和Parcel?；趯?dǎo)入的捆綁慢慢成為規(guī)范，即使是樣式和圖片等非JS資產(chǎn)也是如此，這極大地簡化了構(gòu)建工具的配置，使它們變得更精簡、更快速，總體上更上一層樓。
• 隨著越來越多的API被標(biāo)準(zhǔn)化，Node和Web標(biāo)準(zhǔn)之間的差距也慢慢縮小。SSR開始成為一種真正的可能性，隨后變成每個標(biāo)準(zhǔn)的應(yīng)用程序都在做的事情，但每次都是某種程度上的定制化設(shè)置。
• 邊緣計算的發(fā)布，使基于JavaScript的服務(wù)器應(yīng)用程序在分發(fā)/響應(yīng)時間方面獲得了SPA的好處（SPA由于是CDN上的靜態(tài)文件，所以以前一般可以更快地開始加載，即使最后完全加載和渲染需要更長時間）。

到這個時代結(jié)束時，仍然存在一些問題。即使我們有了比以前更好的模式，但狀態(tài)管理和反應(yīng)性至今都是棘手的問題。性能情況也正在改善，可仍然存在許多臃腫的SPA?？稍L問性的情況也經(jīng)常是許多開發(fā)團隊事后的想法。但這些變化為下一代框架鋪平了道路。而我想說，我們剛剛進入下一個框架時代。

全棧式框架

就我個人而言，最后一個框架時代真的悄悄來到了我們身邊。我想這是因為我花了4年左右的時間深入到Ember渲染層的內(nèi)部，試圖清理前面提到的，仍然影響它作為第一代框架的技術(shù)債務(wù)。但這也是因為它更加微妙，因為所有這些第三代框架都是圍繞上一代的視圖層框架構(gòu)建的。著名的框架包括：

• Next.js  (React)
• Nuxt.js  (Vue)
• Remix  (React)
• SvelteKit  (Svelte)
• Gatsby  (React)
• Astro  (Any)

這些框架隨著視圖層的成熟和固化而出現(xiàn)。既然我們都同意組件是構(gòu)建框架的核心基礎(chǔ)，那么就有必要開始標(biāo)準(zhǔn)化應(yīng)用程序的其他部分——路由器、構(gòu)建系統(tǒng)、文件夾結(jié)構(gòu)等等。慢慢地，這些元框架開始構(gòu)建第一代一體化解決方案所能提供的相同功能，從各組件內(nèi)部中選擇最佳的模式，并隨著它們的成熟而將它們合并，隨后再更進一步發(fā)展。

到目前為止，SPA一直專注于客戶端。SSR是每個框架都渴望解決的問題，但只是作為一種優(yōu)化，一種渲染的方式，最終會在JS加載完成后被替換。第一代框架中只有一個敢于做得更大，那就是Meteor.js，但它的“同構(gòu)JS”理念從未真正實現(xiàn)。

但隨著應(yīng)用程序的規(guī)模和復(fù)雜性的增長，這個想法被重新審視。我們注意到，將后端和前端組合在一起是非常有用的，這樣你就可以為某些請求隱藏API秘密、在頁面返回時修改header、代理API請求。隨著Node和Deno實現(xiàn)越來越多的web標(biāo)準(zhǔn)，服務(wù)器端JS和客戶端JS之間的差距每年都在縮小，這似乎不再是一個瘋狂的想法。將它與邊緣計算和令人驚嘆的工具相結(jié)合，你就有了不可思議的潛力。

最新一代的框架充分利用了這一潛力，將客戶端和服務(wù)器無縫地融合在一起，我無法強調(diào)這是多么令人驚嘆的感覺。在過去的9個月里，我和SvelteKit一起工作，坐下來的并感嘆:“我們應(yīng)該一直這樣做。”的次數(shù)多得數(shù)不清了。

以下是我最近完成的一些任務(wù)，通過這個設(shè)置，它們變得非常容易:

• 添加服務(wù)器端OAuth到我們的應(yīng)用程序，這樣auth Token永遠不會離開服務(wù)器，同時還有一個API代理，每當(dāng)一個請求發(fā)送到我們的API時添加Token。
• 將某些路由直接代理到我們的CDN，這樣我們就可以托管內(nèi)置在任何其他框架中的靜態(tài)HTML頁面，允許用戶制作他們自己的定制頁面(這是我們?yōu)橐恍┛蛻籼峁┑姆?wù))。
• 當(dāng)我們需要使用需要密鑰的外部服務(wù)時，添加幾個不同的一次性API路由(不需要添加一個全新的路由到我們的API并與后端人員協(xié)調(diào))。
• 將我們對launchdark的使用轉(zhuǎn)移到服務(wù)器端，這樣我們就可以加載更少的JS并降低整體成本。
• 通過后端路由代理我們的Sentry請求，這樣我們就可以捕捉錯誤，否則將由于廣告攔截器導(dǎo)致沒有被報告。

而這僅僅是冰山一角。這種模式真的有很多很酷的地方，其中最大的一點是它如何重振漸進式增強的理念，利用服務(wù)器和客戶端的組合特性，允許客戶端在用戶禁用JavaScript的情況下回退到基本的HTML + HTTP。當(dāng)我開始從事SPA工作時，我已經(jīng)完全放棄了這種做法，認為它們只是未來的趨勢，但我們有可能看到它再次回歸的景象，這真的很酷。

從經(jīng)驗上看，根據(jù)這些新功能，我把這些框架歸類為新一代的框架。以前難以解決或不可能解決的問題現(xiàn)在變得微不足道，只是改變了一點點響應(yīng)處理邏輯。不需要任何額外的配置的情況下，可靠的性能和用戶體驗是信手拈來的。我們不需要建立整個新的服務(wù)，而是能夠根據(jù)需要添加一些額外的端點或中間件。這已經(jīng)改變了生活。

我認為這一代框架也解決了第一代和第二代框架及其用戶之間的一些主要矛盾點。它始于向零配置術(shù)語的轉(zhuǎn)變，但我認為它最終是由第二代框架周圍的衍生的系統(tǒng)所驅(qū)動的，并逐漸變得成熟和穩(wěn)定。第三代框架現(xiàn)在又開始嘗試成為一體化的解決方案，試圖解決我們作為前端開發(fā)者需要解決的所有基本問題，而不僅僅是渲染問題。

現(xiàn)在比以往任何時候都更感覺到社區(qū)在解決困擾SPA的所有問題上是一致的，而且重要的是，他們在一起解決這些問題。

我們下一步該怎么走？

總的來說，我認為JavaScript社區(qū)正朝著正確的方向發(fā)展。

當(dāng)下的開發(fā)者們正在專注研究從頭開始構(gòu)建完整應(yīng)用程序的成熟解決方案，這些解決方案并不局限于 "一個視圖層"。同時，我們終于開始與原生應(yīng)用的SDK在同一起跑線上競爭，提供一個開箱即用的完整工具包。

接下來，我們?nèi)杂泻芏喙ぷ饕?。在SPA領(lǐng)域，可訪問性是一個長期需要解決的問題；在GraphQL之外，我仍然認為數(shù)據(jù)可以被用來實現(xiàn)一些功能（不管你喜歡與否，大部分的網(wǎng)絡(luò)仍然運行在REST上）。但趨勢是正確的，如果我們繼續(xù)朝著共享解決方案的方向發(fā)展，我認為我們可以用比以前更好的方式解決這些問題。

我還對將這些模式更進一步帶到網(wǎng)絡(luò)平臺本身背后的潛力感到興奮。Web組件仍在悄悄地迭代，致力于解決SSR和擺脫全局注冊等問題，這將使它們與這些第三代框架更加兼容。在另一個方向，WebAssembly可以以一種令人難以置信的方式迭代這種模式。想象一下，能夠用任何語言編寫一個全?？蚣?。同類型的Rust、Python、Swift、Java等語言最終可以將前端和后端之間的障礙減少到幾乎為零，只是在你的系統(tǒng)邊緣有一點HTML模板（諷刺的是， 盡管有了更好的用戶體驗 ，但這使我們幾乎繞了一圈）。

如果我們能夠讓開發(fā)者在默認情況下就能用上合適的工具，也許網(wǎng)站的運行狀況會變得更好，用戶體驗會變得更流暢。雖然框架的好壞并不能解決網(wǎng)站的所有問題，但是這將為網(wǎng)站往良好的方向發(fā)展奠定一個基礎(chǔ)，也能讓每個開發(fā)人員都有更多的時間專注于其他事情。