JavaScript 框架發展的四個時代，以後的發展方向是什麼？

作者 |  Chris ;  譯者  |  彭慧中;   責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

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

我曾為一家當地的企業從頭到尾開發了一款PHP應用程式，這是一個簡單的CMS網站。後來，他們決定要重新編寫它並增加一些功能。這個專案的經理希望我使用.NET來開發，其中的部分原因是他比較瞭解這項技術，同時他也希望能夠將這個專案做成一個類似本地的應用程式——減少頁面載入的時間。經過一番研究和原型設計，我說服他用網頁的方式做同樣的事情，也就是在這個時候，全新的JS框架出現了。

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

從那時起， 很多事情都發生了變化 ， 許多新的框架出現，舊的框架淘汰。 用JavaScript 在瀏覽器中 構建應用程式的想法，從 少數開發者的嘗試逐漸 變成了 前端領域中 一種標準 的操作方式 。 隨著開發者所構建 的基礎設施 的 改變， 帶來 了 許多 新的可能。

在這段時間裡，不少開發者的很多想法陷入糾結、自相矛盾的迷茫中。我想很多在前端領域工作了一段時間的人可能都有過這樣的經歷，糾結使用哪種JavaScript框架、如何編寫CSS、使用函數語言程式設計還是面向物件程式設計、如何最好地管理狀態、哪種構建系統或工具最靈活、最快速等等。 

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

1. 前世

2. 第一代框架

3. 以元件為中心的檢視層

4. 全棧式框架 (← 這也是我們當前所處的位置)

每個時代都有自己標誌性的特點和亟待解決的矛盾，每一個時代也賦予了我們不同的經驗與教訓，最終讓我們取得了進步。

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

前世

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

也就是說，我不能寫自己沒有經歷過的事情。當我開始編寫前端應用程式時，新一代的框架剛剛開始成熟，像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在任何地方都可以使用，而且更容易長期維護。這推動了Web整個行業的發展。

很明顯，現在JS可以用來編寫更為複雜的應用程式。然而，當時環境下，想要實現這一點還是有些困難的，因為那時的JavaScript並不具備今天的所有功能。就像我說的，所有東西都是全域性性的，你通常需要手動下載並將每個外部庫新增到你的靜態資產資料夾中。當時還沒有NPM，模組也不存在，JS也沒有今天一半的功能。在大多數情況下，每個應用程式都是需要定製的，每個頁面都有不同的外掛設定，每個外掛都有不同的系統來管理狀態和渲染更新。為了解決這些問題，最早的JavaScript框架出現了。

第一代框架

在2000年代末和2010年代初，第一批專門用於編寫完整客戶端應用程式的JS框架開始出現。這個時代的幾個著名的框架是：

• 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

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

這是第一代框架，也正式開啟了未知領域的大門。一方面，這些框架試圖做的事情是非常超前的，很多人認為它們不會真的成功。有許多反對者認為單頁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這樣的構建工具則爭奪如何將這些模組組合成一個可交付的最終產品。

在大多數情況下，這些都是非常通用的類似於任務執行器的工具，可以真正構建任何東西，只是碰巧與HTML、CSS/SASS/LESS等技術結合，基於JavaScript開發出很多適用於Web端的產品。

從這個時代，我們學到了很多東西，收穫了寶貴的經驗，包括：

• URL路由是基礎。沒有它的應用程式往往會出現Bug，開發者需要從一開始就在框架中考慮它。

• 通過模板語言擴充套件HTML是一個強大的抽象層。即使有時它可能有點笨拙，但它可以讓你的UI與狀態保持同步且更容易。

• SPA（單頁面應用）的效能很差，而且Web開發有許多原生應用沒有的額外限制。我們需要通過Web釋出所有程式碼，讓它即時編譯（JIT），然後執行以啟動我們所開發的應用程式，而原生應用程式已經下載和編譯。這是一項艱鉅的任務。

• JavaScript作為一種語言有很多問題，它確實需要改進以使事情變得更好——框架無法單獨做到這一點。

• 我們絕對需要更好的構建工具、模組和包裝來編寫大規模的應用程式。

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

但後來，一顆“小行星”的突然出現，把現有的正規化砸得粉碎，造成了一個小的滅絕事件，把我們推進了下一個時代——這顆“小行星”名為React。

以元件為中心的檢視層

我不認為React發明了元件，但說實話，我不太確定它們最初是從哪裡來的。我知道現有技術至少追溯到.NET中的XAML，並且Web元件也在那時開始作為一種規範開始普及。

