If that is your goal then I dont want to clame that you have not achived it. This looks quite good for many things, my point is however that I mayself would not want to restrict myself this way.

In the future we be able to directly go from one browser to another, we might query or get messages from tons of diffrent servers, the OS might send us events and so on. More and more, the browser becomes a application deployment target.

> 9 - 29 Web Worker processes for a page sounds liveable with.

The question is not really if I can live with, the question is if I want to.

It just seamst to me that, when light weight concurrency is good on the server we should also use it in the browser. Seams to me this would help with the idea of using simular programming models on both ends.

> I don't see how the sophisticated restart and fail-over strategies that you might have in a 50-node server cluster will ever work. The user is the consumer, and they are in front of their device, failing over to another browser is not an option.

I can imagen many things. Lets say a you inplment some game or simulation where you have threads of executuion doing some calculation and maybe rendering themselfs on the screen. Now it would be nice to have some sort of fail-over system that might monitor all these and can potentially restart them, maybe get some information from the server or internal data store, maybe it is required to shut down all the other threads and restart them as well.

Maybe you stop getting messages from the server, and you have to restart the server or go and search for another server. Maybe you have to get a message from the server, informing you that it is shuting down and internal storage should be used.

I can image lots of things, and I dont know why I should restrict myself by design.

> I don't know what CSP is, so I can't really comment. I also don't really have any knowledge or desire to support gaming.

CSP is what Go implments (or core.async library in clojure).