Google releases first beta SDK for Dart, including 20% faster analysis engine
thenextweb.com
thenextweb.com
The Angular team recently announced[1] that they are going to start supporting the Dart project too. This means that if you're already familiar with writing Angular code but you want a language with some better semantics, better tooling, and a standard library, this may be a good time to start checking it out.
[1]: http://news.dartlang.org/2013/06/angularjs-announces-port-fo... , https://github.com/angular/angular.dart
I have no idea how Google could get around that - maybe a written promise to provide support for Dart for X years?
EDIT: Another similar worry: if Dart really does take off, will Google not just drop support for other browsers besides Chrome from stock Dart?
I'm no longer willing to tie my career to google's fickle attention span. Particularly since as I understand it the dart team has some of the same personnel from the old gwt team. They are masters at the art of soft deprecation through neglect.
Dart is lead by Lars Bak out of Aarhus, which IIRC wasn't even a Google office location before they hired Lars to do V8. Even if some people transfered over from GWT, I doubt it would be many, and I don't see how it would have substantial impact with someone like Lars at the top.
And it's been 7 years since GWT was released. Yes, yes, enterprise needs whatever, but many web technologies fade away over time. It sucks if you were an early adopter and were heavily invested, but at a certain threshold, no one cares anymore. Is YUI's nearly negligible update rate a sign of Yahoo's fickle attention span? No, because no one uses it anymore (sorry YUI users), and at a certain point you have to cut your losses. If the community is self sustaining enough, it can pick up the slack with these open source frameworks, but if it's not, I really can't manage any indignation. It happens sometimes.
I'm not advocating using Dart in production (I would advocate just learning JS if you're targeting browsers anyway...), but this critique is specious at best, not least because the SDK is apparently just entering beta, so it says right on the tin not to found your production pipeline on it.
then why anybody would want to use it? as much as i dislike MS , their TypeScript language makes more sense than Dart which feels DOA already.
I agree with you on Typescript, though I don't see it as any more interesting than Closure Compiler annotations plus one of the various ES6 transpilers. It's nice to have those in one package, but I don't really use or want the transpilers normally, so I feel no draw to them now.
As for Dart, I've never totally understood its intended place and how it was expected to succeed there (though we'll see, I guess), but as for its use in practice, philosophically I now just think of it as another Coffeescript, and so I'm at peace with the idea that people want to use it.
It was a process to stop worrying and love the bomb -- so many HN articles proselytizing and condemning Coffeescript (and others) -- but I believe the healing started with the sheer popularity of Coffeescript, and then normalized when Brendan Eich stood on stage with Jeremy Ashkenas and told everyone that compiling to Javascript was A-OK in his book.
So thinking of these languages in those terms is the reason I don't really care about the horse race and I'm ok with people writing in Dart if they want to. My domain will be fine, and might be improved as they find interesting things (syntax, developer tools, whatever) exploring a slightly different path toward a web scripting language.
(though I'll continue to be annoyed if some article on web technology puts all its examples in X where X is not Javascript :)
This session from I/O by Kasper Lund and Lars Bak is well worth a watch: https://developers.google.com/events/io/sessions/324431687
In it they explain that they've pretty much reached the peak of where they can get to in terms of performance with V8 (no more big jumps in performance), but by designing a language that is easier to optimize for, they've already made the Dart VM faster.
Not that there weren't signs of ADD before that, what with the dizzying changes in how-things-ought-to-be-done with each point release. But an attendee of 2011 Google IO could quite reasonably have come away with the impression that as far as Google was concerned the future of GWT was glorious. (see http://www.google.com/events/io/2011/sessions.html)
Even in this age of iterating, pivots, and agility, two years is a quick turnaround from breathless evangelizing to dead and buried.
If Dart, an open-source toolchain, takes off (e.g., becomes wildly popular with developers) and then Google chooses to limit future Dart versions to only work with Chrome, I would expect a fork to become popular in a heartbeat. I mean, look at other popular open source projects whose sponsor/maintainer has done things unwelcome by the community (e.g., OpenOffice, MySQL.)
The difference is that Dart is not a service, and cannot just be turned off. It's an open-source language, and "at worst" could be community maintained.
I stopped playing with Dart when I "discovered" Meteor recently. That said, the Dart language is very nice and I might still use it on a real project.
http://channel9.msdn.com/Blogs/Charles/Anders-Hejlsberg-Stev...
Until these things are achieved then it is absolutely proprietary and claims to the contrary are based on a PR position about a possible future that could easily be de-prioritized or never come about.
I could easily see developers jump on board this 'soon to be standardized' language, only to see an announcement that 'Other vendors didn't join up, so we have been forced to go it alone' from Google.
So just like every language being developed today then?
At the moment the goal of the Dart language is to provide a structured language to help create large scale web applications with much faster Starup and runtime performance that's being developed by experienced language designers with input from skilled VM engineers who were on teams that's brought the worlds fastest language VMs: i.e. StrongTalk's VM (later acquired by Sun to form Java's fast Hotspot VM), V8 and are now working on Dart's VM. Google's goal for Dart is to provide a better language to develop, faster and richer web applications - I'm not sure which of their goals are harmed from being a Google Sponsored project.
Note the Dart team frequently asks for feedback on the Dart Mailing list and invites features and language enhancements on the projects issues list: https://code.google.com/p/dart/issues/list
None of Google's goals are harmed by Dart. That's the point - it's there to serve their goals by diverting effort away from improving JavaScript - a project that benefits everyone towards supporting Dart - a project that benefits Google.
In Lars and Kasper Google I/O talk, they explain that V8 has become an extremely complex code-base, now weighing more than 500k LOC, with advanced compiler tricks to achieve the leading performance it currently has. The V8 designers think they're nearing the max performance ceiling possible with JS where it's unlikely they'll be able to get a further 2x perf improvement: http://www.youtube.com/watch?v=huawCRlo9H4
Which is in contrast to Dart which was developed with the input of VM engineers, is a much smaller and simpler code-base that is able to support proper classes, real integers and SIMD support which is already capable of delivering 10x faster startup times (with snapshots) and 2x faster and more predictable runtime performance which is still in beta and has yet to receive anywhere near the engineering effort V8 has.
Google is big enough to attempt 2 competing strategies to improve web development and performance, i.e. a faster JavaScript being led by the Standards committee that's enhancing JavaScript at a comittees pace and by introducing a completely new language for the web built from the ground up to be faster, structured and more consistent: http://infrequently.org/2011/09/google-the-future-of-javascr...
Dart wouldn't exist or have anywhere near the technical excellence it has today if it wasn't a sponsored project. Its existence also doesn't prevent any other browser vendors from trying the same thing - it may even encourage it if it yields noticeable end-user improvements.
The fact that others could try to make their own competitors is an exact description of the situation where the web breaks down in favor of proprietary solutions and the strongest companies end up owning the web.
The web doesn't have to worry about the strongest companies making too good compelling open-source solutions that people fear will end up owning it, we're in 2013 and web development is still fragmented, inconsistent and progressing at a glacial pace. The biggest threat is coming from proprietary native apps in walled garden mobile platforms being developed behind close doors without a standards body in sight and no desire for any open or interoperable initiatives.
Without any attempts at any new initiatives trying to make web development better, in the next 5 years we'd still be building buggy web apps on a broken language running at similar to todays performance - but hey, at least we waited for the standard bodies to create all possible solutions. All other attempts that stray from the script be damned.
If standards bodies are as feeble as you suggest aren't going to be a serious custodian for Dart anyway.
Ossified standards bodies or unilateral action are not the only options. Google could have engaged in cooperation with other interested parties throughout the development, so that it was a truly collaborative effort.
Whilst I agree there are technical problems that Dart is solving, they have chosen an approach designed to maximize their control over the web.
I read a lot of criticism of Google's centralized incubation of Dart, that it has not been developed by some standards committee. How would this prevent the nightmare scenario of a Google overlord (it's a _language_, for Pete's sake)? What was the last successful committee designed language you've used?
tl;dr Hate Google for all kinds of reasons, but judge the language on its merits.
Your TLDR says it all - you tell us to look at Dart as if it were some disembodied platonic entity independent of the goals of the corporation that controls it.
But Dart isn't independent of Google, so can you explain why we should limit our thinking like this?
You see, it's possible to separate the product from its origin.
A language has even less to do with advancing corporate interests (other than Google's professed goal to "make the web faster"), since it's an agnostic platform rather than a product designed to further a specific goal.
The real story is that Google wanted to go it alone rather than improve JS, and that's why there's Dart.
No. JavaScript has some warts that are more easily fixed by going a different direction, hence Dart. Diverting effort away from improving JavaScript isn't serving their goals, having a nicer language to develop in is.
I haven't seen anything about Dart (the big win would be eliminating the really slow DOM "GC" cycles on the webkit/blink side of things), but it would be interesting if this opened the way for easier VM integration. My understanding was that post-webkit they were tying v8 deeper into blink, though, not allowing more flexibility...
When Google starts shipping the Dart VM, then it will be a different story, of course. It will still not be comparable to asm.js, because asm.js runs in all browsers without the site author having to do anything (which would not be the case if Google shipped the Dart VM, as it would then be possible, and convenient, to write pages that only worked in Chrome).
> It will still not be comparable to asm.js, because asm.js runs in all browsers without the site author having to do anything
Dart web apps will continue to run in all browsers just as it runs today through Dart2JS, it even has great source maps support which lets you debug native Dart code even though it's running transpiled JS. There's nothing special the "author" would have to do, it already exists as part of the project template, e.g. if the browser has a Dart VM it will run the Dart code natively, otherwise it will run the Dart2JS version. Since some Dart benchmarks http://www.dartlang.org/performance/ show Dart2JS outperforming handwritten JS in V8 even with the overhead of different semantics, I'm assuming that Dart2JS compiles to efficient JS that developers wouldn't write.
> because asm.js runs in all browsers
runs is a technically interesting term, there are some asm.js demos that you would not attempt to run without asm.js specific optimizations (i.e. not Firefox) since it would be unusably slow. This is visible in the Epic Citadel http://www.unrealengine.com/html5/ flagship asm.js demo where it needs a Firefox Nightly release to run. The demo doesn't let you run it in IE10 and whilst it lets you try run it in the latest Chrome, but it crashes.
Even Firefox ended up reverting a correction fix (deviating from their JS SpiderMonkey VM) in OdinMonkey because it would invalidate its type checker and cause this demo to run with their normal (i.e. unoptimized asm.js) JS engine: https://plus.google.com/111090511249453178320/posts/cr4jTsfx...
So whilst it can in theory technically still run since its "just JavaScript", it can currently be either a broken, or unusable experience if you don't use Firefox.
Not true, Firefox uses OdinMonkey, which type checks the code, but then optimizes it using IonMonkey, the exact same pipeline all JS code uses.
> runs is a technically interesting term, there are some asm.js demos that you would not attempt to run without asm.js specific optimizations (i.e. not Firefox) since it would be unusably slow. This is visible in the Epic Citadel http://www.unrealengine.com/html5/ flagship asm.js demo where it needs a Firefox Nightly release to run.
This is simply false. You can run the Epic Citadel demo in Chrome (dev runs ok on my machine for example) and non-nightly versions of Firefox.
It is true that the Epic website recommends Firefox Nightly, that is outdated and it should definitely be removed.
The special interpreter is what I've inferred from pcwalton's comment of their being an optimized interpreter for it in Firefox. If its the same JS VM how can anything fail the type checker (e.g. forgetting a '+' or '|') cause it to run much slower? http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html and if its the same pipeline, how can an asm.js bug have different behavior to normal JS in Firefox? https://plus.google.com/111090511249453178320/posts/cr4jTsfx...
> This is simply false. You can run the Epic Citadel demo in Chrome (dev runs ok on my machine for example) and non-nightly versions of Firefox.
I've got the latest version of Chrome and it always crashes for me: http://imgur.com/Nrsxsdk I've tried it a few times and I've never seen it work in Chrome, It even crashes when I tried it in Dartium (a Chromium based browser shipped with Dart SDK). Though I don't have the dev version of Chrome to try it on.
> It is true that the Epic website recommends Firefox Nightly, that is outdated and it should definitely be removed.
Right, it works in normal Firefox which is what I meant.
P.S. it is good to have 2 from the Mozilla elite here to clarify Firefox internals :)
The type checker either succeeds or fails to type check. If it succeeds, we know all the types and send those with the code to IonMonkey (just like normal code, except with the types). Otherwise, we run it normally, and eventually it will also get sent to IonMonkey (with types inferred at runtime).
So failing to type check can make a difference in performance. It should not be large, and if you look on awfy, on most benchmarks it in fact is not (it is larger on large benchmarks though, which need more attention).
> I've got the latest version of Chrome and it always crashes for me
Yes, this was fixed by the Chrome devs, but not yet in a stable release. Please try the Chrome dev build for example, and you'll see it runs very well there. In just a matter of weeks that will be true in stable Chrome as well.
The code generation back-end and middle end are the same as IonMonkey uses (sans code generation patterns related to added IR instructions).
Overall both start of asm.js code compilation and end are highly customized and different from what happens to normal JS functions.
Whether this constitutes a separate pipeline or not is debatable. I think it does because none of this custom stuff is running for normal JavaScript no matter how you write it until you put "use asm"; in the right place. I am not debating that it is build on top IonMonkey though (my post from April states exactly that).
[One additional thing to notice is that asm.js typing rules are clearly at least partially duplicate what IonMonkey type inference already should infer statically for the JavaScript code, at the same time, if I am not mistaken, there is little sharing going on between OdinMonkey type-checker and TI engine.]
If this comes down to the semantics of "separate pipeline" then maybe that is pointless. There is some new stuff at the start and end of processing, as you say, but all the middle is shared, and that is by far the bulk of the code.
IMO it comes down to the fact that one developer wrote all the new stuff at the start and the end in a few short months. Compared to a team that took years to write IonMonkey and other parts of the JS engine that are shared. So calling this a new VM or new JIT is definitely wrong, and even calling it a new pipeline feels like an odd choice of words, since the "pipeline" used on asm.js code is almost entirely of the existing SpiderMonkey VM.
It is not a separate pipeline. asm.js uses the standard IonMonkey pipeline, with some additional IR-level instructions.
Furthermore, the argument that doing work on asm.js won't help normal JavaScript applies equally well to the Dart VM.
> There's nothing special the "author" would have to do, it already exists as part of the project template
I'm glad to hear that, but the fact that it is possible to just not serve the JS (or, just as badly, not test it: from what I've read elsewhere in this thread, the semantics of Dart2JS is not the same as the semantics in the Dart VM!) doesn't give me confidence that people won't write Web apps that depend on the Dart VM.
The worry is that Web apps will come to depend on the Dart VM being present. I have seen nothing to indicate that this is not a very real possibility.
> The demo doesn't let you run it in IE10 and whilst it lets you try run it in the latest Chrome, but it crashes.
That has nothing to do with optimizations and is a bug in Chrome's JS implementation. The ECMA standard says that asm.js is valid JavaScript.
> The worry is that Web apps will come to depend on the Dart VM being present. I have seen nothing to indicate that this is not a very real possibility.
Dart has always their primary goal to compile to efficient JavaScript:
> For languages that are quite different from JavaScript: it's important for Dart to compile to efficient JavaScript - http://www.dartlang.org/support/faq.html#compare-to-everythi...
There have been many times where language features were dismissed because they couldn't be compiled to efficient JavaScript (e.g. non-local returns and tail recursion). Google knows that Dart2JS is an important platform to optimize for (which has great source maps / debugging and tree-shaking optimizations) since it's the platform target that most browsers will be running and they want to ensure their own internal apps built with Dart2JS has a good experience across all browsers.
Following the mailing list, the only known deviation (that's wasn't a bug) is with some corner cases involving its use of arbitrary-precision integers: http://www.dartlang.org/articles/numeric-computation/ which relates from numbers in JS being stored in doubles (IEEE-754).
Other than that it's impossible for web developers to "target the Dart VM", the libraries in the Dart SDK are separated by platform so packages that can only run on the Dart VM like 'dart:io' cannot run on the client. Likewise there are some client packages like 'dart:html' that can only run in a browser and not on the server.
I've never heard anyone from Google state an intent to ship Dart VM in browser for general use without other browser vendors being on board (Dart VM for running Dart on the server, sure, and Dartium [Chromium with Dart VM] as a rapid-cycle tool for developers, sure), the specific reason being to encourage Dart use by not making it browser specific.
Heck, there's no reason, if asm.js catches on for optimized browser support, the preferred-for-client format of Dart couldn't move from compilation to bog-standard JS to compilation to asm.js.
asm.js is just JavaScript that works in all browsers and if a browser integrates an asm.js compiler, it'll run faster.
Yes there are deployments steps needed to serve both Dart and JS to browsers: Those steps are: 1. Include both the JS and Dart in your static resources. 2. There is no 2.
Since no general use browser implements the Dart VM, no one would do that, so its really pretty irrelevant.
That's right. My hope is that it continues to stay that way, absent browser-manufacturer consensus.
(for my personal projects, I genuinely love JS)
1 As someone who works in a large organization, I live this. Small groups with great programmers can make use of all the many tools and tricks for maintaining their project, but for teams fractured across time and space and governance, it is no fun.
http://arewefastyet.com/#machine=11&view=breakdown&suite=asm...
and you can see that saying that asm.js runs faster in a particular browser is just wrong. On many benchmarks Firefox and Chrome are very close.
In the end, asm.js speed is just like SunSpider and Octane and Kraken speed - it's something browsers compete on. That tends to reduce the differences over time, since all the JS engines are very capable.