I'd much rather they keep holding off. We've had more than enough of big companies fragmenting the ecosystem by making their own languages, file formats etc. because they can. As things currently stand, Dart compiles to JavaScript, which is exactly the right way to do it; that way it's a tool that's available if you want to use it, but it doesn't screw up interoperability.
>As things currently stand, Dart compiles to JavaScript, which is exactly the right way to do it
That was never going to change. The idea, as far as I understand it, is for Dart to be executed natively where there is a Dart VM. Where there isn't, the dart2js output would be executed. The DOM itself would be unchanged. I think that's reasonable. In fact, more than reasonable, that's just a good idea.
The danger is that the VM has different semantics (for example, integer overflow) than dart2js code. If the same dart code sometimes runs in JS and sometimes in the dart VM, people are going to hit weird bugs.
Also, if it is possible to ship dart code by itself - without the JS fallback - then we are going to see sites that don't bother with the JS fallback, and those sites are only going to work in chrome.
For both of those reasons, the dart VM is somewhat worrying from the perspective of the openness of the web.
A lot of those objections could have been applied to SPDY, a protocol google developed unilaterally and initially was only supported in Chrome and Google sites. The end result was that everybody else got a regular experience while Google Service <-> Chrome users got a better one. Other sites started including SPDY, and then browsers got in on it as well. Seemed to have worked out well.
I don't see how Dart would be any different. You can cook up worst-case hypothetical scenarios in which Dart-only sites exist because the developer was OK with cutting off half his customers, and was too lazy to generate the js output (it's not like there are vendor-specific prefixes, and even technologies like WebGL, or WebRTC that don't work universally in all browsers).
>For both of those reasons, the dart VM is somewhat worrying from the perspective of the openness of the web.
In the absolute "worst" case, Dart (an ECMA standardized language at that point) becomes very popular and forces other vendors to include a Dart VM. I'm willing to live in such a world. More likely, Dart becomes a complement to JavaScript when it comes to building RIAs in the browser (because JS is really really bad when it comes to writing and maintaining big codebases), though JS still reigns as King of the Web.
SPDY does have some similarities, but the differences here are very large.
As I said, Dart runs differently in the VM and in dart2js. SPDY was just not present in other browsers at first. So there wasn't a case of sites breaking in subtle and hard to debug ways in SPDY, but there is in Dart. (Later, when other browsers started to support SPDY, there were the usual spec issues, but that's a separate matter.)
The second issue I raised was that someone could ship Dart code alone, without the JS fallback. In that case, it is indeed more similar to SPDY, as someone could in principle write a SPDY-only website. Even here there is a difference, though - SPDY relies on client+server interaction. Dart is client-only (there's a Dart server, but that's not relevant here). Client-only code can more easily stay on the web for a long time, possibly forgotten and unmaintained. But this might be a small difference, so I somewhat agree with you on this point, but disagree on the previous.
Do you have any example other than integer overflow?
It's the only difference I've ever heard referenced.
The Dart team spends enormous efforts on maintaining JS-compatibility, so much so that it rejects adding any language features that can't efficiently compile to JS.
Another example where the VM and dart2js differ is, as others linked to elsewhere in this discussion, that dart2js relies on undefined/unspecced behavior in browsers,
Here is a question to consider: can the web where you can't efficiently[1] implement any dynamic language with a semantics different from JavaScript be called truly open?
[1] I am well aware about different attempts to attack this issue from various angles from AOT to JIT generating JS code but no attempt currently produces truly efficient solution that demonstrates small footprint and consistent high performance on par with native VM across all of the web or even across its relatively modern part.
First, you're using "open" in a way I haven't heard before (not in the context of "open web"). Not saying it's wrong :) Perhaps we should use it that way too. But you're suggesting a new perspective here. We could debate that first, before debating the technical stuff. Or perhaps we could call it "technologically open."
But to focus on the more interesting technical stuff: First, we have a fast Lua VM port. Not LuaJIT, but even the Lua VM itself is quite fast for a dynamic language (and the port is 2/3 of native speed).
Second, there are experiments with JITs targeting JS, like pypy.js. Yes, pypy.js has a large footprint, as you referred to. But I think the fact is that very little effort has gone into this. Much more is possible than has already been done.
If we had a large, serious project doing this, I think we could see the potential. Instead, things like pypy.js are spare-time projects of a single person. So it's not fair to assume that their success or failure in terms of performance and footprint is indicative.
It's my understanding that Shumway is basically a full-scale AS2/AS3 VM & JIT using JS as the codegen target, is that wrong?
JSIL is increasingly a JIT that targets JS instead of an offline JS compiler, if only because JS runtimes are so terrible at optimizing C# code and semantics. Eventually it may end up being like Dalvik, where the offline compiler runs a filtering/transform pass on the input bytecode and all the actual codegen happens on the client.
Hard to be sure, as you pointed out it's hard to do serious CS research like this as one person in your spare time :-)
Thanks! I forgot Shumway. Last I heard it was competitive with the Flash runtime (better on some stuff, worse on others), so that seems like a clear counterexample to mraleph's concern.
Isn't Shumway more of a confirmation for my concern than a counter example? Shumway is running ActionScript which is extremely close to JavaScript semantically though somewhat more strict and allows for optional typing.
