Panel Discussion: Difficulties of Adopting RSC From a Framework and Library Sides

So the theme for us today is the title that we were given to ponder upon and meditate on is Challenges of Adopting React Server Components as a Library or Framework Maintainer or Author. You know, that's a very broad missive and, you know, like I think we're all very sort of like interested in the process that goes into the meat grinder. You know, I think Daishi today, you know, you explained, you showed, you know, in practice what, you know, like undertaking it is to actually implement all of the different, you know, sort of cases needed to support server components. So let's jump sort of straight into it. So, you know, you work in a work where, you know, you have sort of essentially had to figure out, you know, all of this, you know, for yourself. How has the experience been? Well, is it on? Yes. Okay. So developing React Framework is tough. One of the reasons is that it's not very specified. So I went through all examples and try out many, many things and see, understand the behavior, not from the document, not from the source code and, yeah, build a mental model and create a framework, which is still a tough task. But yeah, I've done it. You've done it. Yes. Yes. A round of applause. And I understand Tobi, you are in the process of doing it. You haven't quite yet done it, but you are close to having done it. Is that right? I'm trying to... saying close is difficult, but yeah. No, I feel like we're finally getting close to having something that we can ship for users to play with for sure. Yeah, right. So Redwood is making the sort of migration, you know, like before you would, you know, like I guess Redwood would be considered sort of like centered around GraphQL and now in the future, the next version of Redwood will be...

So next version, coming back to what are our major versions, we try to, like we are on version 8. We're probably going to be version 9, 10, maybe before doing the big release with React Serial Components. So we try to speak in epochs instead, but we'll see. The messaging is difficult around major versions for sure because people have heard, expect big things, but just because it's a major version break. But yeah, so next version may probably not, but yeah, next epoch definitely going to be React Serial Components. Yeah. And Dominik, you know, you're working on React Query, which is sort of like a client library, right. But are you surprised at all that you're kind of finding your library in a very pivotal position in this sort of like, you know, migration? Like, you know, in my job we use Next.js App Director and we use server components and we use React Query, you know, as the kind of like client-side cache.

So you must be like seeing a lot of the like actual live end-user, you know, sort of problems and challenges. Is there, you know, anything like what's been your experience as a maintainer of a project sort of, you know, perceiving people adopting server components using React Query? Yeah, it's a bit of an awkward position to be in because as you said, React Query is like fundamentally a client library, right. So all the hooks that we expose cannot be used on the server. So sometimes we get questions like, can we use this in server components? And the answer is like fundamentally no, you can't use it in a server component. You can't use it in a framework that leverages server components for rendering if you want some client-side interactivity or if you want to start the fetch on the server and then send data or even send the promise to the client and then put it into the client cache and then continue with client-side interactivity there. But in server components themselves, React Query doesn't actually export any components apart from the context provider. So there is really nothing that you could use in a server component. Yeah, but yet it's like a pivotal part of it and actually similar, your previous effort, you are well known to be a maintainer of many state management libraries. Again, like the people that you have interacted in the past, maintaining these libraries have now sort of facing this monumental sort of like rethink. Are you seeing any sort of churn there? Yeah, exactly. For people who has used my state management library, want to use server RSC, server component, but it's not possible because it's a client-side state management library. So I have had a hard time explaining why this is not possible or how should we do. So that's one of my motivations to start developing Waku so that I can eventually support those state management libraries. So yeah, that's the thing, how it goes. Yeah. And I think that's kind of like, we were yesterday talking about this and I think some mindset shift is sort of like a big thing and we'll probably spend a lot of time talking about it. So before we jump into it, Alexander, I also wanted to sort of ask you, you just gave a presentation where you showed sort of the timeline of the things that you have sort of worked on in the context of data. And it was very interesting in the context of React server components because you were in a way like a trailblazer with Blitz, kind of this early model of being able to import server code into client code, even though it wasn't based on RSC. So how do you sort of see this transformation? Like if you were working on that project or your next project in that space, do you think RSC would be the way to go for you? Yes, I think so. Like something that we try to do is to like minimize this API layer to bring server closer to the client, which is also something that RSC enable. And basically it was this framework that would let you run server code or access your database directly in your client components. And yes, it did not use RSC. We spent some time thinking like, okay, so how do we deal with that? How do we not copy the code? Like how do we not have it in two places on the server and on the client? How does it communicate? So yes, I definitely feel that RSCs are the way. It's a shame that we didn't have them back then, but it's good that we had Blitz. Well, that is always the pain of the early adopter of the trailblazer. You have to figure out a lot of things that the later generations get for free, essentially. So let's jump into this kind of mindset shift. This seems to be something that like, was it yesterday, we were having a bit of conversation about what we should talk about. And Dominik said something like, well, there are these developers who just don't want to update their thinking. And I was like, wait a minute.

