JavaScript 框架的四個時代

作者：Chris

譯者：小智

原文：https://www.pzraq.com/blog/four-eras-of-javascript-frameworks

本文爲譯文，原作者是 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 多個選項中做出選擇，並在有限的資源和緊迫的期限內將它們拼湊在一起時，這就是我們看到的體驗，這也是合理的。一些應用程序非常快速、一致、可靠，使用起來也很有趣，而另一些則令人沮喪、困惑、緩慢和破損。

如果我們能給開發者提供更容易使用的工具，默認地做正確的事情，也許一般的網站會變得更好一些，一般的體驗會更順暢一些。

它不會修復每個網站 -- 沒有多少代碼可以解決糟糕的用戶體驗設計。但它會奠定一個共同的基礎，所以每個網站開始時都會好一點，每個開發人員都有更多的時間專注於其他事情。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/KVN0M05Zi4LkM1FrcPEyhg