聊一聊 JavaScript 框架的 4 個時代
本文為譯文，原作者是 Chris ,它是Bitski的首席前端工程師，Ember.js核心團(tuán)隊(duì)成員，曾任LinkedIn、Addepar、Ticketfly（現(xiàn)為EventBrite）的前端工程師，反正是個厲害大佬就是了，本文的第一人稱都指是的該大佬。
早在2012年，我開始主要用JavaScript進(jìn)行編碼。我曾為一家本地企業(yè)從頭到尾做了一個PHP應(yīng)用，一個基本的CMS和網(wǎng)站，公司決定要重寫它并增加一些功能。
項(xiàng)目經(jīng)理希望我使用.NET，部分原因是這是他所知道的，但也因?yàn)樗Ｍ@個應(yīng)用感覺像一個本地應(yīng)用程序--沒有頁面刷新或操作動作長時間等待。經(jīng)過一番研究和原型設(shè)計(jì)，我說服了經(jīng)理，可以使用當(dāng)時剛開始出現(xiàn)的全新JS框架，它能做到這些事項(xiàng)。
我選擇的第一個框架實(shí)際上是 Angular 1。在我遇到路由器的一些問題之前，已經(jīng)建立了一個相當(dāng)大的應(yīng)用程序，并使用FuelPHP的后端--每當(dāng)重新渲染子路由/出口時，它就會閃爍，而且真的感覺它在設(shè)計(jì)時沒有考慮到這種場景。
后面，有人向我推薦了Ruby on Rails + Ember，在試過之后，覺得效果很好。我也喜歡這兩個框架的理念，喜歡這些社區(qū)生態(tài)，而且與當(dāng)時的替代方案相比，總的來說，它非常有成效。
從那時起，很多事情都發(fā)生了變化--框架層出不窮，并且有了很大的發(fā)展。去無可以在瀏覽器中用JavaScript構(gòu)建應(yīng)用程序的想法，從某種程度上的邊緣變成了一種標(biāo)準(zhǔn)做法。我們構(gòu)建的基礎(chǔ)設(shè)施已經(jīng)完全改變，實(shí)現(xiàn)了一系列新的可能性。
在這段時間里，各種想法之間也有相當(dāng)多的競爭和沖突。使用哪種JavaScript框架，如何編寫CSS，函數(shù)式編程與面向?qū)ο缶幊蹋绾巫詈玫毓芾頎顟B(tài)，哪種構(gòu)建系統(tǒng)或工具最靈活、最快速，等等。回顧過去，這些覺得很有趣，我們經(jīng)常爭論的是錯誤的事情，而忽略了一些前瞻性，當(dāng)然，這也是事后諸葛亮。
所以我想做一個回顧，回顧過去幾十年的JavaScript開發(fā)，看看我們已經(jīng)走了多遠(yuǎn)。我們可以把它大致分為四個主要時代。：
原始年代 第一個框架 以組件為中心的視圖層 全棧式框架
每一個時代都有自己的主題和核心矛盾，同時也都想到吸取關(guān)鍵教訓(xùn)，并穩(wěn)步前進(jìn)。
今天，爭論仍在繼續(xù)。web 是否變得過于臃腫？一般的網(wǎng)站真的需要用React編寫嗎？我們甚至應(yīng)該使用JavaScript嗎？當(dāng)然，當(dāng)前也不能代表未來，未來現(xiàn)有框架很大可能也會被替換，但是，也是從現(xiàn)有的一些觀點(diǎn)出來，幫助我們向前邁進(jìn)。
原始年代
JavaScript是在1995年首次發(fā)布的。就像我上面提到的，我是在2012年開始寫JS的，差不多20年后，接近我稱之為第一框架的時代的開始。你可以認(rèn)為，我在這里可能會掩蓋很多歷史，而且這個時代可能會被分解成許多子時代，每個時代都有自己的模式、庫和構(gòu)建工具等等。
也就是說，我不能寫我沒有經(jīng)歷過的事情。當(dāng)我開始編寫前端應(yīng)用程序時，新一代的框架剛剛開始走向成熟。Angular.js、Ember.js、Backbone，等等。
在這之前，最先進(jìn)的技術(shù)是jQuery和MooTools等庫。這些庫在它們的時代非常重要--它們幫助平滑了瀏覽器實(shí)現(xiàn)JavaScript的方式之間的差異，這些差異是非常重要的。
例如，IE 實(shí)現(xiàn)事件的方式與Netscape完全不同--冒泡事件與捕獲事件。這就是為什么我們今天的標(biāo)準(zhǔn)最終實(shí)現(xiàn)了這兩種方式，但在這之前，我們需要使用庫來編寫能在兩種瀏覽器上使用的代碼。
這些庫主要用于制作小型的、獨(dú)立的用戶界面組件。大多數(shù)應(yīng)用程序的業(yè)務(wù)邏輯仍然是通過表單和標(biāo)準(zhǔn)的HTTP請求進(jìn)行的--在服務(wù)器上渲染HTML并將其提供給客戶端。
在這個時代也沒有什么構(gòu)建工具可言，至少我知道的是。當(dāng)時的JavaScript還沒有模塊（至少沒有標(biāo)準(zhǔn)的模塊），所以沒有任何辦法導(dǎo)入代碼。所有的東西都是全局性的，要組織好這些東西是非常困難的。
在這種環(huán)境下，可以理解的是，JS通常被視為一種玩具語言，而不是你用它來寫一個完整的應(yīng)用程序。那時我們最常做的事情是加入 jQuery，為一些UI小部件編寫一些腳本，然后就可以了。
隨著時間的推移和XHR的引入和普及，人們開始把他們的UI流程的一部分放到一個頁面中，特別是對于需要在客戶端和服務(wù)器之間進(jìn)行多次來回交互的復(fù)雜流程，但應(yīng)用程序的大部分內(nèi)容還是留在服務(wù)器上。
這與移動應(yīng)用開始出現(xiàn)時的情況形成了鮮明的對比。從一開始，iOS和Android上的移動應(yīng)用就是用Objective C和Java等嚴(yán)肅語言?編寫的完整應(yīng)用。此外，它們是完全由API驅(qū)動的--所有的UI邏輯都在設(shè)備上，與服務(wù)器的通信純粹是數(shù)據(jù)格式的。這導(dǎo)致了更好的用戶體驗(yàn)和移動應(yīng)用的爆炸性增長，直接導(dǎo)致了我們今天關(guān)于移動和 web 哪個更好的爭論。
用JavaScript做這一切，起初被認(rèn)為是可笑的。但隨著時間的推移，應(yīng)用程序開始變得更加雄心勃勃。社交網(wǎng)絡(luò)增加了聊天、DM和其他實(shí)時功能，Gmail和Google Docs表明可以在瀏覽器中編寫相當(dāng)于桌面應(yīng)用，越來越多的公司轉(zhuǎn)向編寫 web應(yīng)用，因?yàn)?web 在任何地方都可以工作，而且更容易長期維護(hù)。這推動了整個行業(yè)的發(fā)展--現(xiàn)在很明顯，JS可以用來編寫非簡單的應(yīng)用程序。
當(dāng)時的JavaScript還沒有今天的所有功能，所有的東西都是全局的，通常需要手動下載并將每個外部庫添加到靜態(tài)文件夾中。當(dāng)時還沒有NPM，模塊也不存在，JS也沒有今天一半的功能。
在大多數(shù)情況下，每個應(yīng)用程序都是定制的，每個頁面都有不同的插件設(shè)置，每個插件都有不同的系統(tǒng)來管理狀態(tài)和渲染更新。為了解決這些問題，最早的JavaScript框架開始出現(xiàn)了。
第一個框架
大約在2000年代末和2010年代初，第一批專門用于編寫完整客戶端應(yīng)用程序的JS框架開始出現(xiàn)。這個時代的幾個有名的框架：
Backbone.js Angular 1 Knockout.js SproutCore Ember.js Meteor.js
當(dāng)然，還有很多其他的，可能還有一些在某些圈子里更大的。這些是我記得的，主要是因?yàn)樾∶饔盟鼈儊砭幋a，而且它們比較受歡迎。
這是一代框架，正在進(jìn)入未知的領(lǐng)域。一方面，他們試圖做的事情是非常雄心勃勃的，而且很多人認(rèn)為它永遠(yuǎn)不會真正成功。
有許多反對者認(rèn)為單頁JS應(yīng)用程序（SPA）從根本上來說更糟糕，而且在很多方面他們是對的--客戶端渲染意味著機(jī)器人不能輕易抓取這些頁面，而且用戶甚至需要等待幾秒鐘才能開始繪制應(yīng)用程序。很多這些應(yīng)用程序都是無障礙的噩夢，如果關(guān)閉了JavaScript，它們就根本無法工作。
另一方面，我們沒有在JS中構(gòu)建完整應(yīng)用程序的經(jīng)驗(yàn)，因此有大量關(guān)于最佳方法的競爭性想法。大多數(shù)框架都試圖模仿其他平臺上的流行做法，所以幾乎所有的框架最后都是Model-View-*的某種迭代。Model-View-Controller，Model-View-Producer，Model-View-ViewModel等等。但從長遠(yuǎn)來看，這些都不是真正意義上的成功--它們并不特別直觀，而且很快就變得非常復(fù)雜。
這也是一個我們真正開始嘗試如何編譯JavaScript應(yīng)用程序的時代。Node.js在2009年發(fā)布，NPM在2010年緊隨其后，為（服務(wù)器端的）JavaScript引入了包。
CommonJS和AMD爭奪如何最好地定義JS模塊，而像Grunt、Gulp和Broccoli這樣的構(gòu)建工具則爭奪如何將這些模塊組合成一個可交付的最終產(chǎn)品。
在大多數(shù)情況下，這些都是非常通用的任務(wù)運(yùn)行器式的工具，它們真的可以構(gòu)建任何東西，只是碰巧要構(gòu)建JavaScript--還有HTML、CSS/SASS/LESS，以及其他許多進(jìn)入web應(yīng)用的東西。
然而，我們從這個時代學(xué)到了很多東西:
基于URL的路由是基礎(chǔ)。沒有這種路由的應(yīng)用程序會破壞 web，因此需要在框架中從一開始就考慮到這一點(diǎn)。
通過模板化語言擴(kuò)展HTML是一個強(qiáng)大的抽象層。即使它有時會有點(diǎn)笨拙，但它使用戶界面與狀態(tài)保持同步變得更加容易。
SPA的性能很差，而且web有許多原生應(yīng)用所沒有的額外限制。我們需要通過 web 發(fā)布所有的代碼，讓它JIT，然后運(yùn)行來啟動我們的應(yīng)用程序，而本地應(yīng)用程序已經(jīng)下載和編譯，這是一項(xiàng)艱巨的任務(wù)。
作為一種語言，JavaScript有很多問題，它確實(shí)需要被改進(jìn)，以使事情變得更好--框架無法單獨(dú)做到這一點(diǎn)。
我們絕對需要更好的構(gòu)建工具、模塊和包裝，以便大規(guī)模地編寫應(yīng)用程序。
總的來說，這個時代是富有成效的。盡管有缺點(diǎn)，但隨著應(yīng)用程序的復(fù)雜性增加，將客戶端與API分離的好處是巨大的，而且在許多情況下，所產(chǎn)生的用戶體驗(yàn)是驚人的。如無特殊情況，這個時代可能會繼續(xù)下去，我們到現(xiàn)在還在迭代MV*風(fēng)格的想法。
但后來一顆小行星突然出現(xiàn)，把現(xiàn)有的范式砸得四分五裂，造成了一次小規(guī)模的滅絕事件，把我們推進(jìn)了下一個時代--這顆小行星名叫React。
以組件為中心的視圖層
我不認(rèn)為React發(fā)明了組件，但說實(shí)話，我也不太清楚它們最早來自哪里。但至少可以追溯到.NET中的XAML，而 web 組件也在那時開始作為一種規(guī)范發(fā)展。最終它并不重要——一旦這個想法出現(xiàn)了，每個主要的框架都很快地采用了它。
事后看來，這完全是有道理的--擴(kuò)展HTML，減少長期存在的狀態(tài)，將JS業(yè)務(wù)邏輯直接與模板綁定（無論是JSX還是Handlebars還是Directives）。
基于組件的應(yīng)用程序消除了完成工作所需的大部分抽象概念，并且明顯地簡化了代碼的生命周期--一切都與組件的生命周期而不是應(yīng)用程序的生命周期聯(lián)系在一起，這意味著作為一個開發(fā)人員，你要考慮的事情要少得多。
然而，當(dāng)時還有一個轉(zhuǎn)變：框架開始把自己吹噓成 "視圖層"，而不是成熟的框架。他們不再解決前端應(yīng)用所需的所有問題，而是專注于解決渲染問題。
其他問題，如路由、API通信和狀態(tài)管理，則由用戶自己決定。這個時代著名的框架有：
React.js Vue.js Svelte Polymer.js
還有很多其他的。現(xiàn)在回過頭來看，我認(rèn)為這是第二代框架的一個流行框架，因?yàn)樗_實(shí)做了兩件主要的事情。
它極大地縮小了范圍。該框架的核心不是試圖在前期解決所有這些問題，而是專注于渲染，許多不同的想法和方向可以在更廣泛的生態(tài)系統(tǒng)中探索其他功能。有很多糟糕的解決方案，但也有很好的解決方案，為下一代從精華中挑選最好的想法鋪平了道路。
這讓我們更容易接受它們。采用一個完整的框架來接管你的整個網(wǎng)頁意味著重寫你的大部分應(yīng)用程序，這對于現(xiàn)有的服務(wù)器端巨石來說是不可能的。使用像React和Vue這樣的框架，你可以一次一個小部件或組件地將它們的一小部分放入現(xiàn)有的應(yīng)用程序中，允許開發(fā)人員增量地遷移他們現(xiàn)有的代碼。
這兩個因素導(dǎo)致第二代框架迅速發(fā)展，使第一代框架黯然失色，從遠(yuǎn)處看，這一切似乎很有意義，是一種合理的演變。但在當(dāng)時身處其中，是相當(dāng)令人沮喪的經(jīng)歷。
首先，當(dāng)我們在工作中爭論使用哪種框架，或者是否應(yīng)該重寫我們的應(yīng)用程序時，并不經(jīng)常遇到這樣的框架。相反，很多時候是 "它更快！"或 "它更小！"或 "它是你所需要的一切！"。
還有關(guān)于函數(shù)式編程和面向?qū)ο缶幊痰霓q論，很多人把FP作為我們所有問題的解決方案。公平地說，這些事情都是真的。僅有視圖層的框架更小（起初）、更快（起初），而且是你所需要的全部（如果你自己建立或縫合了很多東西）。
當(dāng)然，函數(shù)式編程模式解決了大量困擾JavaScript的問題，我認(rèn)為平均而言，JS因?yàn)樗鼈兌兊酶谩?/p>
然而，現(xiàn)實(shí)是根本就沒有什么靈丹妙藥。應(yīng)用程序仍然龐大、臃腫和復(fù)雜，狀態(tài)仍然難以管理，路由和SSR等基本問題仍然需要解決。
對于我們中的很多人來說，人們想要的似乎是放棄試圖解決所有這些問題的解決方案，而換成一個讓讀者自己去解決的解決方案。
根據(jù)我的經(jīng)驗(yàn)，這也是工程小組的普遍做法，他們會很高興地接受這種改變，以便交付一個新的產(chǎn)品或功能，然后又不資助完全開發(fā)所有這些額外功能所需的時間。
其結(jié)果是圍繞這些視圖層建立的自制框架，而這些框架本身是臃腫的、復(fù)雜的，而且非常難以操作。
我認(rèn)為人們在使用SPA時遇到的許多問題都來自于這種分散的生態(tài)系統(tǒng)，而這種生態(tài)系統(tǒng)恰恰是在SPA使用爆炸性增長的時候出現(xiàn)的。我仍然經(jīng)常遇到一個新的網(wǎng)站，它不能正確地做路由或很好地處理其他小細(xì)節(jié)，這絕對是令人沮喪的。
但另一方面，現(xiàn)有的第一代全服務(wù)框架在解決這些問題方面也做得不是很好。部分原因是由于大量的技術(shù)債務(wù)包袱。第一代框架是在ES6之前，在模塊之前，在Babel和Webpack之前，在我們弄清楚許多事情之前建立的。
迭代進(jìn)化是非常困難的，而且完全重寫它們，就像Angular對Angular 2所做的那樣，扼殺了他們社區(qū)的發(fā)展勢頭。
因此，當(dāng)涉及到JavaScript框架時，開發(fā)人員處于兩難境地--要么選擇一個開始顯示其年齡的一體化解決方案，要么跳入自由競爭中，DIY一半的框架，希望得到最好的結(jié)果。
當(dāng)時這讓人非常沮喪，但最后還是產(chǎn)生了大量的創(chuàng)新。隨著這些框架找出它們的最佳實(shí)踐，JavaScript生態(tài)系統(tǒng)的發(fā)展非常迅速，還發(fā)生了一些其他的關(guān)鍵變化。
像 Babel 這樣的轉(zhuǎn)譯器成為常態(tài)，并有助于使語言現(xiàn)代化。與其等待多年的功能標(biāo)準(zhǔn)化，不如今天就能使用，而語言本身也開始以更快、更迭代的速度增加功能。
ES模塊被標(biāo)準(zhǔn)化，使我們最終開始圍繞它們構(gòu)建現(xiàn)代構(gòu)建工具，如Rollup、Webpack和Parcel。基于導(dǎo)入的 bundling 慢慢成為規(guī)范，即使是樣式和圖片等非JS資源也是如此，這極大地簡化了構(gòu)建工具的配置，使它們變得更精簡、更快速、更全面。
隨著越來越多的API被標(biāo)準(zhǔn)化，Node和 web 標(biāo)準(zhǔn)之間的差距也在緩慢但穩(wěn)步地縮小。SSR開始成為一種真正的可能性，然后是每個嚴(yán)肅的應(yīng)用程序都在做的事情，但每次都是一種定制的設(shè)置。
釋放了Edge Computing，為基于JavaScript的服務(wù)器應(yīng)用程序提供了SPA在分布/響應(yīng)時間方面的好處（Spas以前由于在CDN上是靜態(tài)文件，因此通常可以更快地開始加載加載，即使它們花了更長的時間才能完全加載并在結(jié)束）。
在這個時代結(jié)束的時候，一些問題仍然存在。狀態(tài)管理和響應(yīng)性仍然是（現(xiàn)在也是）棘手的問題，盡管我們有比以前更好的模式。
性能仍然是一個困難的問題，盡管情況正在改善，但仍然有很多很多臃腫的SPA在那里。
可訪問性的情況也有所改善，但對于許多工程機(jī)構(gòu)來說，它仍然經(jīng)常是一個事后的想法。但這些變化為下一代框架鋪平了道路，我想說的是，我們現(xiàn)在正在進(jìn)入下一代框架。
全棧式框架
就我個人而言，上一個框架時代真的悄悄來臨了。我想這是因?yàn)槲以谶^去4年左右的時間里深入到Ember渲染層的內(nèi)部，試圖解決前面提到的影響它作為第一代框架的技術(shù)債務(wù)（仍然）。但這也是因?yàn)樗游⒚睿驗(yàn)樗羞@些第三代框架都是圍繞上一代的視圖層框架建立的。這些框架包括：
Next.js (React) Nuxt.js (Vue) Remix (React) SvelteKit (Svelte) Gatsby (React) Astro (Any)
這些框架是隨著視圖層的成熟和鞏固而開始的。既然我們都同意組件是建立在核心基礎(chǔ)之上的，那么開始標(biāo)準(zhǔn)化應(yīng)用程序的其他部分--路由器、構(gòu)建系統(tǒng)、文件夾結(jié)構(gòu)等，就很有意義了。
慢慢地，這些元框架開始建立起與第一代多合一解決方案開箱即用的相同功能，從各自的生態(tài)系統(tǒng)中挑選最佳模式，并隨著它們的成熟而將其納入。
然后他們又進(jìn)一步。
在這之前，SPA一直只專注于客戶端。SSR是每個框架都希望解決的問題，但只是作為一種優(yōu)化，一種獲得渲染的方式，最終會在數(shù)兆字節(jié)的JS最終加載完畢后被取代。
只有一個第一代框架敢于想得更遠(yuǎn)，即Meteor.js，但它同構(gòu)JS的想法從未真正實(shí)現(xiàn)。
但隨著應(yīng)用程序的規(guī)模和復(fù)雜性的增加，這個想法被重新審視。
我們注意到，將后端和前端搭配在一起實(shí)際上是非常有用的，這樣你就可以做一些事情，比如為某些請求隱藏API秘密，在返回頁面時修改頭文件，代理API請求。隨著Node和Deno實(shí)現(xiàn)了越來越多的 web 標(biāo)準(zhǔn)，服務(wù)器端JS和客戶端JS之間的差距每年都在縮小，它開始看起來畢竟不是一個瘋狂的想法。將其與 edge-computing和驚人的工具結(jié)合起來，就會有一些令人難以置信的潛力。
最新一代的框架充分利用了這種潛力，將客戶端和服務(wù)器無縫地融合在一起，我無法強(qiáng)調(diào)這種感覺有多么令人驚訝。在過去9個月與SvelteKit的合作中，我不知道有多少次坐下來對自己說："這就是我們應(yīng)該一直做的事情。"
以下是我最近遇到的一些任務(wù)，通過這種設(shè)置，這些任務(wù)變得異常簡單。
將服務(wù)器端的OAuth添加到我們的應(yīng)用程序中，這樣認(rèn)證令牌就不會離開服務(wù)器，同時還有一個API代理，在向我們的API發(fā)送請求時添加令牌。
將某些路由直接代理到我們的CDN，這樣我們就可以托管在任何其他框架中構(gòu)建的靜態(tài)HTML頁面，允許用戶制作自己的定制頁面（我們?yōu)橐恍┛蛻籼峁┑姆?wù)）。
當(dāng)我們需要使用一個需要密匙的外部服務(wù)時，添加幾個不同的一次性API路由（不需要為我們的API添加一個全新的路由并與后端人員協(xié)調(diào)）。
將我們對LaunchDarkly的使用轉(zhuǎn)移到服務(wù)器端，這樣我們就可以加載更少的JS，從而降低整體成本。
通過后端路由代理我們的Sentry請求，這樣我們就可以捕捉到由于廣告屏蔽器而未被報(bào)告的錯誤。
而這僅僅是冰山一角。這種模式真的有很多很酷的地方，其中最大的一點(diǎn)是它如何重振漸進(jìn)式增強(qiáng)的理念，利用服務(wù)器和客戶端的組合特性，允許客戶端在用戶禁用JavaScript的情況下回退到基本的HTML + HTTP。
當(dāng)我開始從事SPA工作時，我自己已經(jīng)完全放棄了這種做法，認(rèn)為它們是未來的趨勢，但我們有可能看到它卷土重來的世界，這真的很酷。
這些是新的功能，從經(jīng)驗(yàn)上看，我把這些框架歸為新一代的框架。以前難以解決或不可能解決的問題現(xiàn)在變得微不足道，只需改變一點(diǎn)點(diǎn)的響應(yīng)處理邏輯。
可靠的性能和用戶體驗(yàn)是開箱即用的，不需要任何額外的配置。我們不需要建立整個新的服務(wù)，而是能夠根據(jù)需要添加一些額外的端點(diǎn)或中間件。這已經(jīng)改變了生活。
我認(rèn)為這一代也解決了第一代和第二代框架及其用戶之間的一些主要矛盾點(diǎn)。
它始于向零配置術(shù)語的轉(zhuǎn)變，但我認(rèn)為它最終是由圍繞第二代框架的生態(tài)系統(tǒng)的成熟和穩(wěn)定所驅(qū)動的，這也是一種文化轉(zhuǎn)變。
第三代框架現(xiàn)在正試圖再次成為一體化的解決方案，試圖解決我們作為前端開發(fā)者需要解決的所有基本問題--不僅僅是渲染。
現(xiàn)在比以往任何時候都感覺到社區(qū)在解決所有困擾SPA的許多問題方面是一致的，而且重要的是，共同解決了這些問題。
我們接下來要去哪里？
總的來說，我認(rèn)為JavaScript社區(qū)正朝著正確的方向發(fā)展。我們終于開發(fā)出了成熟的解決方案，可以從頭開始構(gòu)建完整的應(yīng)用程序，這些解決方案并不是 "僅僅是一個視圖層"。
我們終于開始與原生應(yīng)用的SDK在同一起跑線上競爭，提供一個開箱即用的完整工具包。
我們在這方面仍有很多工作要做。在SPA領(lǐng)域，可訪問性長期以來一直是一個事后的想法，而在GraphQL之外，我仍然認(rèn)為 data story 可以使用一些工作（不管你喜歡與否，大部分的 web 仍然運(yùn)行在REST上）。
但趨勢是正確的，如果我們繼續(xù)朝著共享解決方案的方向發(fā)展，我認(rèn)為我們可以用比以前更好的方式解決這些問題。
我還對將這些模式進(jìn)一步提升到 web平臺本身背后的潛力感到興奮。Web組件仍在悄悄地迭代，致力于解決SSR和擺脫全局注冊等問題，這將使它們與這些第三代框架更加兼容。
在另一個方向，WebAssembly可以以一種令人難以置信的方式迭代這種模式。想象一下，能夠用任何語言編寫一個全棧框架。
同構(gòu)的Rust、Python、Swift、Java等語言最終可以將前臺和后臺之間的障礙減少到幾乎為零--只是在你的系統(tǒng)邊緣有一點(diǎn)HTML模板（這諷刺地使我們幾乎繞了一圈，盡管有更好的用戶體驗(yàn)）。
我在這里最大的希望是，我們正在走過碎片化的時代，走過每天都有新的JS框架的時代。自由和靈活孕育了創(chuàng)新，但它們也導(dǎo)致了 web 體驗(yàn)的混亂、不連貫，而且常常是根本性的破壞。
當(dāng)開發(fā)者不得不在50多個選項(xiàng)中做出選擇，并在有限的資源和緊迫的期限內(nèi)將它們拼湊在一起時，這就是我們看到的體驗(yàn)，這也是合理的。一些應(yīng)用程序非常快速、一致、可靠，使用起來也很有趣，而另一些則令人沮喪、困惑、緩慢和破損。
如果我們能給開發(fā)者提供更容易使用的工具，默認(rèn)地做正確的事情，也許一般的網(wǎng)站會變得更好一些，一般的體驗(yàn)會更順暢一些。
它不會修復(fù)每個網(wǎng)站--沒有多少代碼可以解決糟糕的用戶體驗(yàn)設(shè)計(jì)。但它會奠定一個共同的基礎(chǔ)，所以每個網(wǎng)站開始時都會好一點(diǎn)，每個開發(fā)人員都有更多的時間專注于其他事情。
作者：Chris 譯者：小智 來源：pzuraq 原文：https://www.pzraq.com/blog/four-eras-of-javascript-frameworks