I'm one of those. Yes. And I realized that I am one of those developers. I've been doing React since pretty much the beginning. And I have a relatively fixed set of ideas of how I want the framework to work because it's my comfort zone. And it's kind of like the area where I didn't realize that I'm being asked to innovate or grow, or learn. I thought that was kind of set and I could focus on other things. And now all of a sudden, you guys are asking me to get out of my old man habits and learn new things. Is that right?

I think it's an even bigger mindset shift than we had when we transitioned from class components to hooks. I mean, in some way it's similar because you had to stop thinking in life cycles and you should start thinking in data synchronization with hooks. And that kind of like, wasn't easy for a lot of developers. There were a lot of things that you had learned before that you needed to unlearn and then go on with the new stuff. And I think with server components, it's similar. And it's probably even more of a mindset shift, because all of a sudden you need to think about where is the boundary between server and client? What can I do on the server? What can I do on the client? Where do I put those boundaries for the compiler? How do I get a server component as a child to a client component so that I don't have to have everything client components starting from one point downwards and so on? And there's a lot of unlearning that needs to be done and a lot of learning new things.

I don't know, maybe future generations of developers will have it a bit easier because they are not burdened with working for lots of years only with this client side stuff and then needing to really rethink everything. And they'll probably outperform us by a lot. I think the same. It's difficult for us that are used to working all in the client to switch over to working on the server. But I talk to a lot of developers who are back-end developers or who work with frameworks like Django, for example, and they think we are crazy doing all this use hook stuff in the client. They say we have so much simpler because we can focus on the server only. And I think with React Server Components, we can get a simpler model for React as well. So I think that new people picking up React for them, React Server Components is actually making things simpler and easier. Yeah, I think it's definitely simpler for newcomers. But if you have already existing apps, you have to migrate to the new one. Then you want each component to migrate, like one or two client components to server component. But the best practice is that we should use server component as much as possible. So there is a big gap between this migration pattern to free new. So that's one of the tricky things, I guess. Yes, but also something that Jani mentioned, like there are people who are already used to the current model and it might take some time for them to learn the new one.

