In node is it very easy to fork processes and have them communicate. Scripting languages for serving HTML and JSON aren't the place for threads.
Node now offers sync versions of most IO functions as well.
In node is it very easy to fork processes and have them communicate. Scripting languages for serving HTML and JSON aren't the place for threads.
Node now offers sync versions of most IO functions as well.
JS has nice fast runtimes, and crucially the ability to share code between client and server. I think there’s potential (even without threads) to have a JS server architecture that does not require the entirety of a request/response to be processed in a single thread but could break it up so it could be processed by a pool of workers at IO event boundaries. Either as one isolate per request or explicitly passing state for IO event callbacks.
If your JSON payloads are large, you can't have a forked process do the deserialization of it (because you would need to re-serialize across the communication boundary, which defeats the point).
I think it would be reasonable to have immutable data structures shared with web workers. I also think it would be reasonable to make it possible to pass complex objects (all primitive types supported by JSON) between workers without a serialization step.