Web Workers are true threads, it's just the shared memory part that's missing. I think we will have to introduce some form of it at some point, and there are ways to do it but there's definitely a lot more research required (think about only allowed a typed array to be shared, with atomic reads/writes). I don't really know what's going to happen with this feature, and it is the one single thing that's going to be hard to do in JS, but I think we can solve it and there's really nothing else missing (or isn't planned to be implemented).
>Web Workers are true threads, it's just the shared memory part that's missing.
And thank god for that. I've never understood the fetish C/++ programmers have for shared memory, and locks, and mutexes. Erlang has a much saner approach to concurrency/parallelism, and web workers isn't terribly far away from Erlang's actor model.
EDIT: That said, I thought about the idea of only allowing typed arrays to be shared, and I actually really like it. I think that's a sane way to approach shared memory in JS, and it could cover some of the use cases that web workers aren't a big help with.
A lot of languages that claim to have "borrowed" from Erlang often borrow the "concurrent unit running independently communicating by a channel or mailbox" idea. Very few borrow the most amazing part -- isolated heaps for each of the lightweight processes. Web workers and Dart isolates, have that as well. I am not claiming they borrowed from Erlang, just saying they have that nice feature.
See, fault tolerance was actually the #1 priority when building Erlang not high concurrency. High concurrency was there too but it was #2. Also the tough part is selling fault tolerance. Only those that have implemented large concurrent systems using shared memory models, plagued by dangling pointers, large mutable state in the middle of everything moving around, and have it fail will appreciate fault tolerance. Most will shrug it off -- "hey look, I can run language shootout's Mandelbrot 10x faster!". There is a trade-off there, of course. Just like in a real OS. If you want to fork separate processes for each request, you'll pay for fault tolerance in performance some, if instead you'd just called a callback in the same process.
> I've never understood the fetish C/++ programmers have for shared memory, and locks, and mutexes.
There are some problems which are more amenable to shared mutable memory, especially when performance or memory space is a concern. And for those problems where the sharing of mutable data is not needed, forking, pointer ownership, thread-local data, and const correctness are all old concepts.
Fair criticism. But the idea of a shared typed array is appealing, just for the simplicity. If you must have shared memory in JS, this is not a bad way to do it.
Web Workers can actually let you pass messages at the speed of shared memory, thanks to an optimization, when using typed arrays with "transferables". So you can fling around buffers straight from a worker to the main thread without copying, pass it to WebGL without conversion etc.
(The sender loses access to the buffer after it's sent, so it's still safe)
"...at some point, and there are ways to do it but there's definitely a lot more research required..." Maybe it's better to abandon the whole legacy JS platform and move on to something that doesn't slow down innovation?
Competing platforms/ecosystems slow down innovation? I would say we need at least a couple of strong JS contenders to get the most benefit. The Central Bureaucracies such as W3C make change (granted positive or negative) slower.
>Competing platforms/ecosystems slow down innovation?
Yes. That's what killed the vision for massive adoption of desktop Linux for one thing.
That's what hampered a good Java web story (tons of competing frameworks).
It's why there are several slow scripting languages (Python, Ruby, Perl, etc), whereas Javascript got crazy fast as the only game in town when it comes to the web.
The reverse of that (Rails as the "one true framework" instead of tons of competing stuff) is what helped Ruby make waves.
Especially when the "competing platforms/ecosystems" are needlessly competing. It's a waste of effort, people duplicating features and stuff.
>The Central Bureaucracies such as W3C make change (granted positive or negative) slower.
The central bureaucracies are actually "competing platforms/ecosystems" too, only they are competing for inclusion in the one same standard. MS, Apple, Google, Oracle, IBM etc each wanting their own APIs and changes to the final spec (which is slow).
Most progress has been made by ONE SINGLE company going at it and inventing something new on their own that others adopt more or less wholesale (e.g Apple with Canvas, MS with AJAX, Mozilla with asm, etc).
Constrast that to each of those companies having its own competing technology for the same thing (e.g different canvas drawing APIs) instead of adopting one and being done with it.
You are describing competition within a platform, which is happening in JS as well: EmberJS vs AngularJS vs KnockoutJS etc. Do you really think this kind of competition is bad?
I am talking about competition on a higher level: e.g. Ruby on Rails vs ASP.NET vs JSP. RoR was not the first one. Do you really think this kind of competition is bad? Was inventing Linux a bad thing because we already had other OS's?
"company going at it and inventing something new on their own" - the very definition of competition: generating something new to get a competitive advantage (new platform, new technology, new framework).