

Dart and Google Cloud Platform - pranavpr
https://www.dartlang.org/cloud/

======
woven
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.

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

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

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

------
kreas
This is exciting news!

------
andyl
"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)

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

~~~
cromwellian
If we had the resources and didn't have constraints to co-launch with Android
Lollipop and iOS, making it work on all the browsers out launch may have been
feasible. We had bugs filed for most of the issues in our internal tracker,
but we ran out of time before launch.

This is a problem at big companies like Google and probably Apple, is that we
time major sets of released functionality for 'big impact' launches like
Google I/O, or other media events, and the poor engineers are left working
late into the night to meet the deadlines.

As for just rendering everything with WebGL or Canvas, we could do that
(Google Sheets uses Canvas), but it kind of rubs me the wrong way, it doesn't
feel "webby". You end up reimplementing tons of stuff: Bidi/I18N text
handling, A11Y, system behaviors like text selection, clipboard, it just seems
like you're making your own Flash runtime in JS, an alien hybrid that
displaces the entire browser engine.

I hope apps like Inbox, and the new focus on mobile web performance by both
Google and Mozilla can fix many of these layout/rasterization/composite
hazards, either at the spec level (e.g. will-change), or at the implementation
level, so much like there is a 'war' on JS performance, there can be a 'war'
on layout and paint performance.

Long term, if we want the web to succeed and not be destroyed by mobile native
apps, we need it to work -- as the web --, and not as simply opaque WebGL +
JS, that's basically just a native app model with a different VM.

~~~
azakai
I get what you're saying about i18n in the alternate approach. It's harder to
do those things there.

But isn't "designed for Chrome and Firefox" just a marginally better thing
than "designed for Chrome"? It's still tailor-made for specific browsers, just
2 instead of 1. That's very un-"webby".

