alt Hacker NewsOne of my biggest gripes about this is that the wire format for React Server Components is neither standardized nor documented. Every bundler has its own format [1], but what this means in practice is that every bundler wants to be able to "move fast and break things" and treat the format as an internal implementation detail, which in turn means that there's no reference implementation and no way to have interop between, say, a RSC "backend" and a non-JS-based frontend (or crawler/scraper), or to have a non-JS backend emit RSC-compatible updates. Or to be able to allow people to iterate on it with fresh JS server-side code, rather than needing to build around a bundler.
If I want to make an Erlang or Rust based system that emits RSC-compatible updates (which itself is an undefined statement) in real time, say - there's no way to do that without either having a JS layer as a separate microservice, or calling the code from JS in some way.
The PHP analogy is very much earned, in my view. It doesn't make it a bad choice for all projects, but it will tend to isolate the ecosystem from new directions.
[1] https://overreacted.io/jsx-over-the-wire/#server-and-client-...
Replies
Sounds like you need a 14th bundled but built with some liveview code.
Nothing about the RSC format is privileged in the React client (i.e., react + react-dom). You can always make your own serialization format as long as it can represent React elements and promises somehow. You can of course also use the RSC wire format and pin to a specific client version (or vendor/fork it) but it’s not a stable format today because it’s not clear if many people would use one and we want to leave room to improve the format as new optimization opportunities arise.
Though you do lose a lot of the magic if you don’t have JS on the server at all. Part of the core proposition of RSC is that it’s easy to move logic across the boundary as your app evolves. What goes over the wire can be a performance decision instead of a “that’s too much of a pain to move to the other side I’ll just leave it” decision. For that reason I’d generally make a thin “backend for frontend” in JS that talks to an Erlang/Rust/etc backend. It’s conceptually part of the frontend but runs on your server.