

Architect – Your Web Workers’ Supervisor - EtienneLem
https://github.com/EtienneLem/architect

======
IanCal
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_.

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

~~~
masswerk
You could load your data and have it processed while other assets are still
loading. Later the same worker would liberate the UI-thread from model-jobs
and keep the UI responsive.

See "Example 4" at
[http://www.masswerk.at/plexer](http://www.masswerk.at/plexer) for an example.

