[woven]

Good! This will quiet the noise, so that everyone can focus on advancing Dart and its ecosystem. Let's be honest: getting the Dart VM into non-Google browsers was always destined to be far, far away if not impossible, regardless of the team's excellent work or Dart's merits. Getting it into Chrome is just a decision, but one fraught with perils, namely that our community has an arguably healthy aversion to go-it-alone on the web, and untamed fear amongst the hoards that Google will shove it down our throats does not bode well for Dart.

And is it really worth it? As someone all in w/ Dart (I chose to build my product with it), dart2js serves me well, and the resulting JS is said to be more performant than raw JS. JS itself is improving (see ECMAScript 6 and TypeScript), which means Chrome's compiled JS will improve with it. Of course, having the Dart VM in a version of Chromium they call Dartium has been important, as it eliminates the need to compile until I care to test on other browsers. But there's exciting work ongoing on incremental compilation, so that in theory you'd just see your results in any old browser (http://goo.gl/EHJcK9) a la interactive programming. Bottom line: the Dart development cycle is already great and always getting better, no VM in Chrome needed.

As well, the Dart team can focus on more important priorities: the incremental compilation I mentioned, better JS interop (it's not bad now), improvements like async/await (coming in 1.9), even better concurrency primitives (see Fletch), Dart for native apps (again see Fletch) and more.

And remember, this decision can change later when the climate changes or other factors are in play. But for now, it makes a whole lot of sense to abandon any push, or notion thereof, to get the Dart VM into Chrome.

IMHO, Dart (I mean the language, libraries and tools combined) is hugely underappreciated. Folks will continue to focus on improving it and building awesome apps with it, and this news should quiet some of the noise.

[izolate]

As the dust settles around this announcement, I'm feeling more positive now than in my initial response. I don't think Dart ever had a chance to compete with JavaScript on the browser, especially as JS is advancing so rapidly with ES6/ES7. I'm a strong believer in what the future holds for JS.

But Dart is something else. Dart showed us what JavaScript would have been if it were designed this decade, and with some thought to its architecture. It's clinical in its cleanliness (have a peek at its standard library and you'll agree). It was pitched as a full stack language for web applications done right, and I certainly felt it lived up to that claim.

Personally, I'm more interested in Dart as a replacement for Node.js. Luckily that dream is still alive: "We continue our strong investment in Dart VM for server, embedded, and mobile."

[azakai]

> dart2js serves me well, and the resulting JS is said to be more performant than raw JS

Actually on most of the official benchmarks, dart2js output is slower than normal JS,

https://www.dartlang.org/performance/

(normal JS is faster on 3, matched on 1, and slower on 1).

Of course, the usual caveats apply regarding benchmarks and real-world performance, especially since those 5 benchmarks are fairly small and probably not representative of large real-world codebases. I'm not aware of any good benchmarks for Dart on that (there is a Box2D comparison, but the latest update isn't recent).

[bsdetector]

> (normal JS is faster on 3, matched on 1, and slower on 1).

And I would be really skeptical about that 1 where they say dart2js is faster.

They removed a layer of indirection in DeltaBlue when they ported it to Dart (not due to any Dart language feature, just for no reason), then crowed about how dart2js made DeltaBlue faster than the original. Despite being made aware of it years ago, they never fixed this! But the JavaScript VMs got better enough to be faster even though running code with more indirection than the dart2js version based on the optimized port.

So when the one benchmark dart2js is faster on is one they say they rewrote because a direct comparison would be "unfair" it sets off alarms.

[bsdetector]

Compare the source codes for yourself. It should be obvious that OrderedCollection exists in the js version, left over from the original Smalltalk, and not in Dart. Dart devs don't like criticism.

[callum85]

> the resulting JS is said to be more performant than raw JS.

This claim always bugged me. The output of dart2js is raw JS. Same with CoffeeScript (which makes a similar claim). So these claims are totally reliant on parameters that haven't been defined, ie. what constitutes "equivalent" handwritten code?

[WhitneyLand]

Right, I hope people making this claim realize it's not possible in principle for Dart to always be faster.

I've always assumed claims like this are implying that average case code is written poorly and that's how It could be faster.

However as you point out we'd need all the assumptions made clear to believe such a claim.

[jbergens]

it is up to every test to specify. I think they did explain what kind of hand written js they compared to and if I recall correctly the tests the dart team mentions is compared do js written by experienced js developers to solve the exact same problem. Of course there is a possibility that the hand written code could be further optimized but the comparison is still interesting.

[WhitneyLand]

What am I missing that makes this only a "possibility" rather than a certainty? For any Dart program found to be faster than a JS program, the JS program could be made equally fast by being equivalent to the Dart output, right?

[esrauch]

By going through the dart compiler first they can do optimizations that you wouldn't do by hand. Google runs all their js through their Closure compiler for this (JS -> JS compiler) with a ton of optimizations turned on (constant folding, method inlining, deadcode elimination, replacing of multiline conditionals with ternary operator, etc, some of which I believe are in the open source version and possibly some proprietary).

In that case, they literally are writing JS and using a compiler to get JS that is faster than any normal handwritten JS would be. You could write your JS that way but it would be completely unreadable and unmaintainable.

[WhitneyLand]

Thank you for the clarification. I think we are saying the same thing.

In principle, it's always a certainty that JS can be written as performant as Dart, never just a possibility. The possibility part only comes in with respect how optimally the JS code is written.

The interesting part here is I think is how often does this happen? How often can significant improvements be made that would be impractical, or even unlikely for a developer to match?

[esrauch]

I suspect that depends on your definition of significant. I suspect any legible code can always get a few percent speedup by doing things that would make it unreadable and unmaintainable.

[s73v3r]

"dart2js serves me well, and the resulting JS is said to be more performant than raw JS."

But is it more performant than raw Dart?

[bla2]

Maybe they'll build an asm.js backend for Dart.

[munificent]

Unlikely. asm.js, at least in its current form, isn't a realistic compilation target for GC languages as far as I can tell.

It may be possible to compile pieces of a Dart program that don't need GC (think pure numeric computation stuff) to use asm.js and use the full JS language for the rest, but I don't know if anyone's seriously looked at doing that.