TanStack Start 正式支援 React Server Components

背景

TanStack 團隊正式宣布 TanStack Start 支援 React Server Components (RSC)，強調其開發哲學與 Next.js 的「伺服器優先」模式不同。TanStack 將 RSC 視為一種可組合、可快取的數據流原語，允許開發者像獲取 JSON 一樣靈活地在客戶端決定如何獲取與渲染伺服器組件，而非強制讓整個應用程式繞著伺服器架構旋轉。

社群觀點

在 Hacker News 的討論中，社群對於 TanStack Start 的推出展現了極高的期待，甚至有開發者認為如果這套工具在未來幾年內沒有取代 Next.js，那將是開發生態的損失。許多從 Next.js 遷移過來的用戶指出，TanStack 搭配 Vite 的組合在開發環境的效能表現遠優於前者，特別是在記憶體消耗與熱更新速度上有顯著提升。支持者認為 TanStack 的設計更符合直覺，將 RSC 視為一種「數據」而非「黑盒化的框架慣例」，這種去中心化的思維讓開發者能保有更多主導權。

然而，關於 RSC 本身的必要性仍存在激烈辯論。部分反對者質疑，在客戶端運算能力與網路頻寬普及的今日，將渲染邏輯移回伺服器的做法是否真有其價值。有觀點認為，RSC 雖然能減少 bundle size，但代價是增加了伺服器負擔與網路往返次數，對於非靜態的 SaaS 應用來說，這種權衡未必划算。此外，也有資深開發者感嘆網頁開發陷入了每五到六年就循環一次的怪圈，認為與其在複雜的 JS 框架中掙扎，不如回歸傳統的 PHP 或 JSP 模板渲染，僅將 JS 用於必要的互動。

針對這些質疑，支持 RSC 的開發者反駁指出，RSC 的核心優勢在於能讓資料獲取與渲染並行，避免了傳統客戶端渲染必須先下載大包 JS 才能開始請求資料的延遲。TanStack 的創辦人 Tanner Linsley 也親自參與討論，澄清 RSC 與 SSR（伺服器端渲染）是不同的概念，不應混為一談。值得注意的是，社群對於 TanStack 選擇不支援 use server actions 表示讚賞，認為這避免了潛在的安全漏洞與過於隱晦的網路邊界，讓開發者能更明確地管理 API 邊界，而非追求過度魔幻的遠端程序調用。

延伸閱讀

在討論過程中，參與者提到了幾項值得參考的資源。針對行動裝置效能的落差，有留言引用了 Alex Russell 撰寫的 Performance Inequality Gap 報告，探討低階裝置在處理複雜 JS 時的困境。此外，Josh W. Comeau 關於 React Server Components 的深度解析文章也被推薦作為理解 RSC 與 SSR 差異的基礎教材。對於偏好其他框架的開發者，留言中也提及 Preact 支援即將到來，以及 SvelteKit 與 Solid 在隱式 RPC 模式上的不同嘗試。