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...