Google I/O 101: Q&A on Introduction to Dart with Gilad Bracha

Uploaded by GoogleDevelopers on 20.06.2012


Welcome to this Dart Q&A on GDL.
My name is Seth Ladd.
I'm a developer advocate with the Chrome team.
And we're joined here today with two special guests--
Gilad Bracha, Dart language spec lead, and JJ Behrens, a
developer advocate joining with the Dart
team very soon, actually.
JJ BEHRENS: Yeah, very excited about that.
SETH LADD: Very cool.
Well, we kind of have a short amount of time. here.
So we're going to get to it and answer all these questions
that you had in our moderator for this GDL session.
So right at the top, did they find the Higgs boson today?
GILAD BRACHA: I didn't follow that.
SETH LADD: Oh, it just came out.
GILAD BRACHA: But they would have done it.
If they'd used Dart, they'd have done it faster.
SETH LADD: Absolutely.
Well, I think they're going to announce that coming up soon,
so that's good.
SETH LADD: First adopter, there you go.
Oh, wait that's not on the--
sorry, OK, the moderator says, Golgote from Paris.
"I'd like to develop apps for Android but
I'm allergic to Java.
Is there any chance to see Google eat its own dog food
someday and provide a complete Android SDK for Dart?"
Well, we're not on the Android team.
We're part of the Dart team, which is on Chrome.
We've heard this request a lot.
But I know that the Dart project is focused squarely on
making a fantastic development experience
for modern web apps.
JJ BEHRENS: And that would extend to all the mobile
devices, not just Android, as much as we love Android.
But we'd like to work everywhere.
SETH LADD: Excellent point.
We're all modern browsers.
John E from Texas asks, "I'd love to hear more about the
roadmap to bring Dart closer to the Google API ecosystem."
Well, some good news there.
You probably see an API console or explorer that
Google has for a countless number of APIs.
We are working on easy ways to integrate your Dart app with
our API services.
So we're still working on that.
But we will make it easier for you to plug into the existing
Google API set, like YouTube, I think, right?
JJ BEHRENS: Yeah, I love that new API infrastructure, where
you could have all the different APIs kind of behave
in similar ways.
And have one client library to rule them all.
So we're definitely working on that.
We hear your call.
This fine gentleman Seth Ladd writes, "I remember when Dart
was first announced, it generated a lot
of JavaScript code.
What's the latest on the Dart to JavaScript compiler?" Have
you been following that at all?
GILAD BRACHA: Well, we've been moving to this new compiler.
Dart to JS, which is actually essentially, even though the
project's very young, the third generation of our Dart
to JavaScript compiler.

