I have never enjoyed dynamic typing; it has always seemed like TheWrongSolution™ to me. And Haskell really drives that home for me (i.e., it is possible to have a static type system with all the benefits that gives you without any of the headaches).
Additionally, I really dislike the trend of JS moving out of the web browser; it is incredibly easy to write impenetrable JS (particularly with the compile-to-js languages) which makes it much harder for me to understand what is running on my system, how to contribute to it and how to debug it.
Furthermore, JS is fast in comparison to other interpreted dynamic languages, but is quite slow compared to most native code (like the kind you would get with Haskell).
I am not trying to be one of the JS naysayers that gets into religious wars, but I will say that I am generally not a fan of the language, and the possibility of removing it from my life does seem like a net-positive.
But again, my intention is not to start a flamewar, simply answer your questions about my preferences.
I see asm.js and wasm as an evolution path. The same idea as JVM bytecode but twenty year after.
It can provide the cross-platform and ubiquity advantages to most of existing projects and languages.
What I meant was the idea that everyone is just waiting for JS to go away seems like you're extrapolating your preferences onto other people.
Though, if a significant number of people feel similarly to me (that there are better options than JS and that wasm could catalyze the move towards those better options), then I do not really see a problem with JS going away. Perhaps that is just me.
Again, I did not write this post with any intention of flaming or insulting those who like JS.
Are you sure that it's not some sort of stockholm syndrome? Or a case of plato's cave?
But, alas, I'm stuck with Javascript. For the longest time, we had to specify which language we were using as part of the script tag. Which was fine, as long as we specified Javascript.
Who invented that damn thing? Henry Ford?
Really? There are a plethora of JavaScript frameworks out there, mostly client-side but also some server-side, each with its own distinct culture, and new ones are coming out all the time. And each framework imposes its own way of doing things, and that attracts different types of people and creates a different culture.
In fact, the JavaScript ecosystem is so vibrant and diverse right now that "monoculture" is the last word I'd use to describe it.
If you want monoculture, look at Ruby. (Don't get me wrong, I love Ruby and it's my favorite language, but it's basically dominated by the monoculture of Rails.)
_frog is worried by a language monoculture, having to develop for a platform in only one language: the platform mandates the language. Other examples: Java for Android, Objective-C for iOS (Swift now).
You are worried by a framework monoculture, Rails dominating Ruby. That has no parallel in the JavaScript world. Other examples: iOS development dominating Objective-C and Swift?
The common worry is that monocultures harm their environment (JavaScript harming the web and Rails harming Ruby).
Given the success of Rails and the JavaScript-based Web one wouldn't say any of those type of monocultures are bad for making money (and look at real monocultures in agriculture and animal farming) but farming teaches that if you don't have enough diversity you are exposed to problems.
Being able to program the web in many different languages would be both good (pick the tool you like most) and bad (example: "sorry, I can't take over this webapp because it's written in OCaml and I only do Ruby and Elixir, find somebody who knows OCaml") but not different from what we always did when developing for the desktop and the web server. Both did well. If we're heading there we'll cope with that (customers will stick with the "big" languages, as usual).
* Javascript is verbose because it's plain text and was 'optimised' for human readability, rather than machine-parsability. That means parsing Javascript is expensive, too expensive for high-performance applications.
* Javascript's being a dynamically typed language means a single JavaScript variable may at different times represent a number, a string, or a fragment of HTML. Likewise, JS allows us radically to modify the behaviour of even built-in objects such as arrays. All this prevents the Javascript JIT compiler to optimise as aggressively as we'd like.
* Javascript currently doesn't provide viable concurrency which makes translating languages that do a problem.
Given that Javascript is the undisputed king of browser languages, and the difficulties with Javascript as compilation target are becoming apparent, I expect that WebAssembly support will be something of a priority for browser makers. I also think that, as you point out, VM design in general has mostly focussed on sequential computation, and concurrency is bolted on later. In part that's because concurrency is much harder, and the underlying CPU support for concurrency is in flux.
Also I don't think they are being unambitious by not wanting to learn JavaScript since all languages have many warts and learning all of the peculiarities of how to do the same thing in different languages is not going to make you a better programmer.
With wasm supporting VMs providing the same sandboxing and the ability to painlessly run more languages in the client, a lot of the incentive for running JS outside the browser will disappear for a lot of people.