Hi,

Is RSC a data protocol or an architectural design? I had a similar question when I started developing Waku, or even before that.

Early Motivation

As a library author, my interest was the serialization algorithm. Actually, I made a library called react-worker-components, which includes a homegrown serialization algorithm supporting references. So, my first goal with Waku was to wire up RSC's serialization capability into something usable. It was like a DEV-only playground for RSC.

Adding Production Build Support

Later, it introduced bundling thanks to Vite and many custom plugins, which can generate a production build.

Around that time, while discussing with someone at the React team, I noticed RSC was a broader concept. For example, an RSC framework shouldn't encourage some bad practices like client-server waterfalls, which is one of the biggest problems RSC was trying to solve. So, I changed Waku's API so that it eased, or more or less forced, a single round-trip request and response API.

Library Interoperability

Another example is library interoperability. There's a library called react-tweet. It's a pure RSC library and is not tied to Next.js. Many fixes have been done in Waku to support it and similar libraries.

Another library to tackle was the AI SDK. It uses RSC extensively, and it was challenging, but we made it work.

RSC as Architecture

Nowadays, React docs include RSC stuff, and it's clearer than before that RSC is not just serialization logic, but the entire architecture with best practices. That said, I think there is still room for more documentation.

Waku should be a full RSC framework. If you find some bugs, feel free to report them.

Happy coding.