I know they're working on that.
They're not where they want to be yet, in some ways, because
we're getting the semantics right.
It's actually getting, in some ways, a little bit worse in
some cases.
But Kasper's on it, and I'm confident that these numbers
will keep improving over time.
JJ BEHRENS: So, Gilad, I know that we're always talking
about this weird thing called tree shaking.
And I know we have a lot of tree huggers here at Google,
but I'm pretty sure that's not what we're talking about.
GILAD BRACHA: Right, so this is basically in the interest
of minimizing the amount of code that gets shipped down to
the browser.
In your program, if you do an analysis, you can often find
that the tree-- the abstract syntax tree, basically, that
you parse for your program--
contains lots of pieces that you're not
actually going to use.
And so you want to shake the tree and get them to fall off
so that you can ship less code.
So it's a way of basically reducing the code size.
SETH LADD: I'd actually take that and segue into a new
feature that we've working on a long time.
Mirrors, which is, I guess, the Dart way to do reflection.
But I think there's an interesting intersection there
with tree shaking.
Is that right?
Reflection makes--
well, they make each other harder, basically.
But basically what happens is if you're doing reflection,
you may have code that you're calling reflectively that the
static analysis can't find.
And so either it can't tree shake, which is bad because
your code will grow.
Or you may find that you had this thing you were going to
reflect on that was written in your file but didn't get
shipped down to the browser.
And so we're going to have mechanisms to let you say
that, even though this isn't statically in my code, I
expect this to not be shaken away.
The exact nature of that mechanism is still being
debated, but we're aware of the problem.
It's one of many.
It makes life interesting.
SETH LADD: Moving back to the moderator, Hussain writes,
"When will we see a Dart VM as a flag in Chrome and
JJ BEHRENS: Oh, that's exciting.
SETH LADD: Well, we have a Dart virtual machine in what
we affectionately call Dartium today, which ships as part of
our editor download.
And this is a build of Chromium with the Dart VM
embedded right in it.
And so you can run your Dart programs directly inside a
build of Chromium.
So we're on track.
And it's part of the plan to ship Dart VM inside of Chrome.
It's hard to tell.
But the best thing you can do to help make that happen is
download the editor, play with Dartium, and help us get there
even faster.
JJ BEHRENS: Yeah, I know that when they initially hired me
onto the Dart team, part of the reason they hired me is
I'm a fairly big guy.
I'm a lot bigger than you guys.
And I think that's going to be helpful in case any
PMs get in our way.
SETH LADD: OK, "Will there be a Dart UI control library
similar to maybe Closure Library, Ext JS?" Yes, we have
definitely on the roadmap this concept of a UI library.
The final form is yet to be worked out.
We're still working hard on that.
But the Dart project does come batteries included.
That's definitely the vision.
And so you can kind of work yourself up from language spec
to virtual machine to the libraries to the runtimes.
But then you have the kind of userland libraries, like a UI
library to help you write those web apps.
So it's definitely on the roadmap.
This one I actually hear numerous times.
"I'd like to develop Dart modular web applications with
a low initial load time.
Do you plan to support lazy loading of Dart libraries, or
is there any other way to accomplish this?"
GILAD BRACHA: There will be a way to accomplish it.
Now, lazy loading actually encompasses a
multitude of things.
And it's not clear that you'll have a completely general,
arbitrary lazy loading, at least not
without using fancy mirrors.
But definitely the issue of efficient loading of web apps
is very high on our list.
And there's going to be a good story for that.
The details are still a little murky.
JJ BEHRENS: Gilad, tell me a little bit more about how
Dart's going to make web apps start up a lot faster once we
get the Dart VM integrated into the browser.
GILAD BRACHA: OK, so the basic idea is that we have this
mechanism called snapshots.
And they let you--
even in the current stage, which I
expect will get better--
load a program 10x faster than by loading Dart code over the
network, where you have to parse it and all
that kind of stuff.
So that translates very directly into
good startup times.
JJ BEHRENS: Great, because I'm very impatient.
Another question here, going on. "Will Dart to JavaScript
compiler take advantage of ECMAscript 6 improvements like
class support in order to make generated code even smaller?"
GILAD BRACHA: I think it would.
SETH LADD: When it rolls out?
GILAD BRACHA: I'm sure that whenever that stuff is
available in the target browsers and so forth, where
it's useful to use it, it'll get used.
That specifically, there are probably differences between
ECMAscript classes and Dart classes, so it may be a little
naive to focus on that one.
We will have to look at it and figure it out.
But generally, anything that gets into JavaScript that
makes it easier for us, we will suck their blood and
leverage it to the hilt.
JJ BEHRENS: Do you think that there will be cases where we
hold back on some of those newer features of JavaScript
to ensure that we work really well with
slightly older browsers?
You know, ones that have JavaScript but maybe aren't
quite as cutting edge?
GILAD BRACHA: Well, I think so.
So we're targeting modern browsers.
Now, that's modern now.
If they have to be more modern in order to run some of this
stuff, we might not want to get that modern that fast.
Depending how--
this is something you just see-- what's deployed out
there, what you can bank on-- and make it
up as you go along.
SETH LADD: I think this is actually an excellent case on
something that Dart brings to the table today.
That is that the class syntax--
I find it very hard today to integrate code from different
libraries in JavaScript.
You have MooTools has their own kind of class builder.
And you have Ext JS has a class builder.
And never the twain shall meet, in a sense.
And when you bake class semantics into the language,
now I can share stuff across these
frameworks and libraries.
SETH LADD: Dart enables me to do that today, which I'm
looking forward to.
So this is a good one I hear a lot. "I'd like to see Dart
support in Google App Engine.
Will you enable this scenario?"
Dart works on client and server, but App Engine--
I don't know if we've thought about that one yet.
SETH LADD: Well, there's an existing bug for it.
JJ BEHRENS: Is there?
SETH LADD: I think in the App Engine bug issue tracker.
So definitely go there and star that.
It's not the first time I've heard that either, and so
that'd be kinda cool.
OK, we've got a couple minutes to wrap up.
Let's see--
oh, this is one that comes up a lot.
"When can we see a two-way communication between
JavaScript and Dart so that the rich features of existing
JavaScript libraries and frameworks can be exploited?"
Now, I think we want to do this generally.
But how does this impact the overall design of the system?
GILAD BRACHA: Well, it's rather complicated because
garbage collectors don't like each other.
They're sort of alpha kind of things.
They just won't--
it's very hard to have two VMs tightly coupled.
So the way we've envisaged doing this is through the
isolate mechanism.
And that, at the moment, is still a little painful because
of the asynchrony.
But there's thoughts about making synchronous covers for
this that should make it relatively painless.
JJ BEHRENS: Now, that'd actually be really nice, to be
able to have multiple widgets on the page.
And have them protected via isolate, so that people can't
reach in and monkey with my stuff.
And keep me a little bit safer.
GILAD BRACHA: Well, that's the idea.
SETH LADD: We should chat--
so you mentioned isolates.
We should probably talk just a second about
what isolates are--
isolated memory heaps.
It allows you to do a couple of different cool use cases.
For one, the security use case that you're talking about.
Another one-- it allows you to exploit multi-core systems
once you have separated memory heaps in your runtime.
You could run those concurrently or on a pool of
processes or threads.
And then there's the interop potential use case as well.
Can I use isolates to communicate between, say,
JavaScript and Dart?
JJ BEHRENS: Yeah, whenever I try to explain this, I always
try to say actors.
But then, of course, if you know what an actor, you don't
need to ask this question.
GILAD BRACHA: And the other great thing is, of course,
Dart on the server and Dart on the client should eventually
be talking through isolates, through message passing, and
not through browser-specific mechanisms.
That may take a little while, but--
SETH LADD: Absolutely.
I've heard that.
GILAD BRACHA: --that should make life
much cleaner and simpler.
SETH LADD: So I've always wondered what the-- so I guess
the wrap-up last question here, "What are some of the
design constraints for the Dart language.
That is, what's that box you're working in?"
GILAD BRACHA: It's a very small box because it has to
compile efficiently to JavaScript.
And it has to be sort of palatable to a large body of
mainstream developers, both from the Java world and the
JavaScript world.
And that's actually a pretty hard set of constraints.
SETH LADD: Well, I know I've really enjoyed it.
In fact, true story-- one day I was editing Dart code.
I had no idea it was Dart code.
It was so familiar.
I just pulled up the file, and I didn't even know it.
So good job on the familiarity.
With that, I think.
I want to thank our guests today, JJ and Gilad.
We'll be at Google I/O next week to give a bunch of
different Dart talks and chat with developers there.
And if you can't be there, we'll hold more of these cool
GDL sessions and more Q&As, and--
lots of ways to get ahold of us.
So I guess lastly, join our Dart mailing list if you're
interested in learning more.
And we're going to be there to help out, answer questions.
And thanks for watching.
And thanks for trying Dart.
JJ BEHRENS: Thanks a lot, guys.