Read on Twitter
React Server Components are all about APIs.
When you keep state in the client you are sending the data over one way or the other, there is no escaping it. Below the navigation fold you need to present new information. Only MPAs never are going to need the "static" parts. 1/
When you keep state in the client you are sending the data over one way or the other, there is no escaping it. Below the navigation fold you need to present new information. Only MPAs never are going to need the "static" parts. 1/
Now there are plenty of ways to lazy load that information. We can defer hydration. Use things like Intersection Observers. But if you ever return to the same route you will at some point you will be sending some serialization of the data/markup. 2/
So where are the savings? Well framework is there anyway, the interactivity/stateful stuff needs to be in the browser, and below the fold the template is coming one way or another. It's avoiding pulling in JS libraries to process data. Lodash, Markup, etc.. 3/
The truth is you could abstract a lot of that stuff into our APIs today. But we tend not to because our APIs are general purpose. We can't tailor them to each UI component. That would be crazy to maintain. But what if we could? We could put the heavy lifting on the server. 4/
And better yet what if it were automatic, and no more burden than maintaining our single application. That is what RSCs do.
In SPA-land Partial Hydration is just another way of doing less now to do more later. Lazy eval. But the real innovation here is automatic RPCs. 5/
In SPA-land Partial Hydration is just another way of doing less now to do more later. Lazy eval. But the real innovation here is automatic RPCs. 5/
That's something any framework can leverage. While putting a diff on the end has the promise of 0kb components. They aren't actually 0kb when you consider over the wire. And if they are truly static, their code should only be their template, which we have to send anyway. 6/
So breaking it down, RSCs are a couple things really.
* An approach to Progressive Rendering
* Autogenerated Component-Level RPC API
* A way of orchestrating the whole thing
This is great and really innovative way to approach SPAs. I hope to see more of this in the future. 7/7
* An approach to Progressive Rendering
* Autogenerated Component-Level RPC API
* A way of orchestrating the whole thing
This is great and really innovative way to approach SPAs. I hope to see more of this in the future. 7/7
