Architect – Your Web Workers’ Supervisor(github.com)
github.com
Architect – Your Web Workers’ Supervisor
https://github.com/EtienneLem/architect
2 comments
Is there much to gain in running ajax requests in web workers?
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 for an example.
See "Example 4" at http://www.masswerk.at/plexer for an example.
Sencha uses web workers for ajax calls to move it away from the UI thread, for its Fastbook web app http://www.sencha.com/blog/the-making-of-fastbook-an-html5-l...
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.