Architect – Your Web Workers’ Supervisor

If you're going to look at creating supervisors for web-workers, I encourage you to look at how Erlang deals with this. It's got an exceptional set of standard libraries for managing large numbers of possibly unreliable threads, and it should really be what we're aiming to get to.

I can see the evolution of this already:

* Web workers

* Web worker supervisors

* Realisation that supervisors might die

* Invention of a supervisor tree. Thousands of articles describing how they've implemented it with a catchy name and slightly different semantics.

* Restart strategies. More articles, with different ways of achieving the same thing. Someone invents library called defibrillatr.

* Heartbeat from some core JS module.

* At some point a reasonable programming model emerges and basically all work is moved into these threads.

* Realisation that we're making the same server-client model again and again, standard library is created to deal with this code repetition.

* Finite state machines, etc. added

Can we jump through this somewhat? At least, I'd like to identify where web workers can't match erlang (signals from dying threads?) so we can work out where it's possible to reach in this, then jump right there. Almost all of this is the OTP in erlang, which is just libraries and common code (I'm not sure about exception passing, etc). It's battle hardened and really good.

Is there much to gain in running ajax requests in web workers?