| I don't agree. The mission is to be a dom-scripting language http://luvv.ie/mission.html I didn't just pluck 9 out of the air, it comes from thinking about how I would structure applications that I have written. Take for instance our online spreadsheet - very complex GUI - 2,500 divs - but when you ask what are is the concurrency - what are the discrete functional data models that I need to manipulate - the number is low: * a menu bar
* a toolbar
* a tabs bar
* a grid
* the cell input overlay
* 5 or 6 dialog boxes
The grid is endless scrolling set of spreadsheet cells and behind the scenes it is pre-built panels of 20x20 which are 'next-but-one' assembled on the fly for smooth scrolling.Even if you break the grid out for max concurrency - you only add another 8 or 9 concurrent data models. 9 - 29 Web Worker processes for a page sounds liveable with. With regard to restart and supervision I really do mean the Operational Supervision that Erlang/OTP supervision does in terms of handling errors. 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. Page refresh covers most of what you might ever need. 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. |
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).