Yes, but also something that Jani mentioned, like there are people who are already used to the current model and it might take some time for them to learn the new one. Like even though for the newcomers, like learning from scratch, like that there is an RSC thing, it might be good. But I think there's a bunch that would need to go through a certain frustration phase to how to switch to those components or how to learn those things, how to write differently. Yeah, I mean, the one word that I hear a lot at this conversation is simplicity, right? Like it makes, you know, like I'm trying to sort of go towards simplicity for the developer perspective. And then you have the framework or library authors to sort of carry the complexity. And I guess that's always the framework's job, you know, like find an abstraction that sort of like does most of the work in a way that aids the developer. Where do you think that we are in the sort of like actual end user or the end developer experience there? Like if you look at the current implementations of server components, I think Next.js is the most production used one. And then Waku, for example, is it already today, like would you say that it's simpler and will there be further opportunities for simplification to build applications in this new model? I've yet to build something like production grade with server components. So from my perspective, we're still on the very edge of things. Like if you look at things that are being discussed on Twitter or at conferences, this is still very far away from what's actually happening in the biggest part of the long tail of the industry. So we're still on the very early adopters, even though server components exist for, I don't know, over a year or something. Yeah, I still think it's going to take a much longer time until there's broad adoption of them. Yeah. And I also think that we need more implementations than just one to be able to see what are actually the good parts and what parts can be improved. It's difficult to know, like, what is fundamental to how React components have to work and what is just a part that the way that we next choose to implement the protocol or the, yeah, what's the framework doing and what's part of React. It's difficult to know when there's just one implementation. So when more people start using Waku, when Redroot can finally ship something that people can play around with and we have like three different implementations, that's when I think we can start seeing what are the good patterns and what should we carry forward. Yeah, if I have to add it, so Waku is developed because I wanted to have RSC only without SSR, without router. I just wanted to learn how RSC works. And there was no such things before. So this is my first one. This should be the first one. And you can learn RSC without SSR and router. Yeah, that's, you know, like Redwood, for example, you said you would need three implementations. And so we have Next.js, now we have Waku. And then it sounds like Redwood might be sort of the third one. What are you learning from the prior art? You look at, for example, Next.js implementation. Of course, some of it is tied to the sort of assumptions they have around the infrastructure and the way the apps are hosted. But what are the things that you go like, oh, those are good ideas. And then maybe those are something that we want to innovate upon? Yeah.

So when we started, there were basically no examples out there and no documentation. And so we started looking at Next. But like React components are actually pretty easy, or like the concept is simple. But implementing it in a framework is very, very difficult. And trying to pick out the parts that are fundamental to React components by looking at the Next source code is difficult, just because Next is such a big framework and they do some main things. So we actually, or I actually started by copying a lot of code from Wacuu, because they were, you guys have always been a few months ahead of us. So I can could learn a lot from what he was doing there in Wacuu. And that was much simpler because we had previously switched from Webpack to Vite. And he was also the first author to build on top of Vite with server components. That also made it easier for us to learn from his example. Now, it's much easier. Now there are lots more examples out there. So if now, if you want to implement something with from scratch with React source components, there are lots of other YouTubes, there are blog posts and lots of examples out there you can look at. But when we started, there was nothing like that.

Yeah, as I said, there is no docs. But there's something called fixtures in the React repository, which you can learn from. And that runs RSE only. So that was one of our resources. I didn't look into Next.js code because it's complicated. And it combines everything. So yeah, I was gonna say, yeah, that picture is one good resource. And I did much, experiments with how it behaves. And somehow, it worked. Yeah, it almost seems to me in some sense that like React server components is less an implementation and more just the specification. Of course, it's specification in code, and it has like parts that you use in the implementation, but it does leave the framework authors to sort of figure out the shape of things.

There's a little bit of both. When we first started, we were actually approached by the Facebook or meta team and invited to an internal work group, their internal Facebook kind of work environment. But that was actually pretty quiet. Not much was said in there. But now I'm part of similar group of people who builds on top of Vite.

And that's been very useful. Like we share learnings and questions there. And I learn a lot from reading what other people what other people's questions are and what their answers are. And especially for Vite, there are actually a lot of people who are right now experimenting with different things, lots of exciting developments going on there to learn from.

Okay, well, I wanted to ask one sort of spicy question. I don't know. Feel free not to answer this if this is something that is, it's not within your sort of comfort zone. But you know, like right now we have this one implementation of server components that's really mature, maturing out there. And it also happens to be made by the company that employs the React core team and pays them to, you know, build this, you know, sort of technology is like, how do you see sort of like that relationship, you know, in the long run for the for the community as kind of like third party implementers, like, obviously, there's some good parts, but are there some challenges as well?

So, well, when I'm hearing what the other framework authors are actually struggling with, it does feel like a bit there's maybe a bit of an unfair advantage in this whole situation where there was like the word was said that, you know, here are React server components, they are now ready, you can use them and Next.js has implemented them and it's ready and all the others like go figure it out yourself, maybe, I don't know. But I haven't had this this struggle myself. And I think from a from another perspective, I think it's actually good that the maintainers of the React core team are now a bit more distributed among different companies. I think that that doesn't hurt, generally.

