17 ms·

“We have decided not to integrate the Dart VM into Chrome”

516 points by kasperset 12y ago

binarez 12y ago
http://techcrunch.com/2015/03/05/microsoft-and-google-collaborate-on-typescript-hell-has-not-frozen-over-yet/ http://techcrunch.com/2015/03/05/microsoft-and-google-collab...
- kevmoo1 12y ago
  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
nathansobo 12y ago
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.
mmastrac 12y ago
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.
- kevmoo1 12y ago
  asm.js, CoffeeScript, etc are all great examples of evolving development for the web by compiling to JS. Dart is new 100% committed to that model for targeting browsers.
  - mmastrac 12y ago
    Agreed. I just changed "Dart" to "Dartium" in my comment to avoid confusion as I realized that it wasn't clear.
- msie 12y ago
  So what if all the major players don't agree to it? Someone has to take the initiative.
  - wmf 12y ago
    I get the impression that other browsers have committed to never supporting NaCl or Dart, so taking the initiative to build a prototype in Chrome wouldn't help.
  - fixermark 12y ago
    The Internet isn't a technology; it's a collection of standards. Much like the industrial revolution wasn't about mechanisms; it was about interchangeable parts and standardization of forms, such that they could be usefully combined without eternal one-off customization. In the short-run, your approach is sound. In the large, a web technology isn't a web technology if my browser doesn't support it. Seems that the people in charge of Dart decided it had crossed the event horizon from situation 1 to situation 2.
  - cpeterso 12y ago
    Not even Google took the initiative. Why didn't Google integrate the Dart VM in Chrome instead of Dartium?
    - msie 12y ago
      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.
  - threeseed 12y ago
    So I am assuming you agree with the approach that Microsoft took with all the IE specific features back in the day ? I know it resulted in some very useful features e.g. AJAX but surely a standards based approach is infinitely better.
  - aikah 12y ago
    Imaging a world with each browser vendor implementing his own incompatible scripting language ... Oh wait it happened in the past and it was so ugly people used a plugin called Flash that ran the same way in every browser ...
arikrak 12y ago
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 12y ago
  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.
  - throwawaymaroon 12y ago
    "We realized that the goal of putting Dartium in every browser was monopolistic and made us look bad, even if we had good intentions" would be avoiding spin. This is a setback for Dart and Dart's mission statement, and everyone knows it, and everyone also knows it's been a long time coming.
  - fs111 12y ago
    one million lines of Dart code? All this work for displaying ads on the web. Something is not right with this world...
    - ihsw 12y ago
      Hey, it makes the world go 'round. Bash it all you want, it provides a useful service to businesses.
    - skybrian 12y ago
      "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.
bananaoomarang 12y ago
This has been pretty much inevitable from the beginning.
- modeless 12y ago
  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 12y ago
    Like it was with SPDY?
    - bydo 12y ago
      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 12y ago
        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.
bydo 12y ago
Another twenty years of JavaScript. Joy.
- chc 12y ago
  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 12y ago
    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.
- wtbob 12y ago
  It's like Cthulhu instead of a groundhog…
tosh 12y ago
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.
Cshelton 12y ago
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 12y ago
  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.
msie 12y ago
I'm disappointed. Where is the innovation? We'll be stuck with JS forever.
- shurcooL 12y ago
  You can use Go and compile it to JavaScript. I've been doing that the last year. I gave a talk about it recently if you want to see. https://www.hakkalabs.co/articles/getting-started-gopherjs https://www.hakkalabs.co/articles/getting-started-gopherjs
  - Zergy 12y ago
    You can also use C++, Java, Kotlin, C#, or almost any popular language. Compiling to JS is not an innovation its a hack and a testament to how terrible the language and ecosystem is.
    - timepiece 12y ago
      It's more of a testament of the intellectual laziness of some devs to pick up the language and put real efforts to master it.
      - tobltobs 12y ago
        Following your logic, all "masters" should code in assembler?
        mastazi 12y ago
        No major language implementation that I'm aware of compiles to assembly. Maybe you are referring to machine language and/or bytecode, which are not targeted at humans, so the 'masters' should not code in them because the 'masters' are humans. Advanced Javascript has many capabilities such as first-class functions and great introspection because of the way objects are. The fact that there is a lot of shitty js code around doesn't make js a shitty language, just like the tons of shitty C from our Commodore-64-childhood don't make C a shitty language.
