5 ms·

Dart and Google Cloud Platform

81 points by pranavpr 12y ago

JoshMilo 12y ago
This is good news; I'm still waiting for the DartVM to get integrated into Chrome.
- shadowmint 12y ago
  realistically, this is unlikely to ever happen for both technical and political reasons. Theres certainly no immediate path forwards towards that end goal at the moment. Dart2js, atscript and other compile to javascript things are where its going to be at for the forseeable future.
  - WoodenChair 12y ago
    Care to elaborate? I believe it has been publicly stated in the past by the team that this is something being actively worked towards once OilPan (or whatever it's called) is finished? Has this changed?
kreas 12y ago
This is exciting news!
andyl 12y ago
"Runs best in Chrome", coming soon to a browser near you. The spirit of IE lives! https://twitter.com/jashkenas/status/525024739816116224 https://twitter.com/jashkenas/status/525024739816116224
- dragonwriter 12y ago
  Dart on Google App Engine via Managed VMs is about server side Dart, not client-side. (Client side Dart might have a runs-best-in-Chrome issue once Google integrates Dart VM into Chrome, but for now all practical web use is dart2js which only runs better on Chrome to the extent that V8 is better than other JS engines.)
- cromwellian 12y ago
  For a less snarky explanation of what's going on: https://news.ycombinator.com/item?id=8495498 https://news.ycombinator.com/item?id=8495498 We are working on it. Inbox was designed to be 'mobile first' and use "Material Design" animations, and pulling off 60fps animations of that style in an app like Inbox is very complex, in fact, each new version of Chrome broke assumptions and broke animations we had running previously. The Web, as a platform for competing with mobile-style interfaces, is in a rickety state at the moment, where performance is non-deterministic not only across browsers, but across versions. We often have to work with the engineers on the browser layout engines directly to resolve these issues. We're working full time on Firefox now, with Mozilla engineers helping, which is a lot easier to do now that the project isn't secret anymore. I do think it is unfortunate that the error page advertised Chrome. I think we could have handled that better by saying "Firefox is coming soon, we'll email you when it's ready, click here" or some such, rather than putting a 'Download Chrome' link.
  - azakai 12y ago
    Isn't this still fundamentally a problematic approach, though? Yes, being Chrome-only at launch was a bad idea (and the predictable response was that tweet and its thousands of retweets), but even if it were "Chrome + a notice about Firefox soon", and some time later it does run on Chrome and Firefox, that still leaves out all the other browsers! I understand that you want 60fps flawless performance for your new product. But if you need to work in close cooperation with a browser vendor in order to enable that, then either you work closely with all the browser vendors - which might be possible in theory, but unlikely in practice (you don't have enough resources/interest, they don't have enough resources/interest) - or your product will not run on all browsers. I honestly think this approach is not a good one. Alternatives which are at least less bad are 1. Let everyone run the app. Yes, some browsers will not hit 60fps. That's already true - even if they run it on your choice of browser, it may be on a slow machine. In this approach, some browsers will do less well, and one may be tempted to write something to the effect of "best experienced in X" but that's just getting back to that tweet (which while snarky, had a valid point). The best you can do here is proactively test on other browsers and file perf bugs on them. Reduced testcases can be filed before your product is public. or 2. Rely less on browser optimizations. As your linked comment correctly mentions, how browsers do layout, create layers, upload them to the GPU, etc. differs between browsers. But the web is no longer limited to that. You can use WebGL - now present even in modern versions of IE and Safari, which means in all browsers - which gives you explicit control of how to create layers, when to upload to the GPU, etc. Of course, this is no guarantee of 60fps performance everywhere (nothing is, there are slow GPUs, etc.), but it has a far higher chance of running at a predictable and high frame rate than letting the browser's layout engine guess for you.
- kevmoo1 12y ago
  Try out Pop, Pop, Win! (http://kevmoo.github.io/pop-pop-win/ http://kevmoo.github.io/pop-pop-win/) or any of our other samples on Firefox, Safari, or IE. Making small, fast, compatible Javascript is critical to the success of Dart.
tosh 12y ago
Looking forward to play around with this over the weekend. Great to have a low-maintenance way to run a full Dart stack.
woven 12y ago
More specifically, Dart on App Engine via Managed VMs. (Dart was already runnable on Compute Engine instances.) App Engine is a subset of Cloud Platform services and is a platform-as-a-service (PaaS) offering – auto scaling, a scalable datastore, logging and other managed services and guarantees that aim to substantially reduce your DevOps. By contrast, Compute Engine (and its closest competitor AWS) is more an infrastructure-as-a-service (IaaS) offering – provision your instances and run anything you'd like on it, as well as choose from available resources like load balancers and firewalls to meet your needs. Managed VMs attempt to offer the best of both worlds: the managed scalability of App Engine with the choice and flexibility of Compute Engine. Through a Docker-based container approach, App Engine scalability guarantees are still kept while allowing you to run your own language, like Dart or Node.js, and services. My Dart app, http://woven.co http://woven.co, has been running on Compute Engine, and I plan to move it to App Engine.

81 points by pranavpr 12y ago

JoshMilo 12y ago

This is good news; I'm still waiting for the DartVM to get integrated into Chrome.

shadowmint 12y ago
realistically, this is unlikely to ever happen for both technical and political reasons. Theres certainly no immediate path forwards towards that end goal at the moment. Dart2js, atscript and other compile to javascript things are where its going to be at for the forseeable future.
- WoodenChair 12y ago
  Care to elaborate? I believe it has been publicly stated in the past by the team that this is something being actively worked towards once OilPan (or whatever it's called) is finished? Has this changed?

kreas 12y ago

This is exciting news!

andyl 12y ago

"Runs best in Chrome", coming soon to a browser near you. The spirit of IE lives! https://twitter.com/jashkenas/status/525024739816116224 https://twitter.com/jashkenas/status/525024739816116224

dragonwriter 12y ago
Dart on Google App Engine via Managed VMs is about server side Dart, not client-side. (Client side Dart might have a runs-best-in-Chrome issue once Google integrates Dart VM into Chrome, but for now all practical web use is dart2js which only runs better on Chrome to the extent that V8 is better than other JS engines.)
cromwellian 12y ago
For a less snarky explanation of what's going on: https://news.ycombinator.com/item?id=8495498 https://news.ycombinator.com/item?id=8495498 We are working on it. Inbox was designed to be 'mobile first' and use "Material Design" animations, and pulling off 60fps animations of that style in an app like Inbox is very complex, in fact, each new version of Chrome broke assumptions and broke animations we had running previously. The Web, as a platform for competing with mobile-style interfaces, is in a rickety state at the moment, where performance is non-deterministic not only across browsers, but across versions. We often have to work with the engineers on the browser layout engines directly to resolve these issues. We're working full time on Firefox now, with Mozilla engineers helping, which is a lot easier to do now that the project isn't secret anymore. I do think it is unfortunate that the error page advertised Chrome. I think we could have handled that better by saying "Firefox is coming soon, we'll email you when it's ready, click here" or some such, rather than putting a 'Download Chrome' link.
- azakai 12y ago
  Isn't this still fundamentally a problematic approach, though? Yes, being Chrome-only at launch was a bad idea (and the predictable response was that tweet and its thousands of retweets), but even if it were "Chrome + a notice about Firefox soon", and some time later it does run on Chrome and Firefox, that still leaves out all the other browsers! I understand that you want 60fps flawless performance for your new product. But if you need to work in close cooperation with a browser vendor in order to enable that, then either you work closely with all the browser vendors - which might be possible in theory, but unlikely in practice (you don't have enough resources/interest, they don't have enough resources/interest) - or your product will not run on all browsers. I honestly think this approach is not a good one. Alternatives which are at least less bad are 1. Let everyone run the app. Yes, some browsers will not hit 60fps. That's already true - even if they run it on your choice of browser, it may be on a slow machine. In this approach, some browsers will do less well, and one may be tempted to write something to the effect of "best experienced in X" but that's just getting back to that tweet (which while snarky, had a valid point). The best you can do here is proactively test on other browsers and file perf bugs on them. Reduced testcases can be filed before your product is public. or 2. Rely less on browser optimizations. As your linked comment correctly mentions, how browsers do layout, create layers, upload them to the GPU, etc. differs between browsers. But the web is no longer limited to that. You can use WebGL - now present even in modern versions of IE and Safari, which means in all browsers - which gives you explicit control of how to create layers, when to upload to the GPU, etc. Of course, this is no guarantee of 60fps performance everywhere (nothing is, there are slow GPUs, etc.), but it has a far higher chance of running at a predictable and high frame rate than letting the browser's layout engine guess for you.
kevmoo1 12y ago
Try out Pop, Pop, Win! (http://kevmoo.github.io/pop-pop-win/ http://kevmoo.github.io/pop-pop-win/) or any of our other samples on Firefox, Safari, or IE. Making small, fast, compatible Javascript is critical to the success of Dart.

tosh 12y ago

Looking forward to play around with this over the weekend. Great to have a low-maintenance way to run a full Dart stack.

woven 12y ago

More specifically, Dart on App Engine via Managed VMs. (Dart was already runnable on Compute Engine instances.) App Engine is a subset of Cloud Platform services and is a platform-as-a-service (PaaS) offering – auto scaling, a scalable datastore, logging and other managed services and guarantees that aim to substantially reduce your DevOps. By contrast, Compute Engine (and its closest competitor AWS) is more an infrastructure-as-a-service (IaaS) offering – provision your instances and run anything you'd like on it, as well as choose from available resources like load balancers and firewalls to meet your needs. Managed VMs attempt to offer the best of both worlds: the managed scalability of App Engine with the choice and flexibility of Compute Engine. Through a Docker-based container approach, App Engine scalability guarantees are still kept while allowing you to run your own language, like Dart or Node.js, and services. My Dart app, http://woven.co http://woven.co, has been running on Compute Engine, and I plan to move it to App Engine.