Remix 3 Beta Preview 的發布在前端開發社群引起了極大討論，因為它採取了一個極其大膽的決定：捨棄 React 運行時，轉而全面擁抱 Web 平台原生標準。對於習慣於 React 生態成長的工程師來說，這次更新不只是版本升級，而是一次徹底的底層重構。
從中心堆疊到全棧框架的演進
在之前的版本中，Remix 的定位較像是一個中心堆疊，主要負責路由管理與渲染。但在 Remix 3 中，它將自己重新定義為一個完整的全棧框架。這意味著它不再只處理前端路由，而是將路由、請求處理器、中間件、Session 管理、身分驗證、表單處理、檔案上傳、資產管理、資料庫管理以及 UI 組件等所有開發環節，全部整合在一個由小型可組合套件構成的體系之下。
擁抱 Web 標準：減少抽象層的依賴
Remix 3 的核心邏輯是減少框架對開發者的干涉，讓開發者直接與瀏覽器原生 API 互動。
在後端部分，路由現在直接採用 Fetch API 路由，控制器回傳的是標準的 Response 物件，表單則直接提交至 URL。這種設計將請求的生命週期完全交還給伺服器掌控，減少了框架特有的黑盒子邏輯。
在前端部分，雖然保留了 JSX 的語法糖，但移除了 React 的運行時。取而代之的是一個基於 Preact 的分叉版本，並將開發模式從函數式轉向指令式。在 React 中，我們習慣使用 useState 觸發重新渲染；但在 Remix 3 中，狀態被簡化為普通變數，開發者透過呼叫 this.update() 來通知系統狀態已更改。此外，非同步操作現在統一使用標準的 AbortController 訊號來處理取消請求。
伺服器驅動 UI 與 Frames 概念
Remix 3 引入了名為 Frames 的機制，這讓它在操作感上非常接近 HTMX。Frames 是由伺服器渲染的片段，每個片段擁有自己的 src 屬性，可以獨立地載入與重新整理。這意味著頁面不需要全頁刷新，也不需要複雜的客戶端狀態管理，就能實現局部 UI 的動態更新。
解耦打包流程：Unbundling
傳統的前端開發高度依賴 Bundler 打包工具（如 Webpack 或 Vite）來定義模組依賴。Remix 3 提出了 Unbundling 概念，將運行時視為唯一的真相來源。資產由 Remix 直接編譯並提供服務，不再依賴特殊的 import 語法來定義行為，進一步降低了建構工具對開發流程的束縛。
實務影響與遷移挑戰
對於現有的 Remix 2 用戶來說，這不是一次簡單的版本更新，而是一次斷層式的遷移。由於底層運行時從 React 變更為 Preact 分叉版，原有的程式碼無法直接無縫升級。官方建議 Remix 2 的應用程式將遷移至 React Router v7，而 Remix 3 則被定位為一個全新的起點。
這項變革在社群中造成了兩極評價。支持者認為這讓開發過程更接近 Web 標準，且明確的設計邏輯更有利於 AI 輔助編碼；反對者則批評其變動過大，導致框架變得完全不可辨識，且對向後相容性的忽視增加了維護成本。
總結：回歸原生的賭注
Remix 3 的方向代表了一種技術趨勢的擺盪：從高度抽象的函數式框架，回歸到更直觀、更接近瀏覽器原生的指令式開發。在 Next.js、SvelteKit 等競爭對手依然強調框架抽象層的當下，Remix 選擇將籌碼全部壓在 Web 標準上，試圖定義一種更輕量、更透明的全棧開發模式。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。