Google releases first beta SDK for Dart, including 20% faster analysis engine(thenextweb.com)
thenextweb.com
Google releases first beta SDK for Dart, including 20% faster analysis engine
http://thenextweb.com/google/2013/06/19/google-releases-first-beta-sdk-for-its-dart-javascript-alternative-including-20-faster-analysis-engine/
73 comments
The idea of Dart is great - but the 'Google' brand attached to it is very worrying. Dart feels like exactly the type of service that Google will just drop in the future if it doesn't get popular quickly enough, and with only Google supporting it, that makes any code written it in a huge risk. Google's track record is the single clear problem facing Dart at present. Personally, I've been holding off on Dart for exactly that reason.
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 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?
As someone professionally responsible for maintaining and extending a legacy GWT project, I couldn't agree more with this view.
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.
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.
Wait, what? My sympathies for maintaining legacy GWT, but that isn't at all equivalent to Dart except in that they both have JS compile targets. Go is at least a somewhat more reasonable comparison, but still isn't great. The biggest problem with any legacy GWT project is all the widgets people loved to make and use which grafted unnaturally to JS and the DOM, and certainly not the code transpiler, which is all that really matters here.
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.
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.
GWT may have been released 7 years ago, but it isn't like it was abandoned 5 years ago and the last stragglers have been dying off since then. The release tempo didn't fall off a cliff until the end of 2011, which just so happens to be when Dart was announced.
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.
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.
Since GWT is open source, Google 'dropping' it (many largish Google projects use GWT and they still commit code) is not the death knell for GWT based projects. For the same reason it is being actively developed and has a steering committee and regular participation of googlers. It is also 'probably the best cross-compiled JS framework in the world', to borrow a phrase from the beer industry. Full-featured and works today, not 'maybe in five years' which is what Dart promises (I'll be the first to jump onto it when/if that time comes).
> I'm not advocating using Dart in production
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.
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.
Well I don't see why my advocacy would be the dealbreaker either way :) Unless you mean if it's not to be used in production, then what's the point? It's a new language; that's how they work. I wouldn't recommend people use Rust in production yet either, but that says nothing about its future.
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.
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.
Don't forget that Dart is not just a language, it's also a tool ecosystem, with a virtual machine that is already faster than V8 in some key benchmarks.
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.
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.
How can you compare a language that introduces a bunch of syntactic sugar over JavaScript semantics (CoffeeScript) with a language that brings a cleaned and streamlined semantics (Dart)?
Only in the sense that I could have also compared it to any of the other languages that compile to Javascript. It was not meant as a commentary on the value of the language design. In fact, it was the opposite: Dart's mere existence doesn't mean I have to care about if people should be writing pure Javascript or worry about any potential Javascript existential crises Dart might raise. And that's great.
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 :)
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 :)
I don't think this is a problem. It's rather uncommon for languages to be supported in the first place. Rather, independent contractors become experts in the language and pick up the slack.
> Another similar worry: if Dart really does take off, will Google not just drop support for other browsers besides Chrome from stock Dart?
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.)
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.)
"Dart feels like exactly the type of service that Google will just drop in the future"
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.
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.
This is exactly why I'm not touching it. At least with GO they are using it in all there servers, so you know they will be supporting it for a while.
Two corrections: 1) We are not using Go in all of our servers. Java, C++, and Python are very prominent. Go is just getting started internally. 2) Dart is being used internally, we won't be dropping it.
Can you say which internal projects are using Dart at Google? Were they new systems, rewrites, or evolutions of existing JS systems?
They got some patches from the finance department and Google were really insistent on adding big integers to JS so it looks like they're using it for currency. Woo... exciting.
Dart is an unilateral project aiming to: "ultimate goal is to replace JavaScript", "rescue browsers from JavaScript" or "Google preps Dart to challenge JavaScript". Being open source here, is not good enough.
I have played around with Dart - very nice to use the same language on client and server. I have a small client server example: http://blog.markwatson.com/2013/05/complete-but-small-dart-c...
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.
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.
Barely on topic. Here's a recently posted video on a Dart alternative called TypeScript.
http://channel9.msdn.com/Blogs/Charles/Anders-Hejlsberg-Stev...
http://channel9.msdn.com/Blogs/Charles/Anders-Hejlsberg-Stev...
Finally google will have a proprietary language to compete on a level playing field with Apple without having to worry about web standards.
By "proprietary language" do you mean fully open sourced with a liberal patent covenant and a well documented hosting API that as a goal encourages its adoption and contributions, that's being developed in the open and is in the process of being standardized once released?
Yes, because none of that will have any effect on Google's control over what runtime goes into Chrome and their ability to make unilateral decisions about the language's future. It's fully owned and controlled by Google.
> their ability to make unilateral decisions about the language's future
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
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
No - not like JavaScript.
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.
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.
The purpose of a language isn't to divert effort away from a language it compiles to as a first-class concept. That's actually not a goal, that's just someones cynical view of a potential side-effect when trying to invent a new more productive language for the web without JS deficiencies, with better language semantics, faster start-up and predictable run-time performance.
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...
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...
You can get snapshots in JS just by structuring the code in a certain way (ala asm.js). You can get the same performance benefits by having a more limited subset (like Dart, no eval or dynamic code loading).
The real story is that Google wanted to go it alone rather than improve JS, and that's why there's Dart.
The real story is that Google wanted to go it alone rather than improve JS, and that's why there's Dart.
Ok these are fair technical reasons for them doing this. Nevertheless Google's strategy also happens to leave them in control of resulting language and platform.
Once its standardized anyone is free to safely implement it from the language specs, which they don't even have to do since they are free (and encouraged) to use the open-source implementation.
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.
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.
'Once it's standardized' is a chicken and egg statement - since to be standardized can only happen if other parties get on board. If nobody does, Google can say 'well we tried', whether or not they made any serious attempt to involve others in the process (which thus far it would apper they have not).
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 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.
You can submit a language specification as a standard without outside buy in. It becomes an open specification that anyone is free to implement. You seem to interpret every open initiative Google tries to do with Dart as a bad thing. What else can they do? How much more open can they make the implementation to appease critics? What haven't they done yet to make it any more open? V8 was open sourced and its now powering node, running server side procs in PostgreSQL databases, creating rich cross-platform Desktop apps with node-webkit - what has Google done to stop it's pervasive use? Before V8, JS performance was orders of magnitudes slower than it is today, with little focus on performance - and now there's an arms race.
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.
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.
The web ending up being controlled by Google isn't 'saving' it from proprietary platforms at all.
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.
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.
But how Google's "control" over Dart (meaning: "leading the development"), maximize their "control" over the Web (meaning: "currently providing the best suite of applications")? It's a language. If it takes off, it will be self-sustaining. Has IBM's "control" over Eclipse given IBM dominance over the Java ecosystem?
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.
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.
> serve their goals by diverting effort away from improving JavaScript
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.
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.
But standardization, a strong goal of the project founders, will.
If Google submits Dart to an independent standards body that has a governance model that includes other interested parties e.g. Mozilla, Apple, W3C, and doesn't make Google king, and if Google agrees to adhere to the standard and not just rush ahead with a de-facto standard reference implementation that people write anyway to because it's in Chrome, and if other browsers widely integrate Dart, then it would no longer be proprietary.
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.
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.
Except: it compiles to JavaScript and you deploy that. When I was playing with Dart, I think it worked fine with Firefox, Chrome, and Safari.
Why the comparison with Apple? Apple doesn't use a proprietary language.
Apple is in complete control over its version of Objective-C, the runtime, and the libraries. The fact that parts of this are contributed to open source projects makes it no less proprietary.
Apple didn't invent Objective-C. It was adopted by NeXT 25 years ago. It wasn't used to create lock-in. Of course Apple is going to improve the language. It was badly in need of some improvements. They are the only company that has an interest. I don't think they keep any changes locked up at Apple in order to prevent other companies from adopting it. In fact, it would be great if someone got it working well on Android.
Where is the "Works better on Google Chrome" badge?
Google Chrome has yet to implement the DartVM, I believe the OilPan memory experiment allowing for multiple languages to interact with the DOM without leaks is experimental still.
Secondly, Dart compiles to efficient Javascript and works on all modern browsers.
[deleted]
Sounds interesting, is there more information on that that I can read?
Check out https://groups.google.com/a/chromium.org/forum/?fromgroups#!... or just look for oilpan on blink-dev.
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...
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...
Thanks, yeah, that was my guess too (fix leaks by GCing DOM stuff, which is a nice idea), I was surprised to hear it was related to Dart somehow. I can't seem to find anything online explaining a connection between them (is it just speculation?).
There's no Dart VM in Chrome atm. So any Dart app in Chrome has to run the same compiled JS like every other modern browser.
Right next to the "Works better on Firefox" badge for asm.js?
Ignoring the snark (which I realize you did not start), that is totally irrelevant. Look at the numbers,
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.
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.
asm.js is just JavaScript. It is not remotely comparable to Dart.
Dart compiles to just JavaScript that works in all browsers, and if a browser integrates the Dart VM, it'll run faster.
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.
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.
The difference between asm.js and Dart is, as I mentioned before, that it is impossible to serve a Web app with asm.js that does not work in all modern browsers, due to the fact that asm.js is just JavaScript. With Dart, however, if you serve the Dart and don't include the corresponding JS, then your app only works in browsers that implement the Dart VM.
> With Dart, however, if you serve the Dart and don't include the corresponding JS, then your app only works in browsers that implement the Dart VM.
Since no general use browser implements the Dart VM, no one would do that, so its really pretty irrelevant.
Since no general use browser implements the Dart VM, no one would do that, so its really pretty irrelevant.
> 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.
That's right. My hope is that it continues to stay that way, absent browser-manufacturer consensus.
Please correct me if I am reading you wrong: so you hope that web developers will never get access to a better development platform?
This. Set aside that Javascript has hit "peak speed", its failures for large codebases are fundamental [1]. I don't agree with the Google hate, but I can understand. What I don't understand: outright denial of the possibility of something better than JS.
(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.
(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.
The "absent browser-manufacturer consensus" limitation in the post suggest that the hope is that a better development platform won't come with the cost of a fragmented web; i.e., that whatever the choice is for improvement (Dart or something else) it won't be one or more vendor-specific targets, but one broadly-accepted target that can be used freely without worrying about either locking-out users of other major browsers or providing different browser-specific alternative s.
Which compiles to JavaScript with Dart2JS.
That's correct. There is basically nothing comparable between asm.js (which is a subset of JS with a JavaScript interpreter optimized for it) and Dart (which is a language that currently compiles to JS with no special compiler optimizations in any engine that I'm aware of).
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).
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).
Only Firefox uses a separate special interpreter (Odin Monkey) for asm.js - Chrome's asm.js improvements come from optimizing the same V8 JS pipeline. Having a separate compilation pipeline can be viewed as a disadvantage since any optimizations for speeding up asm.js doesn't improve JS performance: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html
> 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.
> 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.
> Having a separate compilation pipeline can be viewed as a disadvantage since any optimizations for speeding up asm.js doesn't improve JS performance: http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html
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.
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.
> 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.
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.
> 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.
> Only Firefox uses a separate special interpreter (Odin Monkey) for asm.js
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.
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.
> Not true, Firefox uses OdinMonkey, which type checks the code, but then optimizes it using IonMonkey, the exact same pipeline all JS code uses.
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 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 :)
OdinMonkey is: a separate front-end for optimizing compiler (one that translates JavaScript code to compiler IR), a couple of IR instructions specific to asm.js (e.g. asm.js heap access), plus AOT linker, trampolines for transitioning to/from asm.js code and some runtime infrastructure specific for bounds check elision on 32-bit platforms. Potentially there will also be a separate parser added to the mix.
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.]
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.]
> Whether this constitutes a separate pipeline or not is debatable.
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.
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.
> 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?
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 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.
> When Google starts shipping the Dart VM, then it will be a different story, of course.
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.
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.
They are working on changing some internals of Blink project (code name oilpan) so that both Dart and V8 can work better with it.
My understanding is that they will ship Dart VM with Chrome once it is ready regardless of other browsers decision. This will probably be post 1.0 tough.
Actually dart2js compiles a "Dart-like" language to JavaScript. The "dart-like" doesn't include big integers or operator overloading on numbers.
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