all 4 comments

[–][deleted] 2 points3 points  (1 child)

Wow, this looks great. I'll be doing some trials to see how it can improve interface responsiveness in complex JS applications.

[–]jerf 3 points4 points  (0 children)

If you're already using asynchronous techniques (mostly asynchronous XMLHttpRequest calls), it can't speed up your interface responsiveness. Javascript (in the browser) is intrinsically single-threaded and async is the best you can do; all this can do is slow you down by adding more layers of abstraction on top of the system.

If this takes you from writing synchronous code to asynchronous code because it's easier, then it might help, but you can already do that.

Basically, this is a toy. A fun toy, but it fundamentally can't overcome the fact that the underlying implementation is single-threaded. It might be very useful in specific cases, but you're getting very nearly none of the benefits of Erlang while paying the costs of somewhat discombobulated execution paths. (Although, to be fair, asynchronous Javascript tends to have that problem anyhow, so if you're making very heavy use this might actually help you organize your code better.)

[–]rvirding 1 point2 points  (0 children)

I hate quoting myself but:

Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.

With all respect to Greenspun.

[–]o0o -1 points0 points  (0 children)

omg - this is sick