 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Bun creator Jarred Sumner said that while the JavaScript runtime has React Server Components (RSC) integration, it’s not documented and is in a very incomplete state.
“You can sort of use it if you’re adventurous enough, if you pass //app to Bun build,” Sumner said. “This is something that we eventually want to do a much better job of, but honestly, right now we’re very focused on Node compatibility, so we can’t really spend time on it.”
From a runtime perspective, the overlap of the bundler with the runtime makes it so that Bun can probably create “a pretty good experience” he said, but the team is focused on making it “simpler to do the server-side rendering parts in a way that actually makes sense without having to do the hydration step,” he added.
Bun’s still not there yet, he said, adding that the team is more focused on Node compatibility at this time.
Sumner was part of a panel that discussed the State of React at React Summit 2025. The conference took place in mid-June, but GitNation, which hosted the event, only released the conference videos last week.
One of the frameworks that has implemented RSC is Waku, Naman Goel said (Waku is designed for RSC). Goel developed StyleX, which is a JavaScript syntax and compiler for styling web apps, as well as some tools for React. Next.js and Redwood have also implemented RSC, he added.
Goel noted that the first time he learned about RSC was at Meta, where it was meant to be an internal solution for Facebook’s news feed. There are more than 2,000 possible news post types on the news feed, he said.
“Almost all of them are fairly static with a few interactive bits, and it was an optimization to not ship all these different components that you may or may not need, and if you could, just run it on the server,” he said. “That optimization was the original goal, but it [had] evolved into something else by the time it actually shipped, where it’s more of an architecture, it’s more of a data fetching thing.”
Because of that evolution, it’s hard to pin down one part of what server components are, he said.
“To some people, it is just a serialization format which can be used, just to return data from a loader; and to other people, it’s this whole architecture where you have mutations and things like that,” he said. “I don’t think we can have a productive conversation until we settle that debate of what is several components, what is Next.js’ architecture, and where’s the line?”
Sasha Greif led the panel. He founded Devographics, which runs the State of React and other frontend-related surveys. Greif quickly checked with the audience and found that while almost everyone had heard of RSC, only about 30% of the audience — 10-15 people — had actually tried RSC. One of the promised benefits of RSC was to simplify code, he said.
“That’s representative of the ecosystem as a whole,” Greif noted. “There’s a big, big mind share, but practical usage is still a bit slow.”
Several panel members expressed a lot of hesitation about RSC.
“I’ve seen the same common pattern, which is: It is hard to first understand what RSCs are, but also once you understand them, to adopt them has been hard as well,” said Shruti Kapoo, a technology educator who has worked as the lead member of the technical staff at Slack and as a software engineer at PayPal. “And the sliver where you can actually use RSCs and they have the right kind of advantage is small, so the adoption, therefore, has been very low.”
For example, Slack wants to adopt RSC, but it doesn’t use Next.js, she added.
“How do we go down that route?” Kapoo said. “I find it one of the hardest things about adopting RSCs.”
Expo added experimental support for RSC at the beginning of the year, according to panel member and Expo Engineering Manager Evan Bacon.
“We added server components support to Expo experimentally beginning of this year, and it’s been pretty good so far,” he said. “On native, there’s, like, no data fetching, like, there’s so much variety for data fetching in the web, and we just have very little on native. So it’s jarring to jump from nothing to this really comprehensive, fine grain, granular system.”
RSCs bridge the gap between web and native development by standardizing the most challenging part of cross-platform work: Data handling, he explained.
“This is just so foundational. With RFCs, we actually have an opportunity to build universal data fetching that works right at once,” he said. “It just runs pretty aggressively everywhere, which we find to be really nice on native.”
Expo also used it for ‘little hacks,’ such as when an RSC payload needs to be streamed through a web-based HTML renderer on a native platform. With RSC, you can make the native runtime interpret the RSC payload, essentially creating a ‘React-first browser,'” he said.
One of the promised benefits of RSC was to simplify code, Greif said.
“When I actually implemented RSC, I ran into all of the edge cases, as you might expect, which meant that my code base didn’t really get simpler, more like the opposite,” he said. “So I wonder if maybe React components weren’t sold the right way, and I still struggle to articulate the reason why you should even care about them and use them.”
“When I actually implemented RSC, I ran into all of the edge cases, as you might expect, which meant that my code base didn’t really get simpler, more like the opposite.”
—Sasha Greif, founder Devographics
Mark Erikson is a Redux maintainer and a senior frontend engineer at sales engagement platform Replay.io. He suggested that anyone who is confused should just read Dan Abramov’s numerous blog posts about RSC. Abramov previously worked at Meta and is known for his open source contributions.
“He’s already written a dozen posts about this topic in more detail than any of us could do,” he said. “He’s been approaching it from the perspective of, if you know REST APIs, here’s how server components is different and better than REST APIs.”
He also approaches it for developers with a GraphQL background, Erikson added.
“He’s repeating the same thing in different ways, but he’s […] making the comparisons,” Erikson said, who has written his own post about RSC — where he noted that “many companies may not be running JS backends, and may even have rules and restrictions against that.”
Abramov’s posts include a piece on the confusing role of server in React Server Components.
According to Goel, one option for those who want to try RSC without fully committing is incremental adoption, though he noted that guidance is “buried in the npm documentation.”
I couldn’t locate that exact reference, but incremental guidance is also available in the RSC documentation and in a Mux post about its RSC migration of 50,000 lines of code.
