Since Dart never went anywhere adoption-wise, and even abandoned plans for its own VM in browsers (not to mention its purpose obsoleted by the announcement of WebAssembly -- since devs will be able to use ports of much more established languages for web programming).
And since Google-made Chromebooks never sold well, and those by third parties (Acer, Samsung, etc) don't make much money for their manufacturers and no money at all for Google, and all constrained to the niche educational market (schools buying them for their students).
> since devs will be able to use ports of much more established languages for web programming
Sure, they'll be able to use any language they like, as long as it's C or C++. :)
There is currently no story for using any high level language (read: language that uses GC) like Ruby or Python as a web language by way of WebAssembly.
>There is currently no story for using any high level language (read: language that uses GC) like Ruby or Python as a web language by way of WebAssembly.
Actually that's part of the whole point of WebAssembly -- as Eich put it. It's not just to speedup emscripten style ports of C/C++ programs.
Eich's words: "Bottom line: with co-evolution of JS and wasm, in a few years I believe all the top browsers will sport JS engines that have become truly polyglot virtual machines".
I understand that's his goal, but I believe actually getting there is quite a ways off and may ultimately never happen. Of course, you can never say never on the web, but going from supporting C/C++ to supporting, say, Ruby or Python is a pretty fundamental change in how the system works.
A modern GC is a large, complex beast. Python, Ruby, Lua, etc. all have their own implementations of them, and those implementations are specific to the semantics of those languages. (For example, Python's early finalizers. Ruby's FFI, etc.) That's a big blob of code for you to push down the wire with your application every time the user hits your site.
Also, that GC doesn't know how to play nice with the browser's own GC. If you have an event handler that has a reference to some Ruby object that in turn has a reference to some DOM node, neither GC can trace through that path and tell when those objects can be collected. That means you get memory leaks.
On top of that, the language implementation itself is large. The Python executable on my machine is 2 MB. Do you want to add another 2 MB to your app? Is Python enough better than JS to justify forcing all of your users on their crappy mobile networks to download that before any interactivity begins on your page? What about when you start using the additional 45 MB of standard library that comes with Python?
Also, how do you make those standard libraries work in a browser? Who is going to rewrite them all to stop using the native OS libraries they currently use and instead rely on APIs that are available in JS?
That's not to say this is an insurmountable problem. But my belief is that it's a big enough headache to outweigh the benefits you would get from writing your app in another higher level language.
Now, if your language can compile to JavaScript and has a decently small runtime library, that's a different story. At that point, you're back to only one GC and relatively little overhead for your language's semantics and core libraries. It means you don't have to worry about a large existing standard library that #includes everything under the sun.
This is why I think CoffeeScript, ClojureScript, Dart, etc. are feasible. But I don't think anyone will be writing web apps in Ruby or Python anytime soon. Languages that look syntactically similar to them (Opal, Red, Pyjamas, Brython, etc.), sure. But the real deal where you can have some app that does, I don't know, "import requests" and have it actually work in a shippably-sized web app? I think that's going to be a much harder path.
It's a great goal for the WebAssembly folks to work towards, but it's an aspirational goal.
And since Google-made Chromebooks never sold well, and those by third parties (Acer, Samsung, etc) don't make much money for their manufacturers and no money at all for Google, and all constrained to the niche educational market (schools buying them for their students).