I wonder if naming React Server Components as “ViewModels” (for real) would help with understanding and adoption. Sure, it’s not as elegant as “component”, but practically they are different enough in important ways, and pointing to similarities only adds confusion
i think the problem is that in practice the boundaries blur a lot because you can move the “use client” boundary a dozen times a day. so do components turn into view models and back when i do that? what about components imported in both worlds? they’re kind of serving double role.
s and such into view models (which is often useful!), the naming also starts being confusing. they’re not really two different things, more like two environments in which a component can run
How would you make Auth work with RSCs? By passing tokens to the ViewModels? What about cookies? I couldn't find anything related to Middlewares in the docs
i’m not actually sure what people do for auth these days but since RSC is essentially a restructuring of the API layer, i’d expect any the same way as you’d normally use for the API layer to work
In my experience this happens in 2 parts:
- Middlewares in backend (works for both cookies and jwt)
- Having something like an interceptor in front end for embedding the token information in the request headers(for jwt)
But I really can't find anything related to Middlewares in the backend.
I know lots of people who enjoy their lives in the hotwire ecosystem, and I dig the entire premise - but boy does it chagrin me that the whole thing is packaged as "not using much javascript". I feel bad for any new devs that believe this, because it cost me years w/ RJS back in the day.
yeah, anything that colours outside of the lines breaks the "not much JS" model, goes for any "framework" really. Hotwire custom JS is a bit neater than RJS though, boy that got messy easily.
For sure! Modeling it all around an actually restful base pays off a lot, it’s incredibly friendly stuff client side. It’s definitely fair to say a ton of common async use cases should just be reactive html elements at this point, I get the motivation behind deciding to say “this is stabilized” now.
CGI lost not because of the programming model but because per request process startup overhead was too much so it got replaced with mod_perl and mod_php which were more efficient.
I strongly agree with most of what you've written, but I hope we are someday able to combine the richer RSC programming model with the per-request isolation we used enjoy with CGI or even mod_php/mod_perl programming model. Hopefully WASM or TinyKVM will get us there.
I’ve read this post a couple times over the past few weeks, and it’s really helped put words to some concepts I’ve been thinking about over the past few months as I’ve been pondering htmx and some other web technologies that focus on hateoas. Thanks for the compelling read!
The aside on XHP was particularly helpful, in that it was a relatively concise explanation of the motivation for a lot of the more dynamic technologies. I know the article was long, but I don’t know what you could remove because it’s all so intertwined with itself.
I’ve always had difficulty with where do you store state in a web ui system, and having servers return hypermedia/components directly feels like a much more natural way to handle this than the alternatives.
This gets into the “React for Two Computers” article a bit, but one of my takeaways is that the server component of a UI should be considered part of the front-end. That is, BFF is a misnomer: it is part of the front-end. Attempts to create a firm boundary just make things worse.
Apologies for turning this into a stream-of-consciousness dump, there’s just a lot to digest here as I catch up on web technologies and design—I know much more about pure back-end development and am trying to branch out more.
No worries, I don’t think it was worth expanding the scope of the article to mention them, that was more about my background and where I’d started thinking about these ideas myself.
Great article! I really appreciate your comprehensive Overreacted posts - I vibe with how you present abstract ideas and directly address common headaches. It's been a hot second since I've enjoyed learning this much
Brilliant write down. I was nodding and smiling along the whole time, as it‘s basically a recap of my 25 years in WebDev. Except I never was at FB, so swap out the XHP for MXML (Flash 🙈)
Makes me want to try returning „RSC“-JSX from my Rails/Phlex app to load up a React frontend on the client. 🤓
Nice writeup! I found this very insightful and as always I enjoy your writing style!
I wanted to mention/discuss a seemingly minor difference but I think this is where the Relay/GraphQL approach kind of avoids performance pitfalls without extra effort:
In the final version, the example fetches the likes inside the PostLikeButton, but before this was fetched in parallel with the post at the top level. In order to do this with RSC, the parent component would need to know not to eagerly load the post, or have some other way to preload the likes.
Ah that idea of prewarming independent JSX elements could be an interesting way of approaching this. 🤔 Maybe the react compiler can do this hoisting in the future.
one thing worth keeping in mind is that RSC streams breadth-first by default. so it can do useful CPU work to compute and send the outer parts while waiting on the inner parts. this tweaks the tradeoffs a bit. you’re not just idling even if waiting on more IO.
i apologize for absence of GraphQL/Relay in the article (aside from a few passing mentions). it could’ve been its own “path” (and historically it was) but i’m not the right person to write about it, and i feel that it would also pull the narrative far enough that i’d struggle to bring it together
We are not using RSC at Meta yet, bc of limits of our packaging infra (it’s great at different things) and because Relay+GraphQL gives us many of the same benefits as RSCs. But we are fans and users of server driven UI and incrementally working toward RSC.
This is lengthy, but very tidy and comprehensive, I love it! The only missing piece is server actions, which I hope will come soon and be as good as this!
It's really interesting to see what is happening to RSC. With JSON JSX we don't have to explicitly define our (reading) API and instead have a generic format that the client understands. Almost like plain HTML APIs for Browsers.
there are lower level React APIs that Next itself uses for this but i don’t think they’re directly exposed by Next.
if you’re actually using Next, you should be able to return JSX from a "use server" function. then await’ing it should give you a React element you can render
Comments
just two cover pages are missing rest it is complete book.
Did you heard about Inertia ? I think it would fit the need you express here.
I wonder if naming React Server Components as “ViewModels” (for real) would help with understanding and adoption. Sure, it’s not as elegant as “component”, but practically they are different enough in important ways, and pointing to similarities only adds confusion
- Middlewares in backend (works for both cookies and jwt)
- Having something like an interceptor in front end for embedding the token information in the request headers(for jwt)
But I really can't find anything related to Middlewares in the backend.
This would work elegantly if we had createContext support on the server but I think that's not the case.
(also again no way to get cookies on the server)
Makes me want to try returning „RSC“-JSX from my Rails/Phlex app to load up a React frontend on the client. 🤓
I wanted to mention/discuss a seemingly minor difference but I think this is where the Relay/GraphQL approach kind of avoids performance pitfalls without extra effort:
I know this is a minor improvement in this example but it could add up in a real scenario if not taken care of.
Curious if I'm missing something in my assessment of RSC for this example!
one is what Next does — parallelizing route segments and treating them as different RSC roots. this helps somewhat although not all the way down.
if JSX prewarmed renders, you could have a compiler hoist independent JSX
imo, the article gave me more about the view on the evolution and possible future of the "microfrontends concept" than about RSC itself
Does it require special handling?
@danabra.mov
if you’re actually using Next, you should be able to return JSX from a "use server" function. then await’ing it should give you a React element you can render