現在每個主流的框架都使用了元件。事後看來，它的流行也完全是有道理的——擴充套件HTML，減少長期存在的狀態，將JS業務邏輯直接與模板聯絡起來（無論是JSX還是Handlebars還是Directives）。基於元件的應用程式消除了完成工作所需的大部分抽象概念，並且明顯地簡化了程式碼的生命週期，一切都與元件的生命週期而不是應用程式的生命週期聯絡在一起，這意味著作為一個開發人員，你要考慮的事情要少得多。                                      

然而，當時還有一變化：框架開始把自己吹噓成 "檢視層"，而不是完整的框架。他們不再解決前端應用所需的所有問題，而只是專注於解決渲染問題，其他問題如路由、API通訊和狀態管理，則由使用者自己決定。這個時代著名的框架包括：

• React.js

• Vue.js

• Svelte

• Polymer.js

當然還有很多很多其他的框架。現在回頭看，我認為這是第二代框架中流行的框架，因為它主要做了兩件事情:

1. 它極大地縮小了範圍。這些框架的核心不是試圖解決前端所有問題，而是專注於渲染，關於實現其他功能的許多不同的想法和方向可以在更廣泛的系統中探索。儘管有很多糟糕的解決方案，但也有好的解決方案，這也為下一代從精英中挑選最好的創意鋪平了道路。

2. 這讓開發人員更容易接受。採用一個完整的框架來接管你的整個網頁，意味著你需要重寫大部分應用程式，這對於現有的伺服器端來說是不可能的。使用像React和Vue這樣的框架，你可以把它們中的一小部分放到一個現有的應用程式中，每次只遷移一個小部件或元件，允許開發人員逐步遷移他們現有的程式碼。

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

首先，在工作中關於框架選擇的爭論，不會是我們應該使用哪種框架來開發，或者我們是否應該重寫我們的應用程式。 相反，經常是 "它更快！ "或 "它更小！ "或 "它是你需要的一切！ " 。 還有關於函數語言程式設計和麵向物件程式設計的辯論，很多人把FP作為我們所有問題的解決方案。 平心而論，這些事情都是真的。 僅有檢視層的框架起初更小、更快，而且是你所需要的全部（如果你自己建立或縫合了很多東西）。 當然，函數語言程式設計模式解決了大量困擾JavaScript的問題，而且我認為總體來說，JS因為它們而變得更好。

然而現實是，根本就沒有什麼靈丹妙藥。應用程式仍然變得龐大、臃腫和複雜，狀態仍然難以管理，路由和SSR等基本問題仍然需要解決。對於我們很多人來說，似乎人們想要的是拋棄試圖解決所有這些問題的解決方案，而把這個問題留給讀者。在我的經驗裡，開發團隊中普遍會很高興地接受這種想法，以便快速釋出一個新產品或新功能。然而他們卻沒有足夠的時間來充分開發所有額外的功能。

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

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

就像我說的，當時這讓人非常沮喪，可到最後還是湧現了大量的創新。隨著找出這些框架的最佳實踐，JavaScript的整個系統都發展得非常快，還發生了一些其他的關鍵變化：

• 像Babel這樣的轉譯器成為常態，並有助於使語言現代化。與其等待數年才能實現功能的標準化，不如今天就能使用，而且語言本身也開始以更快、更多的迭代速度增加功能。

• ES模組被標準化，使我們最終能夠開始圍繞它們構建現代的構建工具，如Rollup、Webpack和Parcel。基於匯入的捆綁慢慢成為規範，即使是樣式和圖片等非JS資產也是如此，這極大地簡化了構建工具的配置，使它們變得更精簡、更快速，總體上更上一層樓。

• 隨著越來越多的API被標準化，Node和Web標準之間的差距也慢慢縮小。SSR開始成為一種真正的可能性，隨後變成每個標準的應用程式都在做的事情，但每次都是某種程度上的定製化設定。

• 邊緣計算的釋出，使基於JavaScript的伺服器應用程式在分發/響應時間方面獲得了SPA的好處（SPA由於是CDN上的靜態檔案，所以以前一般可以更快地開始載入，即使最後完全載入和渲染需要更長時間）。

到這個時代結束時，仍然存在一些問題。即使我們有了比以前更好的模式，但狀態管理和反應性至今都是棘手的問題。效能情況也正在改善，可仍然存在許多臃腫的SPA。可訪問性的情況也經常是許多開發團隊事後的想法。但這些變化為下一代框架鋪平了道路。而我想說，我們剛剛進入下一個框架時代。

