JavaScript 框架發展的四個時代，以后的發展方向是什么？
早在2012年，我就開始用JavaScript進行編碼。
我曾為一家當地的企業從頭到尾開發了一款PHP應用程序，這是一個簡單的CMS網站。后來，他們決定要重新編寫它并增加一些功能。這個項目的經理希望我使用.NET來開發，其中的部分原因是他比較了解這項技術，同時他也希望能夠將這個項目做成一個類似本地的應用程序——減少頁面加載的時間。經過一番研究和原型設計，我說服他用網頁的方式做同樣的事情，也就是在這個時候，全新的JS框架出現了。
我選擇的第一個框架實際上是Angular 1。彼時，我基于FuelPHP后端開發了一個相當大的應用程序。在功能上，每當重新渲染子路由/出口時，路由器就會閃爍，這一點是我們在開發過程中沒有考慮過的突發情況。后來，有人向我推薦了Ruby on Rails + Ember的解決方案，在試過之后，我覺得效果很好。我喜歡這兩個框架的理念，喜歡構建它們的社區。
從那時起， 很多事情都發生了變化 ， 許多新的框架出現，舊的框架淘汰。 用JavaScript 在瀏覽器中 構建應用程序的想法，從 少數開發者的嘗試逐漸 變成了 前端領域中 一種標準 的操作方式 。 隨著開發者所構建 的基礎設施 的 改變， 帶來 了 許多 新的可能。
在這段時間里，不少開發者的很多想法陷入糾結、自相矛盾的迷茫中。我想很多在前端領域工作了一段時間的人可能都有過這樣的經歷，糾結使用哪種JavaScript框架、如何編寫CSS、使用函數式編程還是面向對象編程、如何最好地管理狀態、哪種構建系統或工具最靈活、最快速等等。
回顧過去，我覺得很有趣，因為我們經常為小的錯誤爭論不休，而忽略了更有意義的事情，當然這也是“事后諸葛亮”了。所以我想做一個回顧，總結過去幾十年的JavaScript開發，看看我們已經走了多遠。我認為我們可以把它粗略地分為四個主要時代：
- 前世
- 第一代框架
- 以組件為中心的視圖層
- 全棧式框架 (← 這也是我們當前所處的位置)
每個時代都有自己標志性的特點和亟待解決的矛盾，每一個時代也賦予了我們不同的經驗與教訓，最終讓我們取得了進步。
關于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
當然還有很多很多其他的框架。現在回頭看，我認為這是第二代框架中流行的框架，因為它主要做了兩件事情:
- 它極大地縮小了范圍。這些框架的核心不是試圖解決前端所有問題，而是專注于渲染，關于實現其他功能的許多不同的想法和方向可以在更廣泛的系統中探索。盡管有很多糟糕的解決方案，但也有好的解決方案，這也為下一代從精英中挑選最好的創意鋪平了道路。
- 這讓開發人員更容易接受。采用一個完整的框架來接管你的整個網頁，意味著你需要重寫大部分應用程序，這對于現有的服務器端來說是不可能的。使用像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模板（諷刺的是， 盡管有了更好的用戶體驗 ，但這使我們幾乎繞了一圈）。
如果我們能夠讓開發者在默認情況下就能用上合適的工具，也許網站的運行狀況會變得更好，用戶體驗會變得更流暢。雖然框架的好壞并不能解決網站的所有問題，但是這將為網站往良好的方向發展奠定一個基礎，也能讓每個開發人員都有更多的時間專注于其他事情。