Yeah, and I agree. And I think, I think that we all agree. And we see that with next itself now with the what's it called OpenNext initiative or something like that, where you can actually start deploying Next fully functioning on other ecosystem, not just with inside Resell. And I think it's the same with React components, it needs to be implemented in more than one place. I think it's best for all of us.

Speaking of the unfair advantage, I'm not sure if this is really tied to our React core team being employed by Next by Versal. But also like the fact that Next.js team is quite huge. I remember that we were struggling with that with Bleeds, like we couldn't iterate as fast as they did. So at one point, like they were, you know, they were adding features, they were releasing new Next.js versions, and there was no way for us to catch up with like a two-person team. So that may be also a reason. Yeah, I mean, we feel that all the time.

They had they just had the Next.conf. And obviously, they have lots of awesome features, but then we also have to remember they're a big team. And we are very small. It's definitely the underdogs here. And you're just pretty much on your own. But I bet it's even worse for you. But for the full disclosure, Versal sponsored Waku. So they care about the community. So I think it's a good thing.

Yeah, I think like I definitely don't want to like try to force a narrative of there being like a competition or like an unfair advantage in the sense that there is a race to some sort of like a payoff, right? Like, you know, these different entities have highly different motivations on you know, sort of like exploring this kind of thing. I think I'm mainly thinking from a perspective of like a developer who himself wants to, you know, build applications and wants to use the sort of best, you know, tool for the job. And then, you know, some tools are sort of tied to certain, for example, infrastructure platforms and, you know, et cetera, is, you know, is there, you know, there was a term bandied about, you know, a few years ago, some people called it the React industrial complex. You know, this is kind of like a industry of companies around, you know, this is like, is RSC sort of like making React, you know, because of the implementation complexity of the framework, sort of, is it becoming more of a, you know, like a few dominant players field? Or do you feel like there's possibility for like individual developers to contribute in an open source sort of open community sense? As much as maybe in the olden days of client only development? I think there's definitely still room for individual experimentation and contributions, definitely contributions, like at Redwood, we're always happy for more contributions. And it's easy for maybe not easy, but we welcome anyone and happy to help anyone to get started with contributing for sure. Another motivation I developed Waku is to accept more like to grow the ecosystem. So I provide some minimal primitives, people can use to develop a new library on top of it. So that that's really my goal. Yeah, no, that's amazing. And I think, you know, like, given that you do the hard graft, and in fact, other people can innovate on that. That's, you know, I think, and also the V-team is doing a great job making it easier for people to build these things, especially with V6 coming up with the environments API is going to make a lot of this much, much, much simpler than it was before. And also making it easier for of course, for anyone to build something with their own twist to React components. And it's like you said, it's more of a specification and people can choose what parts of it that they implement. So I think we're gonna see some interesting things coming out of the Remix team when with their takes on it. And we see with with 10 stack, their take on React components is also super interesting. So I think we'll see more of that.

Yeah, what is the 10 stack take on React components? I actually have several components, actually don't know anything about this. Yeah, I'm not an expert on the topic. I'm not really involved with with 10 stack start that much. But the way I understand it is that Tanner is trying to see React server components as like the RSC payload is just another form of data that you transfer from the server. So similar to the Remix approach where you basically have loaders that can return components that will be then sent as RSC payload to the client. In 10 stack start, you will very likely have server functions that you can declare, and that can either return data, JSON, whatever, or streams or RSC payload. And then you can create components on the server and stream them down to the client like that. So different approach than Next.js and also Baku are having. But yeah, I think the more different takes there are, it's experimentation on a very edgy level. And we'll throw things at the wall and see what sticks basically.

Nice. So one thing that we've discussed here is clearly this need for implementations, additional implementations, in order to learn more about the qualities of this technology. But what else is needed? I know, Toby, you're working on some developer tools kind of stuff. But what is the kind of state of if people want to get involved in exploring the space, what are some of the areas that are clearly screaming for attention but haven't yet received it? Yeah, like you said, I'm ending my talk in a few minutes. I'm going to talk more about the developed tooling, and I think that's something that is really needed. And I think that Next team is also realizing that it's needed, but they have other things to focus on as well. So there's definitely room for contributions there if you want to get involved. And it's also a very, very good way to become an expert on React Circle Components themselves, like to build tools on top of them or for them. Really forces you to understand how they work.