bhouston 12y ago
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.
- sethladd 12y ago
  Dart is much more full-featured than CoffeeScript. Dart is a completely new language, with much improved semantics. Dart has features such as method cascades, mixins, async/await, optional types, a rich core library, factory constructors, libraries, named parameters, lexical this, Futures, implicit interfaces, generics, and lots more. [disclaimer: I'm on the Dart team]
  - bhouston 12y ago
    I am not saying Dart and CoffeeScript are comparable in terms of features -- not at all, rather I am saying that both Dart and CoffeeScript have served similar purposes in showing where the JavaScript language can evolve towards in the future.
    - kybernetikos 12y ago
      On the other hand, persuing the strategy that Google did with Dart distracted people and effort from the important task of actually improving javascript, so it may well have been a net negative.
msie 12y ago
JavaScript as a compilation target should only be a temporary measure.
- fixermark 12y ago
  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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  - libria 12y ago
    > 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 12y ago
      There's no reason Javascript can't get better at being the assembly language of the web, including making debugging of other languages easier.
    - bad_user 12y ago
      You haven't heard of source maps then.
    - TazeTSchnitzel 12y ago
      "Having to trace/debug compiled x86 machine code from another language is a horrific future."
  - ajkjk 12y ago
    It seems to me that we should really be looking for browsers to compile (or at least appear to compile, even if they skip this as an optimization) Javascript into a lower-level 'assembly' language, so that Dart can be made to compile to the same form. A LLVM for browsers, basically. JS is a terrible assembly language. But the work that's been done on making it passable for that purpose is remarkable, so we're getting by with it.
pornel 12y ago
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 12y ago
  The VM development will continue for use on servers, embedded, and mobile, they just have no plans to integrate it into Chromium.
  - cpeterso 12y ago
    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 12y ago
      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-with-dart.html http://news.dartlang.org/2015/03/create-your-own-rest-api-wi... [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-fiber-and-dart/ https://www.dartlang.org/events/2015/summit/sessions/google-...
      - cpeterso 12y ago
        Thanks for the links. Dart had an uphill battle on the web, but doesn't need to worry about those problems or legacy on the server side.
deleted 12y ago
[deleted]
yahiko 12y ago
Good. News.
woven 12y ago
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.
- s73v3r 12y ago
  "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 12y ago
    Maybe they'll build an asm.js backend for Dart.
bsaul 12y ago
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 12y ago
  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.
- girvo 12y ago
  Interestingly, that's what Facebook's Flow type analyser is built to do: allow you to type-check normal JS code, and add types where needed in the codebase. [0] http://flowtype.org/ http://flowtype.org/
skalkin 12y ago
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.
sivanmz 12y ago
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 12y ago
  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 12y ago
    Js will never have types.Ever.It could have had type back in 2007, Microsoft creator of typescript said NO.
zanny 12y ago
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 12y ago
  Never let go of your dreams! If you start a petition I'll be the first to sign it.
deleted 12y ago
[deleted]
sharpercoder 12y ago
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 12y ago
  https://github.com/dart-lang/dev_compiler https://github.com/dart-lang/dev_compiler
  - sharpercoder 12y ago
    Awesome. Looking to the dev activity, I must conclude this project is red-hot in development.
    - munificent 12y ago
      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 12y ago
        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
rurban 12y ago
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.
- kevmoo1 12y ago
  Actually the decision was mostly technical and logistical. I'll have a post up about it soonish at http://work.j832.com http://work.j832.com
- dragonwriter 12y ago
  > 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.
ausjke 12y ago
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 12y ago
  @kevmoo has said he will be posting the reason for the decision on his blog http://work.j832.com/ http://work.j832.com/ later.
brakmic 12y ago
Dart? Who's Dart? The Web couldn't care less.
thebouv 12y ago
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.
shirro 12y ago
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.
kenko 12y ago
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 12y ago
  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.
amelius 12y ago
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 12y ago
  > 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 12y ago
    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 12y ago
adrianlmm 12y ago
As a Dart user, I already knew this in my heart.
deleted 12y ago
[deleted]
ceronman 12y ago
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.
lorddoig 12y ago
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.
- danschuller 12y ago
  Agreed. A more generic VM seems the way to go. .NET's CLR does well supporting a wide array of different languages very well C#, F#, IronPython, IronRuby etc
- frozenport 12y ago
  I agree, I thunk this isnt being done because browser vendors believe that the intermediate common language is Javascript and that if they fix JS performance they are killing two birds with one stone. This isnt true because JS lacks many features like synchronization primitives.
  - frozenport 12y ago
    Spelling is hard on my cellphone. Would be nice to have a longer editing window.
  - azakai 12y ago
    Synchronization primitives are being suggested for addition to JS, https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...
deleted 12y ago
[deleted]
yy77 12y ago
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.
robbrown451 12y ago
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.
kristianp 12y ago
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.
sriku 12y ago
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.
bipin_nag 12y ago
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.

516 points by kasperset 12y ago

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

kevmoo1 12y ago
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

nathansobo 12y ago

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.

mmastrac 12y ago

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.

kevmoo1 12y ago
asm.js, CoffeeScript, etc are all great examples of evolving development for the web by compiling to JS. Dart is new 100% committed to that model for targeting browsers.
- mmastrac 12y ago
  Agreed. I just changed "Dart" to "Dartium" in my comment to avoid confusion as I realized that it wasn't clear.
msie 12y ago
So what if all the major players don't agree to it? Someone has to take the initiative.
- wmf 12y ago
  I get the impression that other browsers have committed to never supporting NaCl or Dart, so taking the initiative to build a prototype in Chrome wouldn't help.
- fixermark 12y ago
  The Internet isn't a technology; it's a collection of standards. Much like the industrial revolution wasn't about mechanisms; it was about interchangeable parts and standardization of forms, such that they could be usefully combined without eternal one-off customization. In the short-run, your approach is sound. In the large, a web technology isn't a web technology if my browser doesn't support it. Seems that the people in charge of Dart decided it had crossed the event horizon from situation 1 to situation 2.
- cpeterso 12y ago
  Not even Google took the initiative. Why didn't Google integrate the Dart VM in Chrome instead of Dartium?
  - msie 12y ago
    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.
- threeseed 12y ago
  So I am assuming you agree with the approach that Microsoft took with all the IE specific features back in the day ? I know it resulted in some very useful features e.g. AJAX but surely a standards based approach is infinitely better.
- aikah 12y ago
  Imaging a world with each browser vendor implementing his own incompatible scripting language ... Oh wait it happened in the past and it was so ugly people used a plugin called Flash that ran the same way in every browser ...

arikrak 12y ago

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 12y ago
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.
- throwawaymaroon 12y ago
  "We realized that the goal of putting Dartium in every browser was monopolistic and made us look bad, even if we had good intentions" would be avoiding spin. This is a setback for Dart and Dart's mission statement, and everyone knows it, and everyone also knows it's been a long time coming.
- fs111 12y ago
  one million lines of Dart code? All this work for displaying ads on the web. Something is not right with this world...
  - ihsw 12y ago
    Hey, it makes the world go 'round. Bash it all you want, it provides a useful service to businesses.
  - skybrian 12y ago
    "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.

bananaoomarang 12y ago

This has been pretty much inevitable from the beginning.

modeless 12y ago
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 12y ago
  Like it was with SPDY?
  - bydo 12y ago
    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 12y ago
      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.

bydo 12y ago

Another twenty years of JavaScript. Joy.

chc 12y ago
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 12y ago
  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.
wtbob 12y ago
It's like Cthulhu instead of a groundhog…

tosh 12y ago

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.

Cshelton 12y ago

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 12y ago
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.

msie 12y ago

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

shurcooL 12y ago
You can use Go and compile it to JavaScript. I've been doing that the last year. I gave a talk about it recently if you want to see. https://www.hakkalabs.co/articles/getting-started-gopherjs https://www.hakkalabs.co/articles/getting-started-gopherjs
- Zergy 12y ago
  You can also use C++, Java, Kotlin, C#, or almost any popular language. Compiling to JS is not an innovation its a hack and a testament to how terrible the language and ecosystem is.
  - timepiece 12y ago
    It's more of a testament of the intellectual laziness of some devs to pick up the language and put real efforts to master it.
    - tobltobs 12y ago
      Following your logic, all "masters" should code in assembler?
      - mastazi 12y ago
        No major language implementation that I'm aware of compiles to assembly. Maybe you are referring to machine language and/or bytecode, which are not targeted at humans, so the 'masters' should not code in them because the 'masters' are humans. Advanced Javascript has many capabilities such as first-class functions and great introspection because of the way objects are. The fact that there is a lot of shitty js code around doesn't make js a shitty language, just like the tons of shitty C from our Commodore-64-childhood don't make C a shitty language.

bhouston 12y ago

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.

sethladd 12y ago
Dart is much more full-featured than CoffeeScript. Dart is a completely new language, with much improved semantics. Dart has features such as method cascades, mixins, async/await, optional types, a rich core library, factory constructors, libraries, named parameters, lexical this, Futures, implicit interfaces, generics, and lots more. [disclaimer: I'm on the Dart team]
- bhouston 12y ago
  I am not saying Dart and CoffeeScript are comparable in terms of features -- not at all, rather I am saying that both Dart and CoffeeScript have served similar purposes in showing where the JavaScript language can evolve towards in the future.
  - kybernetikos 12y ago
    On the other hand, persuing the strategy that Google did with Dart distracted people and effort from the important task of actually improving javascript, so it may well have been a net negative.

msie 12y ago

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

fixermark 12y ago
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-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- libria 12y ago
  > 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 12y ago
    There's no reason Javascript can't get better at being the assembly language of the web, including making debugging of other languages easier.
  - bad_user 12y ago
    You haven't heard of source maps then.
  - TazeTSchnitzel 12y ago
    "Having to trace/debug compiled x86 machine code from another language is a horrific future."
- ajkjk 12y ago
  It seems to me that we should really be looking for browsers to compile (or at least appear to compile, even if they skip this as an optimization) Javascript into a lower-level 'assembly' language, so that Dart can be made to compile to the same form. A LLVM for browsers, basically. JS is a terrible assembly language. But the work that's been done on making it passable for that purpose is remarkable, so we're getting by with it.

pornel 12y ago

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 12y ago
The VM development will continue for use on servers, embedded, and mobile, they just have no plans to integrate it into Chromium.
- cpeterso 12y ago
  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 12y ago
    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-with-dart.html http://news.dartlang.org/2015/03/create-your-own-rest-api-wi... [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-fiber-and-dart/ https://www.dartlang.org/events/2015/summit/sessions/google-...
    - cpeterso 12y ago
      Thanks for the links. Dart had an uphill battle on the web, but doesn't need to worry about those problems or legacy on the server side.

deleted 12y ago

[deleted]

yahiko 12y ago

Good. News.

woven 12y ago

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.

s73v3r 12y ago
"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 12y ago
  Maybe they'll build an asm.js backend for Dart.

bsaul 12y ago

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 12y ago
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.
girvo 12y ago
Interestingly, that's what Facebook's Flow type analyser is built to do: allow you to type-check normal JS code, and add types where needed in the codebase. [0] http://flowtype.org/ http://flowtype.org/

skalkin 12y ago

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.

sivanmz 12y ago

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 12y ago
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 12y ago
  Js will never have types.Ever.It could have had type back in 2007, Microsoft creator of typescript said NO.

zanny 12y ago

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 12y ago
Never let go of your dreams! If you start a petition I'll be the first to sign it.

deleted 12y ago

[deleted]

sharpercoder 12y ago

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 12y ago
https://github.com/dart-lang/dev_compiler https://github.com/dart-lang/dev_compiler
- sharpercoder 12y ago
  Awesome. Looking to the dev activity, I must conclude this project is red-hot in development.
  - munificent 12y ago
    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 12y ago
      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

rurban 12y ago

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.

kevmoo1 12y ago
Actually the decision was mostly technical and logistical. I'll have a post up about it soonish at http://work.j832.com http://work.j832.com
dragonwriter 12y ago
> 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.

ausjke 12y ago

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 12y ago
@kevmoo has said he will be posting the reason for the decision on his blog http://work.j832.com/ http://work.j832.com/ later.

brakmic 12y ago

Dart? Who's Dart? The Web couldn't care less.

thebouv 12y ago

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.

shirro 12y ago

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.

kenko 12y ago

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 12y ago
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.

amelius 12y ago

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 12y ago
> 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 12y ago
  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 12y ago

adrianlmm 12y ago

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

deleted 12y ago

[deleted]

ceronman 12y ago

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.

lorddoig 12y ago

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.

danschuller 12y ago
Agreed. A more generic VM seems the way to go. .NET's CLR does well supporting a wide array of different languages very well C#, F#, IronPython, IronRuby etc
frozenport 12y ago
I agree, I thunk this isnt being done because browser vendors believe that the intermediate common language is Javascript and that if they fix JS performance they are killing two birds with one stone. This isnt true because JS lacks many features like synchronization primitives.
- frozenport 12y ago
  Spelling is hard on my cellphone. Would be nice to have a longer editing window.
- azakai 12y ago
  Synchronization primitives are being suggested for addition to JS, https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ https://blog.mozilla.org/javascript/2015/02/26/the-path-to-p...

deleted 12y ago

[deleted]

yy77 12y ago

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.

robbrown451 12y ago

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.

kristianp 12y ago

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.

sriku 12y ago

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.

bipin_nag 12y ago

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.