早在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框架開始出現。這個時代的幾個有名的框架：
當然，還有很多其他的，可能還有一些在某些圈子裡更大的。這些是我記得的，主要是因為小明用它們來編碼，而且它們比較受歡迎。
這是一個世代框架，正在進入未知的領域。一方面，他們試圖做的事情是非常雄心勃勃的，而且很多人認為它永遠不會真正成功。
有許多反對者認為單頁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應用的東西。
然而，我們從這個時代學到了很多東西:
總的來說，這個時代是富有成效的。儘管有缺點，但隨著應用程式的複雜性增加，將客戶端與API分離的好處是巨大的，而且在許多情況下，所產生的使用者體驗是驚人的。如無特殊情況，這個時代可能會繼續下去，我們到現在還在迭代MV*風格的想法。
但後來一顆小行星突然出現，把現有的範式砸得四分五裂，造成了一次小規模的滅絕事件，把我們推進了下一個時代--這顆小行星名叫React。
我不認為React發明了元件，但說實話，我也不太清楚它們最早來自哪裡。但至少可以追溯到.NET中的XAML，而 web 元件也在那時開始作為一種規範發展。最終它並不重要——一旦這個想法出現了，每個主要的框架都很快地採用了它。
事後看來，這完全是有道理的--擴展HTML，減少長期存在的狀態，將JS業務邏輯直接與模板綁定（無論是JSX還是Handlebars還是Directives）。
基於元件的應用程式消除了完成工作所需的大部分抽象概念，並且明顯地簡化了程式碼的生命週期--一切都與元件的生命週期而不是應用程式的生命週期聯繫在一起，這意味著作為一個開發人員，你要考慮的事情要少得多。
然而，當時還有一個轉變：框架開始把自己吹噓成 "視圖層"，而不是成熟的框架。他們不再解決前端應用所需的所有問題，而是專注於解決渲染問題。
其他問題，如路由、API通訊和狀態管理，則由使用者自行決定。這個時代著名的框架有：
對我們中的許多人來說，人們想要的似乎是放棄試圖解決所有這些問題的解決方案，而換成一個讓讀者自己去解決的解決方案。
根據我的經驗，這也是工程小組的普遍做法，他們會很高興地接受這種改變，以便交付一個新的產品或功能，然後又不資助完全開發所有這些額外功能所需的時間。
其結果是圍繞這些視圖層建立的自製框架，而這些框架本身是臃腫的、複雜的，而且非常難以操作。
我認為人們在使用SPA時遇到的許多問題都來自於這種分散的生態系統，而這種生態系統恰恰是在SPA使用爆炸性增長的時候出現的。我仍然經常遇到一個新的網站，它不能正確地做路由或很好地處理其他小細節，這絕對是令人沮喪的。
但另一方面，現有的第一代全服務框架在解決這些問題方面也做得不是很好。部分原因是由於大量的技術債包袱。第一代框架是在ES6之前，在模組之前，在Babel和Webpack之前，在我們弄清楚許多事情之前建立的。
迭代進化是非常困難的，而且完全重寫它們，就像Angular對Angular 2所做的那樣，扼殺了他們社區的發展勢頭。
因此，當涉及到JavaScript框架時，開發人員處於兩難境地--要么選擇一個開始顯示其年齡的一體化解決方案，要么跳入自由競爭中，DIY一半的框架，希望得到最好的結果。
當時這讓人非常沮喪，但最後還是產生了大量的創新。隨著這些框架找出它們的最佳實踐，JavaScript生態系統的發展非常迅速，也發生了一些其他的關鍵變化。
在這個時代結束的時候，一些問題仍然存在。狀態管理和回應性仍然是（現在也是）棘手的問題，儘管我們有比以前更好的模式。
性能仍然是一個困難的問題，儘管情況正在改善，但仍然有很多很多臃腫的SPA在那裡。
可訪問性的情況也有所改善，但對於許多工程機構來說，它仍然經常是事後的想法。但這些變化為下一代框架鋪平了道路，我想說的是，我們現在正在進入下一代框架。
就我個人而言，上一個框架時代真的悄悄來臨了。我想這是因為我在過去4年左右的時間裡深入到Ember渲染層的內部，試圖解決前面提到的影響它作為第一代框架的技術債（仍然）。但這也是因為它更加微妙，因為所有這些第三代框架都是圍繞著上一代的視圖層框架建立的。這些框架包括：
這些框架是隨著視圖層的成熟和鞏固而開始的。既然我們都同意元件是建立在核心基礎之上的，那麼開始標準化應用程式的其他部分——路由器、建置系統、資料夾結構等，就很有意義了。
慢慢地，這些元框架開始建立起與第一代多合一解決方案開箱即用的相同功能，從各自的生態系統中挑選最佳模式，並隨著它們的成熟而將其納入。
然後他們又進一步。
在這之前，SPA一直只專注於客戶端。 SSR是每個框架都希望解決的問題，但只是作為一種優化，一種獲得渲染的方式，最終會在數兆位元組的JS最終加載完畢後被取代。
只有一個第一代框架敢於想得更遠，即Meteor.js，但它同構JS的想法從未真正實現。
但隨著應用程式的規模和複雜性的增加，這個想法被重新審視。
我們注意到，將後端和前端搭配在一起實際上是非常有用的，這樣你就可以做一些事情，例如為某些請求隱藏API秘密，在返回頁面時修改頭文件，代理API請求。隨著Node和Deno實現了越來越多的 web 標準，伺服器端JS和客戶端JS之間的差距每年都在縮小，它開始看起來畢竟不是一個瘋狂的想法。將其與 edge-computing和驚人的工具結合起來，就會有一些令人難以置信的潛力。
最新一代的框架充分利用了這種潛力，將客戶端和伺服器無縫地融合在一起，我無法強調這種感覺有多麼令人驚訝。在過去9個月與SvelteKit的合作中，我不知道有多少次坐下來對自己說："這就是我們應該一直做的事情。"
以下是我最近遇到的一些任務，透過這種設置，這些任務變得異常簡單。
而這只是冰山一角。這種模式真的有很多很酷的地方，其中最大的一點是它如何重振漸進式增強的理念，利用伺服器和客戶端的組合特性，允許客戶端在用戶禁用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多個選項中做出選擇，並在有限的資源和緊迫的期限內將它們拼湊在一起時，這就是我們看到的體驗，這也是合理的。有些應用程式非常快速、一致、可靠，使用起來也很有趣，而有些則令人沮喪、困惑、緩慢和破損。
如果我們能提供開發者更容易使用的工具，預設做正確的事情，也許一般的網站會變得更好一些，一般的體驗會更順暢一些。
它不會修復每個網站--沒有多少程式碼可以解決糟糕的使用者體驗設計。但它會奠定一個共同的基礎，所以每個網站開始時都會好一點，每個開發人員都有更多的時間專注於其他事情。
以上是JavaScript框架的四個時代的詳細內容。更多資訊請關注PHP中文網其他相關文章！
