More variety, would you say? More variety, yeah. So I think it was one of the questions we had before, but what's been preventing adoption of React components? Anybody want to take a shot? I'll start. So I actually led a panel at React. I'm going to blank out on the name. But in San Francisco, I led a panel there as well, and we talked about the same thing. What are RSCs and why adopt them? And I think since then, and up until now, 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. And the sliver of slice where you can actually use RSCs and they have the right kind of advantage is small. So the adoption therefore has been very low. Like, for example, at Slack, we want to adopt RSCs. But we don't have Next.js. So how do we go down that route? I find it as one of the hardest things about adopting RSCs.
Yeah, well, we added server component support to Expo experimentally at the beginning of this year, and it's been pretty good so far. I mean, 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-grained granular system. And one of the benefits that we see from it is it's really, like, a universal primitive for SSR, SSG. Like, it's a system that you can apply to both native and web simultaneously. And when we look at, you know, people trying to code share, it's pretty straightforward to code share components, styles, maybe even interactions. But then, like, if you have to start forking at the router level or if you have to fork between platforms at the data fetching level, like, how authentication works, then it kind of all crumbles apart. It's just so foundational. And so with RSCs, we actually have an opportunity to build universal data fetching that works right at once and just runs pretty aggressively everywhere, which we find to be really nice on native. We can also do, like, little hacks where, you know, like, RSC payload, you need to stream that through, like, an HTML renderer on web. On native, you can just make the native runtime interpret RSC essentially as, like, native HTML. And so you get this more pure version of, like, sort of a React-first browser.
Do you think there's a cost in the fact that React wasn't born with RSCs and it's something that came in later compared to something like, I don't know, Astro has. It's not the same thing, but it was built from the start in that perspective of having the island architecture. Is there a future maybe some new framework that's going to integrate that concept right from the start? So, I mean, I think it's primarily an integration problem, which is, like, I saw very similar things even with Stylix where, like, once everything is set up, it's probably fun and nice to use, but setting it up is, like, such a hard thing that once you get stuck at the very, like, step one, you'll never use it. And I think just so far, like, Beats hasn't shipped integration and, like, Webpack was the only one, and even that integration wasn't, like, a super clean, easy, portable implementation. So I think it's just the tooling hasn't caught up yet. So in Bund, we actually this is not documented, and we haven't worked on it in, like, six months, but we actually have a React server components integration.
Comments