And what about server developers using Node.js?

I thought the point of Node.js was that threads were too complicated and rendered unnecessary by asynchronous event loops that do message passing between processes. Are the Node people finally giving up on this trope?

Is there any limitation or reason for not implementing WASM on nodejs?

Of course not, and hopefully it will come to V8, but its mere existence does not preclude enhancing JavaScript, any more than the existence of PInvoke or JNI precludes enhancing .NET and Java.

When people say "JS shouldn't support feature X", when feature X is supported in every other serious language, I can't help but guess that their real problem is with JS itself, and they just don't think people should be using it at all. Fine, if that's their opinion, but they should come right out and say it.

Well for me it adds complexity to JS. One nice thing about JS is that it is single threaded and you don't have to deal with locks or inconsistencies there. An entire class of problems goes away, and since JS event loop is reasonably fast as it is, it's pretty nice not having to worry about concurrency.

I would think that it's owing to the frequently single-threaded context of JS that concurrency becomes even more vital for maintaining the liveliness of your app. I also think that identifying aspects of concurrency often means free parallelism speedups, and the user doesn't even have to be aware -- no extra mental price.

So true!

Lots of people actually like using JS. I think it makes sense to understand what features can be added to this language.

What's the point? Why not write your server directly in say Python or Java then?

I thought WASM is meant to get around the restriction that the browser only understands JS right now.

> why not use X

Because X doesn't run in a browser

Do you need to run your server in a browser?

No, but it's very nice to be able to share code for things like view rendering or form validation between the server and client without jumping through hoops.

So you use language X. Compile it and run it natively on server, compile it to wasm and run that in the browser.

Why should i use language X that i don't like, instead of nice dynamic language, without compilation step that i like, and which only misses this tiny feature?

There may or may not be, but that doesn't address that Node.js was created to specifically avoid a threaded concurrency model in the first place.

Is there any limitation of reason for forcing people to rewrite their Node.js apps in something else just to get modern features?

in this case, yes, a feature that breaks backward compatibility.

So someone suggested rewriting in another language, since the new feature will not fit the only advantage nodejs have: same language as browser. The alternative is to rewrite in a type of JS that will not run on the browser either.

Te proposal for concurrency in the post does not break backward compatibility.

No. In fact, AFAIK it's already implemented on Node, behind the --expose-wasm flag: http://thecodebarbarian.com/getting-started-with-webassembly...

Right! It can't be the all of the cool features are done in wasm, which doesn't even have a GC yet.

WASM is farther along than concurrent JS though...

That's true. But most of the web is written in JS, not wasm.

If you have crazy high performance stuff you can do it in native modules.

Depends on what you're doing, but if you just want to take advantage of multiple cores you can already accomplish that with `cluster`.

I remember when people used to say "you don't need threads, just use fork"!

What do they say now, out of curiosity?

Now they say use fork-join. ;-)

Point is, some people don’t like threads and probably never will. Other people like threads and probably always will. Some languages have threads and many other programming models and then everyone is happy. I want the people who like threads to be happy in JS.

I need concurrency to parse and prepare streamed 3D data while keeping the main javascript/render thread fast. WebWorkers are already very useful in that regard.

Obligatory plug for Browsix (http://browsix.org), "Unix in your browser", which already provides concurrency via Unix-like processes and IPC. Processes can communicate with sockets & pipes, and run on separate WebWorkers. (Also, you can directly run complex C/C++ applications that expect a Unix environment.)