story
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.
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.
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.
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.
https://code.google.com/p/dart/issues/detail?id=13285
In other words a dart2js app can break after a browser update, fail to run on a new browser that is fully standards compliant, etc.
[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.
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.
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 :-)
