🔧 阿川の電商水電行
我想，三年過去了，我的 JavaScript 框架回顧文章應該可以算是年度例行活動了。 2025 年的文章寫起來很艱難，因為一個令人清醒的現實是，我們嘗試的許多想法最終都無法實現。但有時候，我們都需要認清現實，重新調整期望。
今年，這種情緒依然有所延續。一些原本不該獲得新版本的圖書館也獲得了新版本。
{% twitter 1985421962827743574 %}
React 今年在重大崩潰和安全漏洞方面遭遇了不少困難。
{% twitter 1967203307853873363 %}
今年發生了很多變化，但更多的是視角上的轉變。如果說人工智慧之前還不夠主流，那麼過去一年它已經完全主導了討論。以至於幾乎沒人再談論新的 JavaScript 框架或框架特性了。但這並不意味著事物本身沒有在發展。
在應對當前挑戰時，我們已經到了願景比執行更重要的階段。最初促使許多框架採用訊號技術的對效能的關注，如今已讓位給更具策略性的思考。因此，深入探討這些方向似乎是開啟我們關於2026年討論的最佳切入點。
人工智慧優先框架
過去幾年，我一直認為人工智慧對 JavaScript 框架的開發影響甚微。雖然開發者不斷採用新的工具，LLM（生命週期管理）在各種框架中產生程式碼的能力也越來越強，但框架本身並沒有太大的變化。誠然，人工智慧改變了我們看待文件的方式，有些工具也增加了 MCP（多層整合）伺服器。但它真的改變了我們設計框架的方式嗎？
2025年的展望
任何顛覆性技術都需要時間來適應，產業也需要一段時間。我們可能首先關注的是這項技術目前的現有功能，而不是它的全部潛力。就學習生命週期管理（LLM）而言，這意味著要充分利用其最大的訓練資料集。你可能聽過「React 是最後一個框架」這種說法。
有人認為，React 可以透過其編譯器提高效率，而無需任何新功能或語法變更。但如果我們從過去幾年學到了什麼，那就是這只是癡人說夢。情況總是在變化。
但這種現像是真實存在的。人工智慧就像我們迄今為止遇到的最大回音室，它讓像 React 這樣的框架落入了那些原本根本不會接觸它的人手中。
但這同時也意味著，每個框架都成了先前成功的受害者。 LLM（學習學習模型）在為更廣泛的工具產生程式碼方面正日漸進步。是否存在一個臨界點，屆時這些訓練集的品質將比以往更流行的解決方案的數量優勢帶來更好的結果？
{% twitter 1968901043032342789 %}
因為如果 React 像 2018 年那樣成為“最後的框架”，那麼我們就面臨更大的問題了。
擁抱重新設計
雖然如今新的 JavaScript 框架數量有所減少，但有一個新框架卻真正抓住了 AI 優先的概念。 Remix 3 不再基於 React 建置，而是從底層重新思考了全端 Web 開發。其創作者 Ryan Florence 和 Michael Jackson 一直非常強調 AI 在框架設計和實現過程中所扮演的角色。
{% twitter 1958689049440657653 %}
但他們採取的最有趣的立場是，他們的目標是減少特定領域的語言，使人工智慧更容易產生通用解決方案。
{% twitter 1977731819995910366 %}
在觀看他們的現場演示時，瑞恩會要求人工智慧產生一個簡單的程序，完全不考慮框架，然後他可以輕鬆地將其融入他的演示中。
這與其他框架形成了鮮明對比，其他框架提供了語言原語來更好地描述意圖。儘管實作方式不同，但大多數框架最終都採用了類似的語言體系，即狀態、派生狀態和副作用。
只有時間才能證明，究竟是易於整合的通用解決方案，還是領域原語所提供的保障，才能帶來更好的結果。但感覺我們終於開始注意真正的問題了。
同構優先框架
去年，我們注意到JavaScript框架中伺服器端驅動技術遭遇了阻力。儘管Islands和React Server Components在電子商務和頁面速度評分盛行的時期迅速崛起，但許多開發者發現這些解決方案不足以應對他們正在建立的複雜且高度互動的應用程式。
這種複雜性很大程度上源於伺服器端和客戶端 UI 程式碼之間始終存在的界限，以及人們對 Islands 和 RSC 架構截然不同的理解所產生的困惑。它們在導航和變更方面更像是傳統的多頁面應用程式。
因此，2024 年單頁應用程式的技術升級持續在各個框架中傳播也就不足為奇了。
我們看到 Tanstack Start 和 SvelteKit 都加入了 SolidStart 的行列，將亂序流、伺服器函數、細粒度樂觀 UI 和單次變更等模式引入到各自的生態系統中。
{% twitter 1980775946757238993 %}
這再次印證了我所謂的「同構優先」架構。它可以進行伺服器端渲染，但應用程式的核心程式碼同時執行在兩個環境中。多年來，我們一直採用這種方式實現伺服器端渲染，只是利用了諸如伺服器元件之類的新技術和新功能，而無需改變架構。
事實證明，即使不採用不同的架構，你仍然可以充分利用伺服器的大部分效率。我預計，隨著新年的到來，這些框架將不斷發展，推出各自的伺服器端渲染模板（伺服器元件）。
非同步優先框架
如果要我指出 2025 年 JS 框架領域思維方式發生的最大變革，那絕對是圍繞著非同步程式設計的。
雖然我們看到一些最近採用 Signals 的框架（例如 Angular 的 Resource API）中出現了專用原語，但我所說的轉變更為根本。
{% twitter 1903129479901249933 %}
JS框架的目標是讓建立互動式使用者介面更加便利。大多數框架採用的是聲明式方法。你需要根據使用者介面目前的狀態來描述其外觀。框架負責在處理使用者輸入和同步狀態的同時，確保介面的一致性和反應速度。
最簡單的方法是為同步更新建立保證。這正是虛擬域 (VDOM) 的吸引力所在，也是訊號機制的強大之處。相較之下，非同步更新則失去了這些保證，即使被考慮使用，也常常顯得不夠完善。
如果情況並非如此呢？如果非同步操作具有保證且是使用者體驗的核心呢？
這些問題是 React 多年前透過並發模式和「過渡」提出的。但今年，我們終於看到了這條道路的最終走向。 Rick Hanlon 對 useOptimistic 和「動作」的探索，向我們展示了一個未來：每個使用者互動都被包裹在過渡中，在值可用時協調顯示更新，從而確保一致性。
{% stackblitz https://stackblitz.com/edit/react-8d3u4llb?file=src%2FApp.js,src%2Fdesign.js %}
有趣的是，如果你仔細觀察，你會發現它和 Svelte 中新的非同步處理方式並沒有太大差異。 Svelte 雖然沒有 Transitions，但仍會將觸發非同步的更新分組，以確保螢幕顯示一致性。兩者的行為相似度令人驚嘆，即使 Svelte 是透過編譯器而非明確封裝來實現這一點的。
這裡仍需進一步完善。就 React 而言，要求設計系統採用這些模式可能會對整個生態系統造成巨大的挑戰。但顯而易見的是，我們開始看到那些醞釀了近十年的想法逐漸變成現實。
這種變革影響深遠，而且基礎性極強，不出幾年，就會成為各種框架的基本要求。敬請期待。
JavaScript框架的未來
我認為，與近年來任何一年相比，2025年對框架在Web開發中的作用提出了更大的挑戰。人們一直渴望擺脫複雜性，但其他替代方案卻不令人信服。
你可以先減少工作量，直到無法繼續。你可以先使用更受限的抽象，直到它無法滿足你的需求為止。這對於學習來說是一個很好的練習，作為框架作者，我經常這樣做。你或許可以更有效地利用時間。
所以，我說的不是 HTML、免編譯、Web Components，或是其他任何在各自特定問題範圍內完全夠用的簡化工具。我們大多數人，既然不得不向前邁進，就再也回不到過去那個更簡單的時代了。
我們之所以能夠避免複雜性，只是因為我們繞過了決策癱瘓。我們採用了元框架，並在元框架之上建立了更多精心挑選的觀點和預設（例如 Redwood 和 create-t3-app）。我一直擔心，雖然這些框架很有價值，但很難保持其更新。不過，現在不用擔心了，因為人工智慧已經徹底解決了這個問題。無論作者設計多麼巧妙的框架元件，人工智慧都會將它們簡單地拼湊在一起。
如果有什麼變化的話，那就是它呼應了前面的章節，並且更加關注原始模式。這並不是說 API 被鎖定了。 React 是可以更改的。本地 API 的變更是可以學習的。問題在於，這種拼湊式實現的模組化需求使得我們難以從整體上看待解決方案。
從某種意義上說，人工智慧正透過自身的不足來解決我們面臨的複雜性問題。它就像開發者在不理解系統時所做的那樣：透過降低難度、回歸自身認知來繞過問題。而現在主要負責將各部分整合起來的開發者，很可能會接受這種做法。
我們可以討論這並非最優方案。但解決這個問題至關重要。這顯示我們需要一些解決方案，既能在局部範圍內提供明確的控制，又能與整個系統和諧共存。這與團隊協作開發軟體頗為相似，即便只有一位開發者參與。它改變了某些擴展性問題出現的時間點。
幸運的是，無論是有意還是無意，這種系統性的反思正是該領域正在進行的工作。無論是從根本上重新審視非同步編程，還是探索如何讓大多數現有程式碼與同構模式相容。
結論
這些主題都值得更深入的探討，但我今天只做了這些。過去一年我本來應該多寫幾篇文章，但我一直忙於研究。
現在正是開發 JavaScript 框架的絕佳時機。這與 Islands、Resumability 或 RSC 等框架橫空出世時的情況截然不同。這並非是對未來技術能力的驚鴻一瞥，也並非是從架構層面改變我們解決問題的方式。
這是一個核心精煉的時期。我們要汲取經驗教訓，應用更普適的真理。這種改變不僅影響我們編寫程式碼的內容，更會影響我們思考程式碼的方式。因為我們甚至可能不再是程式碼的編寫者。
雖然過去幾年人們一直在談論類似的事情，但我認為到2026年，我們將開始看到這些說法變成現實。各項準備工作正穩步進行。
如果你覺得這一切毫無意義，沒關係。給自己一些時間。說實話，直到我感受到自身領域內決策的影響力，我才開始理解這一切。就像某個遙遠的黑洞，悄悄地改變著引力的走向。但經過幾年對過往複雜架構的摸索，我已經做好了充分的準備，跟著它，走向未來的方向。
橫幅圖片來源：©️ Artur Sadlos 的Cyberpunk-City 。
原文出處：https://dev.to/this-is-learning/javascript-frameworks-heading-into-2026-2hel
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
