I think "no parallelism and shared objects" was one of JS best design decisions, as it really fits the event-driven (and thereby callback-driven nature of the t

I think "no parallelism and shared objects" was one of JS best design decisions, as it really fits the event-driven (and thereby callback-driven nature of the target systems and avoids lots of errors. I can't count how often I've seen illegal accesses from callbacks in Java in C#, partly because the people didn't even knew that the callback would not be invoked from the main thread. I don't think that web workers and the shared arraybuffers will make that worse. It's a tiny loophole that let's one exploit parallelism for a number of very specific use cases. For the average UI it's far too complex to use, since it does also not directly allow sharing objects but only byte arrays, which means users would need to care for serialization. So the possibility of misuse is low. For a specific set of applications (audio/video processing stuff, game engines, thinks that are cross compiled from C++) it could be an important building block that allows to exploit parallelism there. And I think in these use-cases the implementors would more likely know what they are doing when the shuffle bytes around.