Bun的創建者Jarred Sumner表示，雖然JavaScript運行時具有React服務端組件（RSC）的集成，但并未記錄，并且處于非常不完整的狀態。

“如果你足夠大膽，可以將//app傳遞給Bun的build來使用它，”Sumner說。“這是我們最終想要做得更好的事情，但說實話，目前我們非常專注于Node兼容性，所以我們無法真正花時間在這上面。”

從運行時角度來看，打包器與運行時的重疊使得Bun可能創造“相當好的體驗”，他說，但團隊專注于以更有意義的方式簡化服務器端渲染部分，而不必執行水合步驟，他補充道。

Sumner說，Bun尚未達到這一目標，并補充說團隊目前更專注于Node兼容性。

RSC與Next.js架構

Sumner是GitNation舉辦的React峰會2025上討論React狀態的小組成員之一。該會議于6月中旬舉行，但主辦該活動的GitNation上周才發布了會議視頻。

Naman Goel表示，Waku是已實現RSC的框架之一（Waku是為RSC設計的）。Goel開發了StyleX，這是一種用于樣式化Web應用程序的JavaScript語法和編譯器，以及一些React工具。Next.js和Redwood也實現了RSC，他補充道。

Goel指出，他第一次了解RSC是在Meta，當時它被設計為Facebook新聞推送的內部解決方案。他說，新聞推送中有2000多種可能的新聞帖子類型。

“幾乎所有的帖子都是相當靜態的，只有少數交互部分，而優化是為了不發送你可能需要或不需要的所有這些不同組件，如果你可以的話，就在服務器上運行，”他說。“這種優化是原始目標，但隨著實際發布時，它已經演變成其他東西，它更多地是一種架構，更多地是一種數據獲取的東西。”

由于這種演變，很難確定服務端組件的某個部分，他說。

“對某些人來說，它只是一個序列化格式，可以用來從加載器返回數據；而對其他人來說，這是一個整體架構，其中包含突變等東西，”他說。“我認為，在我們解決RSC是什么、Next.js的架構是什么以及界限在哪里的問題之前，我們無法進行富有成效的討論。”

小組和觀眾對RSC的采用率低

Sasha Greif主持了該小組。他創立了Devographics，該組織負責State of React和其他前端相關的調查。Greif迅速向觀眾進行了調查，發現雖然幾乎每個人都聽說過RSC，但只有大約30%的觀眾——10到15人——實際上嘗試過RSC。Greif表示，RSC的一個承諾好處是簡化代碼。

“這代表了整個生態系統的整體情況，”Greif指出。“有很大的思想共享，但實際使用仍然有點慢。”

幾位小組成員對RSC表示了很多猶豫。

“我看到了同樣的常見模式，即：首先理解RSC是什么很難，但一旦你理解了它們，采用它們也很困難，”技術教育者Shruti Kapoo說，她曾在Slack擔任技術員工的主要成員，并在PayPal擔任軟件工程師。“而且你可以實際使用RSC并具有正確優勢的范圍很小，因此采用率一直很低。”

例如，Slack希望采用RSC，但它不使用Next.js，她補充道。

“我們如何走這條路？”Kapoo說。“我發現這是采用RSC最難的事情之一。”

Expo使用RSC的經驗

根據小組成員和Expo工程經理Evan Bacon的說法，Expo在今年年初增加了對RSC的實驗性支持。

“我們今年年初在Expo中增加了對服務端組件的支持，到目前為止效果相當不錯，”他說。“在原生端，幾乎沒有數據獲取，就像在Web上有大量數據獲取的多樣性，而我們原生端只有很少。所以從無到這種非常全面、精細、粒度化的系統是一個很大的跳躍。”

RSC通過標準化跨平臺工作中最具挑戰性的部分——數據處理——來彌合Web和原生開發之間的差距，他解釋道。

“這非常基礎。有了RSC，我們實際上有機會構建一個從一開始就能正常工作的通用數據獲取，它幾乎到處都非常積極運行，我們在原生端發現這非常不錯。”

Expo還用它來進行“小技巧”，例如當RSC負載需要通過原生平臺上的基于Web的HTML渲染器進行流式傳輸時。使用RSC，你可以讓原生運行時解釋RSC負載，基本上創建一個“React優先的瀏覽器”，他說。

RSC的潛力

Greif表示，RSC的一個承諾好處是簡化代碼。

“當我實際實現RSC時，就像你可能預料到的那樣，我遇到了所有邊緣情況，這意味著我的代碼庫并沒有真正變得更簡單，更像相反，”他說。“所以我在想，也許React組件并沒有以正確的方式推廣，我仍然難以解釋你為什么應該關心它們并使用它們的原因。”

“當我實際實現RSC時，就像你可能預料到的那樣，我遇到了所有邊緣情況，這意味著我的代碼庫并沒有真正變得更簡單，更像相反。” ——Sasha Greif，Devographics創始人

Redux維護者、銷售參與平臺Replay.io的高級前端工程師Mark Erikson表示，任何感到困惑的人都應該閱讀Dan Abramov關于RSC的眾多博客文章。Abramov曾在Meta工作，以其開源貢獻而聞名。

“他已經寫了十幾篇關于這個主題的博客文章，比我們任何人都詳細，”他說。“他從如果你了解REST API的角度來處理這個問題，這里是如何說明服務端組件與REST API不同且更好。”

Erikson補充說，他還為具有GraphQL背景的開發者處理這個問題。

“他以不同的方式重復同樣的事情，但他[...]正在進行比較，”Erikson說，他寫了自己的關于RSC的博客文章——其中他注意到“許多公司可能沒有運行JS后端，甚至可能有關于此的規則和限制。”

Abramov的博客文章包括一篇關于React服務端組件中服務器的困惑角色的文章。

逐步采用作為一種選擇

根據Goel的說法，對于那些希望在不完全投入的情況下嘗試RSC的人來說，逐步采用是一種選擇，盡管他注意到指導“埋在npm文檔中”。

我無法找到確切的參考，但RSC文檔中的逐步指導和Mux關于其RSC遷移的帖子（涉及50,000行代碼）中也提供了逐步指導。

原文地址：https://thenewstack.io/the-problems-with-react-server-components/
作者：Loraine Lawson