Hi Framework Authors,
This post is not about criticising the adoption of React Server Components. I am not out to start a discussion on it. Rather would like to share some thoughts about the current state of RedwoodJS an express my concerns about how RSC may affect the framework.
Since NextJS announced their support for RSC we saw many people stating “This is just like PHP all over again”. Anyone that worked on serious PHP applications knows that this is not really the case. I think what they are really trying to say is: The concepts are too tightly coupled and has no clear separation of concerns. Something RedwoodJS shines at.
With a clear distinction between server and web, cells for datafetching, compartmentalised generators and other good practices i’d say RedwoodJS in its current state has achieved a high level cohesion. To me this is the biggest quality this framework has, because it allows for the framework to be fully featured and opinionated, yet flexible enough to adopt with a wide range of use cases. Qualities that competing frameworks are lacking.
As someone who embraced RedwoodJS for projects I naturally am concerned about it loosing these mentioned qualities when transitioning to RSC, namely when adoption looks similar like NextJS’s. I hope that this post allows for some consideration.
7 Likes
I’ve been spending some time thinking through this as well. I feel like I got to a different conclusion and just figured I’d share my thoughts.
I’ve been working with nextjs and RSC for a couple months. There has been a growing move in some frameworks, like Next and Remix to remove the separation of concerns by having everything happen in a single file.
However, I don’t the RSC are well suited to this and I believe Redwood is actually a better suited structure for RSC.
By already having things like Cells, Components, etc. I think the separation of concerns present in Redwood make it a fantastic choice to adopt RSC. In my mind, and I know there are more nuances to it, but in my mind, Cells can just be Server Components rather than graphql calls unless you need it to be a client component take advantage of graphql.
I don’t know how much work it will take but I think this can be done with the really great scaffolding/generator commands redwood has.
And my last seemingly unrelated thought is that Redwood will be one of the better educational places for RSC’s. Honestly, I feel like it could even be a cheat way, if you are working with another framework, to generate/scaffold Components and plop them into another code base.
8 Likes
I don’t want to add much more to this other than to say this post and replies are pure gold. We’re taking note and open to more! Thank you for trusting us and putting this out into the public discussion. 
We (the Core Team) welcome more of this:
- what else are you concerned about… what would “doing it wrong” look like?
- what possibilities are you excited about… what’s your vision for how this could be a win for your workflow and project (including use cases)?
3 Likes