react-stdio's deficiencies (from tweet):
JSON is a great format to send to the browser because it's so widely supported. However, on the server-side, it is quite unnecessary verbose and requires push-down automaton to parse. Some formats build on JSON data model (Msgpack, BSON) and provide binary (de-)serialization, i.e. less bytes has to be serialized, less sent, less read, they will be faster, they would be more suited for this use case. Also on the server, more bytes sent might not be the worst thing, so formats like FlatBuffers or Cap'n'Proto would be probably the best performance-wise. JSON cannot represent directed acyclic graphs (I would say data underlying most UIs are DAGs), only trees. To transfer less data some kind of normalization (as JSONGraph or gaearon/normalizr) might gain speed.
Because react-sdio reads requests from standard input line-by-line, it can only write responses to those responses also line-by-line, otherwise the application would not know which response corresponds to which request. It means single slow response blocks other fast responses to be returned back to the client.
Modern application protocols, to be efficient, almost always implement some kind of framing and multiplexing. Good examples are HTTP/2, Thrift protocol, or TChannel. Even "old" protocols like FastCGI use it.
Request in this context means request to render some component initiated by the app. Once one render process is created it is tightly bound to its parent process, because communication is performed using stdin/stdout. Therefore the pool of render processes has to be managed by the app. For example it cannot be Docker-ized to separate container.
This should not be the app's responsibility, it should be handled by separate system component (also managing the app itself, e.g. supervisord, monit). I know, Erlang VM + OTP has supervision trees baked in, however for other platforms like Ruby, Python, PHP, this is not the case.
Sockets were invented exactly for this use case, why not just use UNIX/TCP sockets.