全棧式框架

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

• Next.js  (React)

• Nuxt.js  (Vue)

• Remix  (React)

• SvelteKit  (Svelte)

• Gatsby  (React)

• Astro  (Any)

這些框架隨著檢視層的成熟和固化而出現。既然我們都同意元件是構建框架的核心基礎，那麼就有必要開始標準化應用程式的其他部分——路由器、構建系統、資料夾結構等等。慢慢地，這些元框架開始構建第一代一體化解決方案所能提供的相同功能，從各元件內部中選擇最佳的模式，並隨著它們的成熟而將它們合併，隨後再更進一步發展。

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

但隨著應用程式的規模和複雜性的增長，這個想法被重新審視。我們注意到，將後端和前端組合在一起是非常有用的，這樣你就可以為某些請求隱藏API祕密、在頁面返回時修改header、代理API請求。隨著Node和Deno實現越來越多的web標準，伺服器端JS和客戶端JS之間的差距每年都在縮小，這似乎不再是一個瘋狂的想法。將它與邊緣計算和令人驚歎的工具相結合，你就有了不可思議的潛力。

最新一代的框架充分利用了這一潛力，將客戶端和伺服器無縫地融合在一起，我無法強調這是多麼令人驚歎的感覺。在過去的9個月裡，我和SvelteKit一起工作，坐下來的並感嘆:“我們應該一直這樣做。”的次數多得數不清了。

以下是我最近完成的一些任務，通過這個設定，它們變得非常容易:

• 新增伺服器端OAuth到我們的應用程式，這樣auth Token永遠不會離開伺服器，同時還有一個API代理，每當一個請求傳送到我們的API時新增Token。

• 將某些路由直接代理到我們的CDN，這樣我們就可以託管內建在任何其他框架中的靜態HTML頁面，允許使用者製作他們自己的定製頁面(這是我們為一些客戶提供的服務)。

• 當我們需要使用需要金鑰的外部服務時，新增幾個不同的一次性API路由(不需要新增一個全新的路由到我們的API並與後端人員協調)。

• 將我們對launchdark的使用轉移到伺服器端，這樣我們就可以載入更少的JS並降低整體成本。

• 通過後端路由代理我們的Sentry請求，這樣我們就可以捕捉錯誤，否則將由於廣告攔截器導致沒有被報告。

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

從經驗上看，根據這些新功能，我把這些框架歸類為新一代的框架。以前難以解決或不可能解決的問題現在變得微不足道，只是改變了一點點響應處理邏輯。不需要任何額外的配置的情況下，可靠的效能和使用者體驗是信手拈來的。我們不需要建立整個新的服務，而是能夠根據需要新增一些額外的端點或中介軟體。這已經改變了生活。

我認為這一代框架也解決了第一代和第二代框架及其使用者之間的一些主要矛盾點。它始於向零配置術語的轉變，但我認為它最終是由第二代框架周圍的衍生的系統所驅動的，並逐漸變得成熟和穩定。第三代框架現在又開始嘗試成為一體化的解決方案，試圖解決我們作為前端開發者需要解決的所有基本問題，而不僅僅是渲染問題。

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

我們下一步該怎麼走？

總的來說，我認為JavaScript社群正朝著正確的方向發展。

當下的開發者們正在專注研究從頭開始構建完整應用程式的成熟解決方案，這些解決方案並不侷限於 "一個檢視層"。同時，我們終於開始與原生應用的SDK在同一起跑線上競爭，提供一個開箱即用的完整工具包。

接下來，我們仍有很多工作要做。在SPA領域，可訪問性是一個長期需要解決的問題；在GraphQL之外，我仍然認為資料可以被用來實現一些功能（不管你喜歡與否，大部分的網路仍然執行在REST上）。但趨勢是正確的，如果我們繼續朝著共享解決方案的方向發展，我認為我們可以用比以前更好的方式解決這些問題。

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

如果我們能夠讓開發者在預設情況下就能用上合適的工具，也許網站的執行狀況會變得更好，使用者體驗會變得更流暢。雖然框架的好壞並不能解決網站的所有問題，但是這將為網站往良好的方向發展奠定一個基礎，也能讓每個開發人員都有更多的時間專注於其他事情。

創作不易， 加個 點贊、在看   支援一下哦！