[msie]

I was at last year's Google IO and a lot of people were asking the Dart representatives about whether Dart was going to be supported in Chrome (not just Chromium). We were told the team was holding off because of performance considerations. It has been ONE WHOLE YEAR since then.

[mda]

There were changes needed on Blink side (Oilpan project) and this sort of things take time.

Oilpan project: https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6...

You can track Darts's performance here: https://www.dartlang.org/performance/

[rwallace]

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.

[macspoofing]

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

[azakai]

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.

[macspoofing]

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.

[azakai]

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.

[mythz]

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.

[azakai]

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,

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.

[mraleph]

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.

[azakai]

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.

[kevingadd]

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 :-)

[msie]

Yes, let's not innovate on the web anymore. Why was Chrome invented in the first place? We all should have stuck to IE 6 and Navigator. For openness.

[higherpurpose]

Chrome already comes with NaCl which nobody else but Google uses it. Do we want another VM inside Chrome that nobody else will adopt?

And now they're putting Android inside ChromeOS, too, just because they don't want to admit Android itself would work better on notebooks (given the right interface) than ChromeOS.

[comex]

Why do you want it to be supported in Chrome? Any performance improvements seen by your users won't apply to those using any other browser.

[rdtsc]

> Any performance improvements seen by your users won't apply to those using any other browser.

But it will apply to those using Chrome (their performance benchmarks show consistent improvement, sometimes up to 2x) and it will be using a better language for all the other ones.

[Igglyboo]

Because then his userbase goes from being an extremely small niche(chromium is probably less than 1%) to a much larger niche(chrome is more than 30%).

[rational-future]

Do you mean that Chromium now has a Dart VM? The last time I checked it didn't, there was a buggy thing called Dartium.

[gsnedders]

Dartium is still separate to Chromium.

[munificent]

Dart -- without being in Chrome -- has the same userbase as CoffeeScript, ClojureScript, or any other language that also compiles to JavaScript.

There are some real potential wins with being in Chrome, many of which are political, but there are no technical reasons for not being in Chrome to block Dart's adoption.

[Igglyboo]

Except Dart isn't trying to be another "compiles to javascript" language like CS, Dart is trying to completely replace js which is why it's so much more difficult to implement. They have to build an entire VM to rival V8.

[spankalee]

The point is that if you write in Dart you still have a very large target audience without the VM.

Sure, Dart's designed to have even more benefit when run in it's own VM, but that doesn't affect its reach.

[ahoge]

> Any performance improvements seen by your users won't apply to those using any other browser.

It will be still about as fast as regular JavaScript.

[adrianlmm]

I will say that you won't need to rely on JavaScript, .dart files size are a lot smaller and the code starts and execute faster.