
“We have decided not to integrate the Dart VM into Chrome” - kasperset
http://news.dartlang.org/2015/03/dart-for-entire-web.html
======
bhouston
I think Dart is sort of like CoffeeScript in that it was an experiment and
influenced a lot of JavaScript standards people.

A lot of the features of CoffeeScript are being integrated into JS with ES6
and ES7. The same is actually happening to the unique features of Dart such as
typing and SIMD and better modules.

Typing is so cool:
[http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects](http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects)

SIMD is amazing:
[https://github.com/johnmccutchan/ecmascript_simd](https://github.com/johnmccutchan/ecmascript_simd)

So, thank you Dart for showing us the way!

My only worry is that the innovators behind Dart are going to be stuck on the
Dart project while JavaScript gains their features and even more momentum. I
would suggest that they let Dart die and not be stuck with it for years after
it has stopped being relevant -- that would be a waste of their talents as
they did really see what the future would be.

~~~
BrendanEich
Good for lulz, but this is really uninformed, if not made up from whole cloth.

The influence of Dart on ES6 and 7 apart from SIMD (John McCutchan shout-out,
John did the Dart work and then worked on
[https://github.com/johnmccutchan/ecmascript_simd;](https://github.com/johnmccutchan/ecmascript_simd;)
I had some small helpful role to do with the project involving Mozilla and
Intel, too) and the courage and validation -- not the idea, which pre-dates
Dart -- of giving the for (let...) loop a binding per iteration in ES6 as in
Dart, there has been no influence or help from Dart.

Modules in ES6 have nothing to do with Dart, and the work started in 2010,
well before Dart ("Dash") leaked. Classes too pre-date Dart, in some ways they
go back to JS2/ES4 of the 1999-2003 era, and ES4 of the 2006-8 era.

CoffeeScript owes a lot to Ruby and Python, of course, and I did design-
champion fat arrow functions into ES6, inspired in part by CoffeeScript. ES6's
for-of loop is responding to the same gravity-well as CoffeeScript's for-of,
but it differs in substantial aspects. And so on.

Languages influence one another -- news at 11 -- but Dart did very little
intentional uplift work for JS. SIMD is the big and very good exception to
this norm. Better late than never, I say. Now is a good time to help get value
objects including bignums into ES7.

[https://code.google.com/p/dart/issues/detail?id=1533](https://code.google.com/p/dart/issues/detail?id=1533)

~~~
bhouston
> Good for lulz, but this is really uninformed, if not made up from whole
> cloth.

To be clear, I didn't say that Dart or CoffeeScript associated people actively
meant to be a guide for JavaScript (I'm pretty sure that having CoffeeScript
and Dart effectively subsumed into JavaScript wasn't the goal), but the fact
that these languages existed and has neat features did served as a guide for
evolution of JavaScript.

Thus I am making the case of much weaker case of languages influencing each
other, rather than a stronger case. And there is massive influence going on
here, whether intentional or not -- the speed at which features of Dart and
CoffeeScript being pulled into JS is very rapid.

I think your comments actually bare this out -- Dart people helping with SIMD,
and you being inspired by CoffeeScript.

~~~
BrendanEich
You wrote "influenced a lot of JavaScript standards people." Please name two.

You wrote "The same is actually happening to the unique features of Dart such
as typing and SIMD and better modules." My reply: no, yes (thanks to bottom-up
work by John McCutchan, not "Dart people" plural -- there you go again), and
nope. Any types for ES7/2016 or beyond are likely to be based on TypeScript,
Flow, and V8's SoundScript experiment, not on Dart. Modules in ES6 have no
relation to Dart modules/packages.

Really, "exaggeration" doesn't being to capture the false overreach of your
first comment, and walking back from it to vague "everything's influencing JS"
isn't helping.

Apart from SIMD, Google by investing in Dart at cost to JS (recreated V8 team;
replace-not-embrace strategy for ~5 years) missed out on uplifting ES6 to have
bignums and other things that would materially aid correctness and performance
of dart2js, which is now the only way forward for Dart in browsers.

I hate playing Cassandra, but the good news is that Troy didn't fall: JS
prevailed, at some unnecessary cost, and as predicted. See
[https://news.ycombinator.com/item?id=2982949](https://news.ycombinator.com/item?id=2982949)
et seq.

~~~
bhouston
Weird, I really didn't expect this conversation...

(1) I am referring to the high level features of Dart and CoffeeScript, not
the specific implementation of features. Specifically I am referring to the
clear reduction in CoffeeScript/Dart positive differentiators over the past
few years, mostly because future JavaScript (es6/es7) is moving aggressively
to close the gap and then go beyond Dart/CoffeeScript. This is a great thing.

(2) I am a complete outsider to the standardization process - I actually know
no one involved in the process. So why did I make the inference then so
confidently? I've been doing software product development in competitive
industries for a couple decades now. I know how it works. People are always
influenced by competitors to push ahead faster and smarter, especially
competitors that try to jump ahead.

This comment of mine from two years ago sums up my feelings of Dart and its
influence on JavaScript:
[https://news.ycombinator.com/item?id=5728786](https://news.ycombinator.com/item?id=5728786)

~~~
tinco
I think what Brendan is trying to say is that Dart simply had no influence on
ES6 and ES7 except for the idea of SIMD. That means no specific
implementations, and no high level ideas.

Any resemblance you might find between Dart and ES6/ES7 would be because of
Darts resemblance to either CoffeeScript or TypeScript, languages that did in
fact influence ES6 and ES7.

My personal view: I don't think Dart is the sort of language Javascript wants
to be like at all. Also, totally off topic regarding your comment of 2 years
ago: Java has _never_ kept up with C# has always been years behind and still
lacks many features that C# has had for ages. The only reason people still use
Java is that C# had no enterprise backing on non-Microsoft platforms and its
main implementation was proprietary. These things are changing, and I think
that will be the end (finally) of Java.

~~~
tkubacki
"These things are changing,"

There is still no end to end story for dev on Linux/Mac with _MS backed_ tools
(Mono is not .NET).

"and I think that will be the end (finally) of Java."

just day after Google will take C# as main dev lang for Android...

IMHO It's more likely that Dart will become new Android's main lang.

~~~
RoyOfTheEdge
Actually, MS recently open-sourced the .NET framework (".NET Core") and
announced they will be adding support for Linux and Mac OS X:
[https://github.com/dotnet/corefx](https://github.com/dotnet/corefx)

...seriously. April the first is still 5 days away.

~~~
tkubacki
"Actually, MS recently open-sourced the .NET framework (".NET Core")"

I know that. My point is you go to dartlang.org and get the IDE with SDK with
single download for Mac, Linux or Windows and use it now.

With .NET you can't do the same now on non-Windows (you can use Mono but it's
not MS project) Dart is designed to do webdev and .NET isn't

------
bsaul
A bit unrelated, but yesterday, after beeing fed up trying to fix unexpected
behaviors of a js code base, i decided to rename my file .ts and compile it
with typescript. Without doing anything, the compiler found type mistakes and
variable declaration errors.

And now today i'm coding in typescript adding type informations wherever i
think it could be useful, and looking at typescript documentation to see in
which way i could refactor my code to make it safer.

That's probably the fastest migration process you could imagine. Maybe dart
would be more popular if they chose that route.

~~~
allendoerfer
Maybe you should use JSHint. You can configure your editor to run it
automatically. It is a bit unfair to compare TypeScript with its compiler
against raw JavaScript, when the JavaScript ecosystem has tooling, too. I am
not argueing, that TypeScript is not the safer or even better choice, I am
just saying, that a properly set up JavaScript environment could have saved
you the hassle as well.

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

~~~
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?

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

------
lorddoig
Here's what I don't understand: why is there any focus on alternative VMs for
_specific_ languages? Surely all this effort should be going into a VM for
some kind of highish-level intermediate representation that's trivial to
generate from any source language? That way no language has a monopoly and
there can be peace on Earth.

It seems odd to be arguing for generic computation abilities in the place
where most "computation" is done nowadays. Can you imagine what could be
achieved if the browser vendors and standards bodies put business
considerations aside and spent a good couple of years designing such a thing?
We could have an almost endless list of goodies: threads, code isolation,
multiple number types...

Just like Intel, AMD, and the rest _in effect_ control (much to Alan Kay's
despair) hardware architectures, the vendors & standards bodies are a sort-of
natural cartel controlling upwards of, what, 50%? 80%? the code end users
actually interact with. The quality of the decisions they make has deep
repercussions beyond the tech community and it's simply not possible for any
of us to know what they all are. Even if they were bona-fide saints, this
would still be too much power to tie up in such a small group.

~~~
deathanatos
> Here's what I don't understand: why is there any focus on alternative VMs
> for specific languages? Surely all this effort should be going into a VM for
> some kind of highish-level intermediate representation that's trivial to
> generate from any source language? That way no language has a monopoly and
> there can be peace on Earth.

I've always wondered: why not LLVM? It's low-level, so the speed is there, and
I think should be trivial to compile as it arrives at the browser. Tons of
stuff already compiles to it. You can compile it to JS. Of course, you'd need
to make sure it doesn't make a syscall that's not allowed (and I'm not sure
how hard that is), and that it has bindings into JS APIs and/or the DOM, but
aside from that…

I'm sure some people will suggest things like the JVM or the .Net CLR, but I
feel like those have certain qualities (e.g., GC) that don't appeal to all
languages.

~~~
Touche
> I've always wondered: why not LLVM?

Because LLVM is not hardware independent.

~~~
azakai
Also, LLVM IR has undefined behavior and was not designed as a network format
(it's large).

LLVM is simply not a good starting point for the problem here, nice as LLVM is
for what it does do well.

------
mmastrac
This isn't surprising. Dartium has always been a nifty project, but you'll
never get all the major players to agree on a radical change like this. It was
always destined to be a "second VM" like VBScript.

asm.js illustrated the right political approach -- build something that
degrades nicely now, then get the vendors to optimize it.

~~~
msie
So what if all the major players don't agree to it? Someone has to take the
initiative.

~~~
cpeterso
Not even Google took the initiative. Why didn't Google integrate the Dart VM
in Chrome instead of Dartium?

~~~
msie
I'm saying that Google should have integrated the Dart VM into Chrome even if
it won't be supported by the other browser makers.

------
ceronman
I believe a lot of Dart criticism comes from people who haven't actually used
it. I personally find it almost always more enjoyable than JavaScript. I've
also used other languages that transpile to JS but there some features that I
find superior in Dart:

1\. Tree shaking. The compiler can detect unused code and remove them
automatically from the JS output, resulting in smaller files. (Yes I know that
Hello World is a bit big, but real projects are not hello world)

2\. A really nice IDE with autocomplete, error highlighting, code formating,
refactoring, debugger, profiler. It really makes a difference.

3\. A VM that's actually faster than JavaScript useful for writing server side
applications.

4\. A nice an well integrated standard library.

------
arikrak
They're putting a positive spin on it, but it seems Google decided not to
focus on Dart, considering all the other javascript's they're invested in.

~~~
kevmoo1
We try hard to avoid spin.

From the article:

Google Ads, one of Dart's biggest customers, is committed to Dart and supports
this new strategy. Scott Silver, VP of Engineering for Ads, says, “We are
committed to building our next-generation web apps with Dart, and a renewed
focus on generating optimal JavaScript helps us deliver great apps to everyone
with a modern browser. Dart has significantly improved our engineers'
productivity and our ability to quickly launch and iterate. We currently have
one million lines of Dart code and the number is growing fast.” Many other
teams inside of Google, such as Google Fiber, Google Express, and Google's
internal sales team, use Dart for business-critical apps.

~~~
fs111
one million lines of Dart code? All this work for displaying ads on the web.
Something is not right with this world...

~~~
skybrian
"Ads" is a short word but it covers a lot of complexity. There different
formats for ads, different kinds of ad customers, different places where ads
can be displayed, different ways of buying and selling ads, and then you have
localization to different countries, etc. There are complex UI's that
automatically reconfigure themselves based on the customer's needs.

A million lines of code is relatively small when you're trying to be all
things to all ads customers in the world.

Still, could it be simpler? I hope so.

~~~
lugg
I read Google Ads as the business unit, not the "displaying ads". I don't
really know how anyone would read "Google Ads" and "million lines+" and think
wow, all that for banner ads?

Alas, I'm writing this and reading the above..

------
msie
I'm disappointed. Where is the innovation? We'll be stuck with JS forever.

~~~
Someone1234
Just today I was reminded of how terrible JS is:

    
    
           new Date(2015, 1, 1)     
    

Guess what date that object represents (hint: It isn't January 1st 2015).

~~~
jessaustin
Is it that you don't like zero-indexing, or that you don't like it together in
the same function with one-indexing? b^)

Actually I think it's pretty terrible how few languages have literal
expressions for dates. Once you have to type "new Date(", it's not _much_ more
annoying to have to remember that January is zero.

~~~
reichstein
Apropos, you can easily make your own date syntax in Dart:

    
    
      class Month {
        static const List<String> names = const <String>[
          "JAN", "FEB", "MAR", "APR", "MAY", "JUN", 
          "JUL", "AUG", "SEP", "OCT", "NOV", "DEC"                                                    
        ];
        final int month;
        const Month(this.month);
        MonthDay operator -(int day) => new MonthDay(month, day);
        String toString() => names[month - 1];
      }
    
      class MonthDay {
        final int month;
        final int day;
        MonthDay(this.month, this.day);
        DateTime operator -(int year) => new DateTime(year, month, day);
        String toString() => "${Month.names[month - 1]}-${"$day".padLeft(2, "0")}";
      }
    
      const Month JAN = const Month(1);
      const Month FEB = const Month(2);
      const Month MAR = const Month(3);
      const Month APR = const Month(4);
      const Month MAY = const Month(5);
      const Month JUN = const Month(6);
      const Month JUL = const Month(7);
      const Month AUG = const Month(8);
      const Month SEP = const Month(9);
      const Month OCT = const Month(10);
      const Month NOV = const Month(11);
      const Month DEC = const Month(12);
    
      main() {
        print(MAR-25-2015);
      }

~~~
jessaustin
Kudos! Truly, Dart has redeeming qualities! Incidentally, this code is the
best argument I've seen for "American-style" date writing, with the month
first. Or would it be as easy in Dart to override integers with a "DayMonth"
operator?

------
nathansobo
Very pleased to hear this. I'd much rather have resources funneled into making
v8 and JavaScript in general more performant. It already has so much momentum
behind it.

------
amelius
The problem is still that even with Dart we have so little choice of
languages. What is needed is a way to implement _any_ language of choice on
the web, probably through a sandboxed low-level virtual machine that supports
threading, and which has no garbage collector (so languages can implement
their own if desired).

~~~
munificent
> which has no garbage collector (so languages can implement their own if
> desired).

The problems with that are:

1\. It means every web app basically has to push its own GC down the wire
every time the user hits myawesomeapp.com. That's a lot of overhead.

2\. You'd have to define what the memory model between the code running in the
VM and the browser's native stuff is. What does it mean for the code to have a
reference to a DOM element? How does the browser hold a reference to an event
handler in the VM?

3\. The set of people who can implement an efficient GC is very very small.
Forcing each source language to do that themselves wastes a lot of effort.
(For example, look at how primitive Python and Ruby's GCs were for most of
their histories.)

Now a low-level VM _with_ GC. That's something I'd be excited about.

~~~
amelius
Interesting points.

1\. Caching, content-distribution-networks, and possibly shared-libraries
could solve or at least ameliorate this.

2\. This is relatively easy. The sandboxed code could "open" handles by
calling into an API, and the code could "close" them when no longer needed.

3\. In many cases, the GC is tied intimately to the semantics of the language,
so enforcing a style of GC could be too limiting in terms of performance.
Instead, it could be better to implement a GC'ed VM on top of the low-level
one.

The biggest problem is to get something like this turned into a standard, and
accepted in all browsers. Perhaps a viable route is to write the standard of
this low-level virtual machine for the web (LLVM/W) on top of ASM.js (and
implement threading by emulation), and then wait for general acceptance, and
for browser vendors to implement LLVM/W directly.

~~~
arohner
> 2\. This is relatively easy. The sandboxed code could "open" handles by
> calling into an API, and the code could "close" them when no longer needed.

That's easy to _specify_ , but is it good for the user? You've just opened the
door to memory leaks on _my_ machine in poorly-written "javascript".

~~~
amelius
Contrary to popular belief, it is still possible (and in fact very easy) to
have memory leaks with a GC. Consider for example this situation: fill a list
with a large number of items, and hold on to that list, without ever accessing
the items again. In principle, the contents of the list is "unreachable"
(since the code never re-visits the items), but the GC isn't aware of this
(too difficult to prove) and conservatively assumes that the reference to the
list means that the items in it can still be accessed.

So, even in Javascript, it is very easy to have memory leaks.

The main way to deal with this, is to simply set a limit on the amount of
memory a browser-tab can use. This limit can be dynamic, and depend on what
other tabs (or processes) are doing, but it doesn't need to be. This is also
the current way browsers deal with this problem.

------
skalkin
This is a great move by the Dart team. There is now a single story for the web
development, their efforts can be more focused, and accusations regarding
trying to break the web will stop. Win-win-win.

After developing with Dart for quite a while, I can just not see myself going
back to JavaScript, the platform is just that much better.

------
zanny
Lets instead try getting the Qt QML engine integrated into browsers. I'd love
to write webapps in QML instead of mutant document markup =P.

~~~
discreteevent
Never let go of your dreams! If you start a petition I'll be the first to sign
it.

------
shirro
Good. We don't need another VBScript. Whatever Dart's technical advantages,
the standard for browser scripting is Ecmascript. Use it as a compilation
target. Don't go breaking the Internet. We don't need another Internet
Explorer.

------
rurban
So I'm pretty disappointed now. I didn't hear the reasons why they ditched
Dart? Compilation to ES6/7 cannot be the technical reason, as there is a huge
run-time and memory overhead by using only ES6/7 compared to Dart. Looks more
like a marketing decision, Dart not have gained enough momentum or such.

~~~
dragonwriter
> I didn't hear the reasons why they ditched Dart?

They didn't.

They ditched plans to integrate DartVM into Chrome from browser-side Dart in
favor of continuing to use dart2js for browser-side dart.

------
tosh
I'm really excited about this new direction.

I also hope some great Mozillians will take a second look at Dart now that the
main objection (adding another VM to Chrome) is out of the way.

------
thebouv
Let Dart stay and transpile. Let them continue to make Dart better. Even if it
exists only to transpile into JS like CoffeeScript and TypeScript and not run
natively in the browser -- as long as they keep innovating with the language,
the ideas can inspire the next version of JS with ES8 and beyond.

Evolution by inspiration.

------
bydo
Another twenty years of JavaScript. Joy.

~~~
chc
Would you really have been happy with a monoculture based around a very
similar but slightly different and less mature language if it had gone the
other way?

~~~
axlprose
Why would there be a monoculture? JS would still exist for a good while after
that, and if anything, it would've likely inspired more competition to
flourish in the browser space.

Secondly, while the language may appear similar, a large number of its
strengths come from actually breaking away from the JS ecosystem, and daring
to take the 'less mature' approach. Without all that legacy, it turned out
with significantly cleaner libraries and APIs, more intuitive semantics, and
and an ecosystem+workflow is worlds apart from the JS style. The difference a
few small changes can make in simplicity to lower cognitive overhead is
astounding. Building a large, complex app in dart actually feels totally
manageable! Yet, regardless of how many new JS tools and libraries come out,
it always still feels completely overwhelming. Thankfully they decided to keep
this part of dart in tact.

------
robbrown451
It seems logical since no other browser is going to support it. Although it is
kind of a shame, as it is clearly an improvement over Javascript, the writing
has been on the wall for a while.

Considering the lack of other browsers jumping on board, I think it is better
that Google gradually phase out Dart and let everyone concentrate on making
Javascript better (both by improving the language itself, and the libraries).
I predict they will stop new development entirely within a few years.

------
bananaoomarang
This has been pretty much inevitable from the beginning.

~~~
modeless
This wasn't inevitable at all; you're not giving Google enough credit. They
could easily have decided to force Dart VM into Chrome and that would have
been bad for everyone.

~~~
bydo
Like it was with SPDY?

~~~
bydo
Apparently that was a touch too glib.

But where was the "bad for everyone" when Google rolled SPDY into Chrome and
its own services, and showed not only tangible improvements to HTTP/1.1 but
also an actual conviction in its efforts? It took a few years, but there was a
good amount of industry momentum behind SPDY even before its ordainment as
HTTP/2 became certain.

All Dart ever got was a Chromium fork; how was it ever meant to make inroads
without Google putting any wood behind it?

~~~
modeless
I like SPDY and I don't like Dart VM; I think that reflects the broader
consensus as well. Dart VM just isn't better enough to justify switching the
entire web to it. SPDY is.

Personally I wouldn't support _any_ proposal for a new web VM unless it could
achieve no-compromise full-speed execution of transpiled C/C++ code in the web
sandbox. That's the #1 most important feature and #2 isn't even close.

------
msie
JavaScript as a compilation target should only be a temporary measure.

~~~
fixermark
Probably not. While it wasn't intended to be so, JavaScript has become the
lingua franca of web browsers and is therefore heading towards a future of
being a compilation target. If your program can't compile to JavaScript, it
doesn't really run on browsers (in much the same sense as "If your program
can't be compiled to x86 assembly, it doesn't really run on computers").

[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
libria
> heading towards a future of being a compilation target

Having to trace/debug compiled javascript from another language is a horrific
future. In your analogy, C programmers would have to debug assembly.

I agree it's the most probable future, but let no one call it innovation when
it's simply resignation from lack of options.

~~~
wtetzner
There's no reason Javascript can't get better at being the assembly language
of the web, including making debugging of other languages easier.

------
kenko
This blog post is really weirdly written, with press-release-style blurbs from
other people. I can't tell what genre it's supposed to be: a report of a
technical decision by language maintainers? A press release? An advertorial?

~~~
kaendfinger
Well, it's a big decision. The post actually includes a quote from the company
I work for (DGLogik). It's kinda a press release in a way.

------
binarez
[http://techcrunch.com/2015/03/05/microsoft-and-google-
collab...](http://techcrunch.com/2015/03/05/microsoft-and-google-collaborate-
on-typescript-hell-has-not-frozen-over-yet/)

~~~
kevmoo1
This is unrelated.

Angular2 has been TypeScript from the beginning to support both JS and Dart
development.

Angular2 is a better story for both Dart and JS developers.

More info:
[http://work.j832.com/2015/03/angulartsjsatdartwtf.html](http://work.j832.com/2015/03/angulartsjsatdartwtf.html)

The latest preview release of Angular2 Dart was yesterday -
[https://pub.dartlang.org/packages/angular2#versions](https://pub.dartlang.org/packages/angular2#versions)

------
bipin_nag
Now dart won't be in browsers. Soundscript already is another way to improve
Javascript from Google. If I choose one I miss the other. Is there any way to
integrate both of them, maybe generate soundscript out of dart.

dart2js or soundscript - which one is the preferred way. If sound script, dart
will fall before reaching the goal of structured webapp. Dart on server
doesn't excite me as much as single language for end to end development. There
is a vaccum created due to soundscript in web development in Dart, these
questions should be answered.

------
ausjke
I read that post but I'm lost in the logic reasoning part....Dart is that
great but then it's not included in Chrome, what am I missing?

~~~
kaendfinger
@kevmoo has said he will be posting the reason for the decision on his blog
[http://work.j832.com/](http://work.j832.com/) later.

------
pornel
I hope Google developers who were working on the Dart VM will now be able to
move to V8 and accelerate its ES6 support.

~~~
Zikes
The VM development will continue for use on servers, embedded, and mobile,
they just have no plans to integrate it into Chromium.

~~~
cpeterso
The Dart blog post was unclear about the future of the Dart VM. I don't see
why Google will continue to maintain the VM. Does Google use the Dart VM on
servers or mobile? Dart would be nice a nice replacement for Java on Android.

~~~
mraleph
Dart VM is an essential part of the Dart ecosystem.

Dart tools: pub's (package manager) client, analyzer, dart2js compiler, etc
are all written in Dart.

We have a good story for server side developement and we are not looking to
abandon it but rather we are looking to expand it, e.g. we just released a
package to facilitate creation of REST APIs[1]. Pub's server side is being
rewritten into Dart as we speak[2]

Among cool internal users of Dart VM I could mention Google Fiber - they'll
share their experience during the upcoming Dart Summit[3].

[1] [http://news.dartlang.org/2015/03/create-your-own-rest-api-
wi...](http://news.dartlang.org/2015/03/create-your-own-rest-api-with-
dart.html)

[2] [https://github.com/dart-lang/pub-dartlang-dart](https://github.com/dart-
lang/pub-dartlang-dart)

[3]
[https://www.dartlang.org/events/2015/summit/sessions/google-...](https://www.dartlang.org/events/2015/summit/sessions/google-
fiber-and-dart/)

~~~
tosh
Now that the Dart VM story is less controversial I hope more people will take
a fresh look at the VM (in non-browser settings) and appreciate its merits.

------
sharpercoder
I wonder if the dart team will support a debugging-to-js experience. With that
I mean 1) write dart 2) refresh browser 3) debug javascript. This requires
partial transpilation from dart to js with updated sourcemaps. This would
enable debugging in for example Spartan or Firefox.

~~~
munificent
[https://github.com/dart-lang/dev_compiler](https://github.com/dart-
lang/dev_compiler)

~~~
sharpercoder
Awesome. Looking to the dev activity, I must conclude this project is red-hot
in development.

~~~
munificent
Yes, this is the full-time focus of a number of people on the team right now.
We really really really want a fast, pleasant iteration loop when compiling to
JS.

~~~
stephen
Any plans to collaborate with sdbg [1] for the Eclipse/debugging/source
mapping side of the developer experience?

(AFAIK sdbg is just one guy who regularly copy/pastes code out of the Dart IDE
+ does some polish for GWT projects. Would be great to have a more
formula/official collaboration, since it seems like a lot of "debugging
language X via source maps with browser Y" could be shared infrastructure.)

[1]: [https://github.com/sdbg/sdbg](https://github.com/sdbg/sdbg)

------
kristianp
Does this say something about the javascript engines in modern browsers that a
dart VM couldn't improve on the performance of them even with its stronger
typing? There isn't a big enough advantage to integrate a dart native over
translated to js.

------
sivanmz
The Angular cross-compiling insanity and eventual switch to TypeScript is the
likely catalyst. Still, I hope to see a technical discussion of why the VM had
to go.

Looking forward to better interop with JS, but can't help feeling a bit sad.

~~~
spankalee
Angular had nothing to do with it. Them switching to TypeScript from AtScript
was just de-fragmenting the JS-superset language space, which is a good thing.
Hopefully TypeScript goes away when types arrive in JS.

~~~
aikah
Js will never have types.Ever.It could have had type back in 2007, Microsoft
creator of typescript said NO.

------
sriku
I wish for a browser with Scheme as the underlying language in which all is
expressed. A Racket browser. No html/script/css distinction. Just
s-expressions. A page is just code and it is run in a sandbox.

------
adrianlmm
As a Dart user, I already knew this in my heart.

------
yy77
this announcement seems to be like a sign of losing attention from the
management team. So maybe some time later, it will be another R.I.P product
from google.

------
yahiko
Good. News.

------
brakmic
Dart? Who's Dart?

The Web couldn't care less.

------
Cshelton
Good boy google, good boy! ...now sit... lol.

Besides, I think people will really come to like ECMA 6, or whatever it's
called this week? I've been using it and love it.

~~~
spankalee
I write in ES6 every day now, after using Dart for a few years. ES6 is a great
improvement on ES5, but trust me, it's no Dart.