Anybody else have any wish list? Yeah, I don't know if that's been figured out already. It's like how to test all these server components setups, apart from end-to-end testing. I think that was the answer initially, like you have an app with server components and you want to test it, you need end-to-end tests on it. I think Storybook then tried to get some support for server components as well. I don't know how the current status is, but last time I checked, it was just right end-to-end test. Okay, this is good for some situations, but not what everybody's doing all the time. So how do you go about that? I don't know if that's an answered question in the meantime, but this was something I've been wondering.

Sure. Well, one thing I've heard, time and time again, come up in this conversation is how there hasn't been a lot of documentation or there isn't one sort of authoritative resource on how to get started. Is now the time to create it or are we still figuring out the things? Yeah, I guess so. But our team did a great job and we have a website, work website, which explains everything from the start. Without you knowing RSC, it explains everything to get used to it. But that's our website. It would be nice if there were more websites with authority. I have to say though that the React team has done a great job on their documentation. Now there actually is much, much more documentation than it used to be. They even have some sections in their documentation that they say, this is for framework authors. So this is how the framework should implement this. And then they have another section for how users should use it. And that's been super helpful. I wish that existed when I started.

Nice. Well, it looks like we're coming towards the end of our time. We have about four minutes left and we have four panelists here. So I figure let's do a little lightning round here. What's something exciting that you are personally working on or looking forward to working on in a coming year? Is there something that you're really looking forward to sinking your teeth in? I didn't prepare these people for this question. Well, so, yeah, so not with like slightly related to server components, but what we're currently trying to implement is a suspense integration into React query that's built on basically passing the promise from use query back to the users where they can then pass it to the use operator to basically trigger suspense at any level that they want to. And this goes hand in hand with also creating the promise on the server and then streaming it down to the client and basically consuming it, like triggering the prefetching on the server and then consuming it on the client. Those are all things that are somewhat experimental, but also very interesting to wrap your head around, like starting a promise on the server and then sending it down to the client. I technically don't know how that actually works, but I think it just works at least in Next. So that's pretty cool. Personally, I really look forward to start playing more around with the data fetching part. In Redwood, we have this concept of a cell that uses GraphQL to fetch data, and we want to like our users, we love it, our users love it, and we want to have something similar for React components. So that's an area that I want to dive more into when our overall RCE implementation is more stable. Something that's exciting for me, and I think it can be possible with React server components, is I would like to see a relay solution for React server components. Now that we don't have to have the APA layer, we can access data from the components directly. It would still be nice to have a compiler on top of it, something related for GraphQL. And that might be something that we'll start exploring at EdgeDB. Yeah, you sort of teased that at the end of your talk already. Yeah. Are you getting to already work on that, or is that a next year's kind of thing? I think it's more like next year. But yeah, it looked very exciting. And it's a shame that we didn't have time to talk more about GraphQL because this is also some of the things I feel like with every revolution in technology, part of the old baby gets left in the old bathwater as we move forward, so to speak. I've been a big user of GraphQL over the years. So hopefully we'll get to talk about that in your Q&A in the Q&A room in a bit. Daishi? Yeah, this is something I keep saying today, but Waku is getting ready. It's still v0, but we are working hard to make it v1. But to make it stable, we need some collaborators, or at least people who has to try it to make it stable. So I really encourage you to try it out and give a feedback to us. Nice. Thank you. Well, what I look forward to is, I think this panel has clearly now convinced me that I am overdue for a mindset shift. And maybe next year will be me starting to actually play with this new technology and see what are the actual opportunities, because right now I'm just that cranky old man who feels like everything is shifting sand. So thank you all for working on creating that future. And then I hope next year to be more involved in it. So thank you for our panelists. Let's give them a round of applause.