

Quick thoughts on concurrent JavaScript execution - bss
http://qni.dk/2011/06/quick-thoughts-on-concurrent-javascript-execution/

======
skimbrel
Interesting read. When it comes down to it the answer seems to be that
JavaScript needs to have support added for explicit parallelism. But isn't
this what we're supposed to get with HTML5 web workers? It shouldn't be hard
to write a utility library to implement parallel map, reduce, and so on in
terms of spawning workers, falling back to serial execution if the worker API
isn't available.

In either case, this will require a rewrite of every piece of code that needs
it.

Speeding up/backgrounding the JIT compilation phase is a transparent
optimization that I'm sure some smart people at Apple, Google, and Mozilla are
already working on.

~~~
asolove
You hit the nail on the head. JavaScript is just not built for shared-data
concurrency, but passing data back and forth to web workers provides a way to
speed up computation-intensive tasks, decouple long processing times from the
UI event loop, without changing the language itself.

