Dartisans Ep. 2 - Chromium with Dart VM announced!


Uploaded by GoogleDevelopers on 15.02.2012

Transcript:

SETH LADD: Cool.
All Right.
So if you've joined us, please mute, and we'll open up for
questions later.
But welcome everybody who's watching on
air and in the hangout.
This is Dartisans Episode Two.
We have two special guests today from the Dart team,
Vijay Menon and Anton Muhin.
Hi, guys.
ANTON MUHIN: Hello.
VIJAY MENON: Hello.
SETH LADD: So thanks for joining us today.
This is really awesome.
Let's get right into it.
Tell everyone who's watching, and our YouTube friends at
home, what are your roles on the Dart team?
What are you doing in these days?
VIJAY MENON: You go first, Anton?
ANTON MUHIN: OK.
Thank you, Vijay.
So we're working on Dart's [? room ?], which is home to
Dart VM and to Chromium.
So we can get the best performance we can provide,
the best developer experience, and stuff like that.
SETH LADD: So you're working on integrating the Dart VM
into Chromium.
That sounds pretty exciting.
I know a lot of people are looking forward to that.
Vijay, what are you working on these days?
VIJAY MENON: Generally, my background's compilers,
runtimes, and I've been working the past while also on
DOM integration, browser integration, of the Dart
language, the Dart APIs.
And also very closely with Anton on seeing what it's like
integrating the Dart VM into the browser.
SETH LADD: Awesome.
Sounds like you have a sweet spot of background to help the
Dart team out, here.
Anton, what had you been doing before the Dart team?
ANTON MUHIN: Before the team, I was engaged into performance
work on the DOM bindings and on the [? 8th ?]
virtual machine.
Also I had some exposure to [UNINTELLIGIBLE]
before.
And I really hope this experience will help us make
the best integration possible.
SETH LADD: I would imagine that experience on the v8 team
would definitely be relevant to the Dart team.
What are some of the lessons that you learned from working
on the v8 team that's helped you with the Dart project?

ANTON MUHIN: Everything was minimal [UNINTELLIGIBLE]
matters when you talk about performance, because sometimes
[? there ?]
[? was ?]
much more to just if you can remove a couple of comments,
you get the biggest [? core ?].
So it's an exciting project, actually.
It's exciting stuff to work on.
SETH LADD: I know that performance has always been a
goal of the Dart team, so that's great.
Well, you guys have been working really hard today, and
I know we have a special announcement today.
What are we announcing today?
VIJAY MENON: We're announcing something?
[UNINTELLIGIBLE] down in Seattle.
I think that was it, right?
SETH LADD:
That was fast. [LAUGHTER]
VIJAY MENON: Anton, do we have a special announcement?
ANTON MUHIN: I believe so.
You go ahead, Vijay.
VIJAY MENON: Sure.
Well, you know, any of you guys who have been paying
attention, or just listen to what Anton and I work on, know
that we've been working on integrating the
Dart VM in the browser.
The builds are public, and I know a few of you brave souls
have actually built it from our public [? repo. ?]

We've been working on hosting binaries and making it easier
for you guys to do that.
And I believe Seth could probably give you the actual
time, but we'll have some instructions later today, you
think, Seth?
SETH LADD: Yeah.
VIJAY MENON: On exactly how to download binaries.
Mac and Linux today.
Windows very, very soon.
Fingers crossed.
We're just working on a few things with the VM team.
But Mac and Linux should be there today that you can play
around with.
Binaries this time, so you don't have to actually build
it yourself.
And it's actually just going to be the output of our
continuous build, so you'll get the latest
and greatest stuff.
That said, there are a few things we
want to talk through.
I don't know if it's a good time to do it, but where we
can give a demo later on, maybe.
SETH LADD: Yeah, that's fantastic.
So to reiterate, for everyone who's just joining us, welcome
to Dartisans Episode Two.
And we have just announced that we'll be releasing public
binaries of Dartium, which is Chromium with the Dart virtual
machine integrated into it.
And we'll make these binaries available later
today on our website.
This is huge news.
This is another step forward for our batteries included
Dart platform.
When we announced and launched last October, we had a virtual
machine, language spec, early revision, libraries, and now
finally, moving closer to this batteries included idea by
putting Dart VM into Chromium.
So this is great news.
Thanks, guys.
Can you talk a little bit about what it actually means
to integrate Dart with Chromium?
I mean, exactly what did you do?

VIJAY MENON: As you heard from Anton, he worked before on
putting v8s into the browser.
And this is kind of another exercise in doing that.
Embedding the VM itself in the browser means kind of drilling
all the holes through, getting all of the DOM integration so
that you can actually interact with the browser's DOM from
the Dart language.

Integrating it with things like developer tools, adding
the support for the MIME types, and so on.
Doing a lot of performance work.
So there's quite a bit to it.
Chrome is a big beast, and figuring out how to get this
to work, and work alongside the v8s has kind of been the
main challenge.

[INTERPOSING VOICES]
SETH LADD: Go ahead, Anton.
ANTON MUHIN: Sorry.
[UNINTELLIGIBLE]
cases you should be aware of, because all this stuff,
something like when you upload, [? you just ?] see
[UNINTELLIGIBLE]
[? collect ?]
some stuff, and how the API should behave, how the
application should be started, how you can then [? upload ?]
application.
There's a lot of difficult and [UNINTELLIGIBLE]
we have addressed, we hope to address.
And we wanted to explore, and ideally to provide the best
environment for the applications.
[UNINTELLIGIBLE]
SETH LADD: So if the Dart virtual machine is now
directly inside Chromium, that means I can run Dart code
straight up in Chromium.
But what about other browsers?
What do we have answers for those?
VIJAY MENON: Well, compiling to JavaScript using the
Dart-to-JavaScript compiler is still very, very
important to Dart.
That's how you will get it to run on other, modern browsers.
And to emphasize, it's not in Chromium proper.
It's in our branch of Chromium that we're calling Dartium.
This is very much a development tool that we're
working on and experimenting.
It is work in progress.
Those of you who really use it will know that you're really
using it when you managed to get an "Aw, snap" screen in
Chrome, and so on.
So very much work in progress.
We're trying to prove to ourselves and everyone else
that having native Dart support in the browser is a
good thing, and we're hoping for feedback on that.
I think that's kind of the point we're at right now.
Early feedback is if people like this
for development purposes.
They love the ability to be able to just edit their Dart
code and just reload in the browser and see it working.
And as we go forward, the VM team is working really hard on
performance.
We're working closely with them on performance with
respect to rendering in the browser.
And you should see a lot of those
improvements coming along.
So we're looking for feedback to see, does this make the
experience better, both with developing Dart applications
and running Dart applications, and I think we go from there.
Improve it in Chrome first.
SETH LADD: That's an excellent point.
This is very much a technology preview.
Along with the whole Dart project, which is still in
technology preview as we add features to the language, we
smooth out the libraries, and launch this stuff very early,
so as you say, get feedback from developers.
How can developers give us their feedback?
Any recommendations there?

VIJAY MENON: Tell us what works, what doesn't work.
In particular, file bugs.
It's a lot of the things people have been doing with
the Dart language and so on.
A lot of these things are just coming live.
Developer tools, support.
There's some preliminary stuff in there.
It's going to continue improving.

Give us feedback on what works, what doesn't work.
When things crash, please file bugs on us.
If things don't work, please file bugs on us.
That's a big reason why this is going out early.
ANTON MUHIN: And just [UNINTELLIGIBLE].
We are really looking for feedback.
We just did a couple of decisions when implementing
Dart, Dartium, and in some cases, we just
[UNINTELLIGIBLE]
We really hope to get feedback from people who do web
application programming so we can revisit our old decisions
and make things more convenient, more
easy for you to use.
So we're really, really looking for your feedback.
SETH LADD: So specifically, if you want to send us bugs and
issues, please do at dartbug.com.
That's a nice shortcut to get to our issue tracker.
So that's dartbug.com.
And on dartlang.org, you'll see links to our mailing list
where there's lots of active discussion, and many of our
Dart team participate there.
So lots of different ways to send us your feedback.
We launched this stuff early in developer preview
specifically to get your feedback, so
please don't be shy.
For everyone who's joining us, this is Dartisans Episode Two,
with special guest from the Dart team.
We've just announced the binaries of Dart VM integrated
into Chromium will be available
later today for download.
And we'll take questions for everyone, so please add
questions to our Google+ posts if you're not joining us in
the hangout, and we will route those into our guests.
In fact, we already got a question here from Google+.
John asks, why is it that the Dart support was shipped into
a separate build of Chromium in the first place, rather
than just shipping it into the Chromium builds?
ANTON MUHIN: The reason is actually simple.
Dart is complicated and very big system.
Dart [? and ?]
[? the ?]
[? bindings ?].
And we don't [UNINTELLIGIBLE]
right now, but we have all these resources out.
So we don't want to compromise stability, the ability of
Chrome, its current stage of development of Dartium
integration, but we are really aiming for that later on.
So when we think we're in better shape, and we don't
provide any security risk, and instability risk, any
slowdowns from Chrome when we don't compromise on any point,
we'll call to have Dart integrated into Chrome.
VIJAY MENON: And to follow up on that point, I want to
emphasize that this is a developer release.
Please don't use this for day-to-day browsing.
As Anton said, this hasn't gone through the stringent
security that we do this with Chrome builds.
It doesn't autoupdate.
And we basically set these things to expire in about a
week or two, so we want you to download--
this is, again, early.
We need to get it more stable before we can get this into
Chromium proper, or Chrome proper.

SETH LADD: And I think the question everyone's asking is
where can developers get this?
We will post links of this on dartlang.org later today, and
it'll be real easy for you to go and download, just like you
can download the Editor, et cetera.
So just watch for dartlang.org later today, where you can get
your hands on this.
This is cool stuff.
And Vijay, you answered the other question.
Will it be automatically updated?
I think you said the answer is no, this is not our normal
Chrome or Chromium channel.
This is a standalone, kind of snapshot build.
Is that the right way to think about that?
VIJAY MENON: Right.
Right.
SETH LADD: So now that we have the Dart virtual machine
inside a build of Chromium, can developers run both
JavaScript and Dart on the same page?

VIJAY MENON: Yes, they can.
That's one of those things that Anton talked about it.
Right now, you can't invoke one directly from the other.
And that's probably going to stay that way because of a lot
of the technical issues involved.
The way you can communicate with--
there'll probably a couple different ways you can
communicate between JavaScript and Dart.
First of all, JavaScript and Dart are essentially isolated
from each other on the page.
They can communicate via the DOM.
They can communicate via things like post
message on a window.
You can add a handler in Dart, and you can send messages to
it from JavaScript, and vice versa.
ANTON MUHIN: And ideally [UNINTELLIGIBLE]
ideally will prefer if you don't [UNINTELLIGIBLE] the
same DOM tree from both Dart and JavaStream
[UNINTELLIGIBLE]
pretty complicated and just [? kernel ?] cases.
So [? new ?] for communicating between Dart [UNINTELLIGIBLE]
you have an I frame or have just a subtree of DOM, and you
just communicate with something like post message
[? router. ?]
Just as a model of Dart, we hope [UNINTELLIGIBLE]
to communication of JavaScript.
SETH LADD: So it sounds like the recommendation is, use
post message right now to communicate between your
JavaScript code and your Dart code.
VIJAY MENON: Yes.
ANTON MUHIN: But you can have use cases when you want to
modify the same DOM directory.
Please let us know, because we are really looking for your
feedback for your experience, for your needs.
SETH LADD: So what it sounds like, it is possible today to
manipulate the same DOM with both JavaScript and Dart, but
that could get you into trouble?

ANTON MUHIN: It's very unlikely, but probably yes.
VIJAY MENON: Well, yeah.
You can put Dart scripts and you can put JavaScript scripts
on the same page.
They can both manipulate the DOM.
It's our intent to make that work perfectly well.
But today, expect to see some funky behavior, and if you do,
let us know about it.
And there's certainly still some technical challenges we
have to solve there with essentially garbage
collection, making sure things don't leak, get a little
complicated when you have two runtimes in the browser.

SETH LADD: It sounds like the expectation then is once we
get the kinks ironed out, you should be able to have both
scripts operating is it more or less concurrently?
Are they running in the separate
processes or separate threads?
Or how would you characterize Dart and
JavaScript parallel execution?
ANTON MUHIN: This is just a common DOM model when you have
the same stuff running on the main UI thread.
So you run a JavaScript for some time.
When you yield, then you run Dart script for some time, you
yield, and so on.
So nothing will change dramatically here.
Of course, if you don't use something like isolates or
[? workers, ?] stuff which adds real multithreading into
both Dart and JavaScript.
VIJAY MENON: Yeah, they do run in the same process, and
that's actually pretty important to getting
performance.
That's why Dart is very different from, say, a
plug-in, where if you look at plug-ins-- like, say, the Java
plug-in or others-- they typically don't interact that
tightly with the DOM.
They live in their own window.
In order to really write apps that interact very closely
with the DOM, you really need to be running on the same
process, tightly coupled with the UI of the browser.
And so Dart really sits right next to v8 in our builds, the
JavaScript engine.
SETH LADD: So John asks a good question.
Can you clarify, do the individual Dart script tags,
are they all running on the same UI thread?
ANTON MUHIN: Yes.
But in different isolates.
For each script tag, you have this on a separate isolate,
and involve on all those isolates from [UNINTELLIGIBLE]
the main UI thread of the browser.
SETH LADD: So if each script is running in its own isolate,
does that mean each script then is required to have a
main function?
ANTON MUHIN: Yes.
VIJAY MENON: That's correct.
SETH LADD: Can you just spend a minute
talking about isolates?
This is kind of a new concept if your
're JavaScript developer.
What does that mean each script is
running in an isolate?
ANTON MUHIN: An isolate is just a unit concurrency in
Dart, just unit [UNINTELLIGIBLE]
It's roughly a thread [UNINTELLIGIBLE]
So it's instance of the [? image ?]
as a separate heap, so we can ensure references between
different [? isolates ?].
And it executes on its own, but it doesn't always
[UNINTELLIGIBLE]
some [UNINTELLIGIBLE]
system thread.
As we talked just a couple of minutes ago, some isolates are
multiplexed on the same thread.
And we'll probably [UNINTELLIGIBLE]
support for [UNINTELLIGIBLE]

and stuff like that.
And to some extent, isolates are close to current
JavaScript [? workers ?]
but they're supposed to be more lightweight
[UNINTELLIGIBLE]

but [? workers ?]
should be heavyweight.
We expect isolates to be pretty much lightweight and
just roughly [UNINTELLIGIBLE]
formalize it.
VIJAY MENON: To follow up on the green thread point, so
different script tags run different in isolates.
Any isolates that can interact with the DOM all
run on the UI thread.
They're all multiplexed onto that same UI thread.
So it is really like a sandbox unit that in some cases can
run on background threads if they don't touch the DOM.
And we went with that model for better security.
We think we can build more secure apps that way.
Script injection's less of an issue because Dart scripts,
even if you inject a Dart script into a page, you can't
directly interact with other Dart scripts that
you have on the page.
SETH LADD: Which I think is a very important
clarification, right?
So you can potentially have multiple script tags, each
loading up a Dart file which has a main function.
Each one of those is running in an isolate.
If that Dart script touches or manipulates the DOM, it will
run in the same UI thread, but it's still isolated in the
sense that one Dart script doesn't know about the other
Dart script.
Is that true?
VIJAY MENON: Yeah.
It's somewhat similar to what we were just talking about a
few minutes ago about Dart to JavaScript communication.
Again, two Dart isolates on the same page, two Dart script
[UNINTELLIGIBLE] tags on the same page, can again
communicate via post message.
But they can't directly reach into each other's heap.
SETH LADD: Got it.

How does Dartium know if a script does or will
manipulate the DOM?
Do you look through the API calls as
you compile the script?

ANTON MUHIN: [UNINTELLIGIBLE] we apply a pretty simple rule
If you have script tag in the page, [UNINTELLIGIBLE]
manipulate DOM.
And currently [UNINTELLIGIBLE]
API to spawn [UNINTELLIGIBLE]
dominated isolates versus just plain isolates.
So roughly in API with the special call, we say, I want
to create a new isolate, but I want this
isolate to have DOM access.
Which means that this isolate will run on plain UI thread.
Or we say, I want to say it will spawn in our isolate, and
I don't care about [UNINTELLIGIBLE].
And in this case, you have the liberty to put it on any
thread which you find [UNINTELLIGIBLE]
convenient for us.
VIJAY MENON: Yeah.
The isolate API is definitely under a lot of
iteration right now.
Today, the declarative script tags are run
on the same UI thread.
You have to programmatically create isolates that run on
background threads.
SETH LADD: I see, OK.
And I think that if you're familiar with Dart has light
and heavy isolates.
And a heavy isolate, at least when compiled to JavaScript,
will go to a web worker.
But if you have a heavy isolate running inside of the
Dart VM in Dartium, that will just spawn a separate--
it doesn't go to web worker, right?
It just goes to a heavy isolate inside the virtual
machine, I would imagine.
ANTON MUHIN: Yes.
But once again, that's a very [? messy ?] topic for us,
what's the best way to divide the space between isolates and
workers, because both has its benefits, and to some extent,
both are pretty close concepts.
Once again, if that is [? good ?] for us, and this is
the area of [UNINTELLIGIBLE] research.
SETH LADD: OK.
So it sounds like we're definitely asking the
developer community, play with heavy and light isolates, play
with multiple script tags, and give us some good use cases
and feedback on how all this works.
ANTON MUHIN: That would be just awesome.
SETH LADD: OK.
So do I need to do anything special to activate Dart on my
pages here?
Or is just a simple script tag, is that all it takes?

VIJAY MENON: So we iterated on this quite a bit.
Part of the trickiness is just getting it integrated into
Chrome and WebKit, and figuring out what
the right hooks are.
With the binaries that are released today, you won't have
to do anything.
If you just have a script with the type application Dart, it
will go ahead and run.

Those of you who have built it in the past few weeks have
noticed that we changed this a few times.
We had a function that we were using from JavaScript to
bootstrap it.
If you look under the hood, that's still there.
We just have a way of just invoking that for you, so you
don't actually have to put it on your page.
And I'll show you an example later if have
some time to demo.
SETH LADD: Yeah, that's an excellent segue.
And for everyone joining us, this is Dartisans Episode Two.
We have special guests from the Dart team.
Today we've announced that binaries of Chromium plus Dart
VM integration will be made available later today on
dartlang.org.
And for everyone following along via the live stream,
please add your questions and comments to the G+ feed.
We'll be monitoring those, and we'll ask those questions to
our panel here.
But yeah, I think it's fantastic.
Let's see a example.
Can you show us a Dart program running in Dartium?
What does that look like?
VIJAY MENON: OK.
Let me try to share my copy here.

OK, is that showing up?

SETH LADD: Yeah, looks good.
VIJAY MENON: OK.
So this is Dartium.
You can tell it's the Mac by the boundaries and so on.
So as we were saying earlier, this is the
development tool right now.
Before I launch into anything, I just want to emphasize
what's in red here.
This is technical preview.
Don't use this as your primary browser.
It hasn't gone through all the deep security review that we
do for, say, production Chrome, and not even as much
as, say, the Chromium that you get from the dev channel.
So this is very preliminary stuff.
It's great for testing your Dart apps.
Don't go off, read your mail, go to news sites, or whatever
on this, because it hasn't been secured.
So that said, we wanted to do a few of those things to
integrate those in there to help developers.
One is that we wanted the start page just to emphasize
this point.
This is the home page when you launch.
It will give you information on Dartium.
So let's get to the meat of it.
As we said, the interesting thing here is being able to
run Dart applications.
And here's a very simple example of a Dart app, a
test.html that I've got here that's just got a script, an
application Dart script, in my bin.
Its importing the HTML library, and it's basically
running hello from Dart and adding that to
the body of the document.
And you can see that running here.
So again, this is pretty short and sweet.
Nothing really to it.
It's creating an element, adding it to the body.
There's nothing that you need to bootstrap it.
Just you will see the application Dart, and as we
reload it, it's there.
We can also run larger apps.
This is a test version of Swarm.
It's a newsreader that we've demoed before.
This is really what's just in the source.
It's not showing any articles.
But this is all running in the Dart runtime.
If you've seen it demoed before, you've seen it
compiled to JavaScript.
So we think cool things about it when you run it in the Dart
VM, is that you get the console here.
You can look at all of the scripts.
So this is an application that has some 60 Dart files to it.
They all just show up in the dev tools thing.
As you make changes, you can just reload it, and it will
just reload it in the browser.
So we really think that'll be cool for
the development cycle.
And this stuff just started coming up in
the past couple weeks.
Pavel, one of our colleagues in Saint Petersburg, has just
added a lot of support for dev tools.
Here I've set a break point on the onload thing.
So if I go ahead and I reload the page,
you can see it break.
Let's see.
He's just changing what you can see.
So again, much incentive to keep updating this.
You'll see more and more cool stuff here.
ANTON MUHIN: Tomorrow, the day after tomorrow, we should be
able to inspect your frames.
So it will be closer to full fledged [UNINTELLIGIBLE].
VIJAY MENON: Right.
So here you can see, you can already set break points and
continue on from there.
So I think this will be pretty cool to use for writing large
Dart applications.
Even if you intend to compile it to JavaScript, this is a
very nice way of developing.
And you get the native Dart runtime support.
We really like the dev experience, and that's the
feedback we've gotten to there.
SETH LADD: That's a good point, Vijay.
To reiterate, I think if anything, Dartium just really
makes an awesome dev experience.
You can think of, you're coding in the editor, you're
getting syntax highlighting, you're getting code
completion.
And you can run that Dart code straight inside Dartium.
Zero compilation step, there.
Test your app.
And then when you go to production, you can compile to
JavaScript and hit every major browser.
So if anything, Dartium enables us to move just as
fast as other web developers with no compilation.
I think that's just fantastic.
ANTON MUHIN: And [? develop ?] feature we expect to be
implemented pretty soon.
Something like in a couple of weeks, so we want to have
better integration between Dart editor and Dartium.
So you will be able to debug the code in Dartium from your
Dart editor [UNINTELLIGIBLE]
So we hope that it will help you as well.
SETH LADD: That's an excellent point.
I'm looking forward to that.
VIJAY MENON: And one other thing I want to show up here.
You'll notice this Dart tool tip here.
The icon's probably a little hard to see over there.
We've integrated this kind of playground here that we found
really useful for testing out stuff.
This is sort of analogous to the Dartboard app if you used
it on Dartlang, except it's actually just running locally.
There's no server involved here.
It's just running.
And of course, it's also running on the VM, so it gives
you a chance to see what works on the VM, what
doesn't work on the VM.
As you find problems with APIs or stuff like that, this is
also a great way to test something out, send us an
email saying, hey, I tried this in the playground and it
didn't work.
So basically, this is stuff you can go
ahead and edit here.
"Hello from Dart today." And it just goes ahead and runs.
And you can play around with that.
The other thing here is that you can look at the console,
and you can get error messages.
So print also just prints the console.
It's like console.log, for those of you who are
familiar with that.
Let me see if I can go ahead and open that.
You can see that, open the dev tools console to see this just
printed out, when we went and clicked on run.
Let me try that more time, you'll see the message appear
one more time.
So again, it's a really easy way, even if you're not really
interested in the browser, you just want to play around with
what can VM do, what are the semantics of this or that,
play around with the language.
The playground is really handy for that.
And error messages will improve.
But here, let me just take out this quote here.
So I've got a badly formed program, and you see the error
message here.
Unterminated string literal, line 3, position 43.
Again, that can be improved, but you get the messages that
can really help you see what's going on.
And as you load your Dart apps to- if you have a syntax
error, just open the console.
You'll see the errors from the VM show
up here on the console.

SETH LADD: That is so cool.
VIJAY MENON: I can go ahead and fix that.
We'll see that running again.
OK.

So anything else you want to show, Anton?
ANTON MUHIN: Probably not.
VIJAY MENON: I'll just add one thing Anton
actually just added in.
Let's see if this works.
ANTON MUHIN: I think it's Chrome version.
VIJAY MENON: I think I actually went to this thing.
But yeah, another thing is you can see the version of the
Dart VM that's integrated here now, as well, along with
everything else.
As you do report issues or run into issues, please let us
know what version number you've got, and that will help
us reproduce things and fix stuff.
SETH LADD: It would be very cool if in the console, you
could have "report this bug."
VIJAY MENON: Yeah.
Yeah.
We've talked about that.
Especially with the playground, it's just such a
nice way of writing test cases that are small, and say, yeah,
this API doesn't work.
Seth, you've been following a lot of bugs lately in the past
week, so you know it's a nice-
SETH LADD: I don't call them bugs.
I call them opportunities.
VIJAY MENON: Opportunities.
You've been sharing many opportunities with us, with
the team recently.
So, yes.
SETH LADD: I have a couple questions about how this fits
into the other features of the Dart virtual machine.
For one, Dart can run in two different execution modes,
production and checked.
Production mode will run with the type assertions turned
off, and check mode will turn on those type assertions.
Oftentimes, check mode is very useful during the debugging
cycle and the authoring cycle.
How do I toggle between these two
different modes in Dartium?
VIJAY MENON: You want to take that one, Anton?
ANTON MUHIN: OK, if you don't mind.
So for now, it's not very convenient.
For now, we have to provide a special--
when you start Dartium, you only provide [UNINTELLIGIBLE]
just environment variable which [UNINTELLIGIBLE]
flags and enables checkit mode.
For example, enable [UNINTELLIGIBLE]
We are going to open that, and eventually want to expose
somewhat APIs so that we can control this setting in more
convenient way.
And we hope to publish a tiny article, just maybe a page,
maybe even less, how to enable those [? checks ?]
later when Dartium release will go official.
SETH LADD: Right.
We will publish those when we publish the
how to download Dartium.
So we'll include the instruction how to flip
between these two modes.
Do you think we'll eventually put those into about:flags?
ANTON MUHIN: Maybe, maybe just. We definitely have one
option we have discussing something like that.
You can switch this mode on directly from the Dart.
So something like you start the Dart application, and you
say, on check mode, something like that.
We are really discussing it these days.
It's another thing [UNINTELLIGIBLE]
VIJAY MENON: Yeah, we definitely want to make it
easy to run check mode.
By default, it's off, as you can see if this
example is still up.
I just said, [UNINTELLIGIBLE] message equals a string here,
and you can see it's still running just fine here, and
printing it out.
That's because we're running in production mode.
If you do run it in check notice, as Anton said--
today you have to use a set environment flag to do that--
then you would see an error on the console saying that the
type check fails.
In check mode, you'd have a type check on
that line right there.
ANTON MUHIN: On the good side, when we have is planned
integration with Dart editor, Dart editor should be able to
start Dartium for you with all the flags properly set.
So in development mode, you will have this check mode for
free, and you won't have to default with nested flags,
[UNINTELLIGIBLE] and stuff like that.
VIJAY MENON: Yeah, that's a good reason to use the editor.
I think they already have the support in there to fire off
in dev mode, and I highly recommend it for
development of apps.
It will run slower, but when you're trying to find bugs,
it's great to have this check here and catch this.
Presumably you put [UNINTELLIGIBLE]
message, because you want to actually convey something.
And you will get that check in check mode.
SETH LADD: So Vijay, you can flip back to you and
[UNINTELLIGIBLE]
Awesome, hi.
So John asks another good question.
Another feature of the Dart ecosystem is
the support of snapshots.
Snapshots allow you to take a snapshot or kind of a binary
[? serialization ?]
of the heap of the program right
before it starts executing.
This we've seen in our internal test really speeds up
initialization of the program.
Is this something that Dartium supports today, snapshots?
And if not, what's the plan there?
ANTON MUHIN: Oh, yes, we do some support snapshots, which
really supports two kinds of snapshots.
So the first snapshot allows you--
once again, in Dart everything is an isolate.
So we have a very fast way to start an isolate from a
snapshot, which loads all the libraries you have to use.
And that gives us a quite reasonable startup time for
the application, and still want to improve upon it.

Dartium supports now an interesting feature.
It's only partial application snapshot, which allows you to
make binary representation of the application, which it
starts on top of the libraries.
And we have experimental support in Dartium for caching
of these partial snapshots.
So roughly, if you have a huge application, you
would start it once.
Program is able to cache this binary [UNINTELLIGIBLE]
application.
And next time you will open this Dart application, it
starts even faster, because you're starting
directly from snapshots.
This is an experimental feature, because it might have
security implications.

We had some interesting discussions about caching
policies of this partial snapshot, because
[UNINTELLIGIBLE]
normal web case, server can tell you how long you're
allowed to cache this resource.
But [UNINTELLIGIBLE] application consist many
parts, so we need to devise a reasonable policy for caching
partial snapshots.
But we really hope to have something like that
eventually, because one of our goals is absolutely blazing
startup time for your [? old ?] applications.
SETH LADD: So this application snapshot experimental feature,
it sounds like that's actually here today, and we as
developers will be able experience this much faster
startup time on the second load.
Is that something we should explicitly test for you and
send feedback on?
ANTON MUHIN: If you please.
Right now, in the current build of Dartium, it will only
work for you if you reload the application in the same tab
due to technical difficulties.
Later, we can expose it, for example, under the
[UNINTELLIGIBLE] so we can switch it on and off to
experimental test. [UNINTELLIGIBLE]
we will just [UNINTELLIGIBLE]

VIJAY MENON: Also today, if you turn it on, it won't
interact very well with dev tools, because of course,
there's some tricks.
Dev tools likes to work off the actual scripts, and the
snapshot actually doesn't need the scripts.
So that bridge will be closed too, so there's still some
things to clean up there to make it really easy to use.
But yeah, an app like Swarm, I'm pretty excited to see what
we do with snapshot.
As we saw, there were like 60 different files that write.
So being able to have the snapshot just cache that in
the browser and restart from that I think will be great as
we deploy these applications.
SETH LADD: I'm really excited for this feature, actually.
I agree improving startup time has always been an important
goal of the Dart project, and I think snapshots are going to
help tremendously here.
VIJAY MENON: To follow up Anton's point about there
being two levels of snapshot.
So things like dart:dom, dart:core, dart:html, those
are all part of a snapshot that you're getting for free.
So we're actually starting from the snapshot that's
already defined all those things in there, and that's
why we can have a bigger library there, which are
library for Dart and not pay so much for
it at startup time.
SETH LADD: So if I write a random Dart script-- like you
had the "Hello world" example there--
and an imported dart:html.
Does that mean when the Dart virtual machine inside
Dartium, loads up your "Hello world" simple, three-line
script, it's already starting from a
snapshotted version of dart:html?
ANTON MUHIN: Yes.
SETH LADD: That's pretty impressive.

Let's take some questions from the Google+ stream here.
Alan asks, is there an API into the operating system
environment settings from within Dart?
And I can't tell if this is specific to Dartium or not.
ANTON MUHIN: Exposing API, which can access operating
system services from the browser, sounds like
[UNINTELLIGIBLE]
due to various security considerations.
So we are not aiming to provide any additional API
than just a typical browser already has implemented in
JavaScript.
But if you're [UNINTELLIGIBLE] have a use case, maybe the
better way would be, for example, to improve on file
API in the browser.

VIJAY MENON: Yeah.
I mean, in terms of the operating system capabilities
or other environment capabilities, we're not
looking to add anything new to Dart that you can't do in
JavaScript.
We really want to get that from HTML5.
HTML5 is starting to add more and more cool stuff that lets
you have local storage.
I think particularly for mobile devices, there's all
kinds of cool stuff you can get.
And our goal is to really expose that in Dart,
not drill new holes.
You really want to be careful about providing access to that
sort of stuff so you can do it in a very secure way.
SETH LADD: That's an excellent point.
I think it's important to reiterate that the Dart inside
the browser effort, we're following all the lessons
learned, all the best practices, all the security
reviews, eventually, that the JavaScript world has pioneered
for many, many years.
That is, we're operating on the same types of constraints
that any other scripting language, like JavaScript
inside the browser.
And that's very important for us to do.
I think to answer Alan's question, though, from the
server side, Dart does work on the server as well.
And nothing we're doing with the language design or
libraries paints us into any kind of corner for just client
side web apps.
So I believe on the server side, it would be interesting
to be able to find the system OS environments.
We already have server side support for opening socket,
server side support for reading files off the native
operating system file system.
So Dart is definitely being designed holistically to be an
end-to-end solution, server and client.
But these kind of questions about operating environment
settings, as Vijay and Anton mentioned, that would really
only apply to running on the command line over on the
server side.
VIJAY MENON: Yeah.
One thing that's cool about that is there'll be libraries
that will let you access that on the server.
So I think dart:io, I haven't played around with it much,
but that has a lot of the sort of stuff you'd want on a
server to access the local file system and such.
And that library will not be available in the browser,
because we're not going to give you the ability to just
go mess around with the user's file system.
SETH LADD: You're operating in the same kind of sandbox
security environment that any other JavaScript file would be
running in, which is very important.
Mark from the Google+ stream asks, will Dart eventually be
submitted for standardization by a body outside Google, or
will it continue to be primarily a Google technology?
I'm interested in Dart, but not in learning a Google
version of VB scripts.
What's our general philosophy there?
VIJAY MENON: I don't know what the timeline for
that is going to be.
I'm not probably the best person to answer that.
You'd probably give as good of an answer on
that as I could, Seth.
But I think eventually, sure.
I couldn't really comment on what the--
SETH LADD: Yeah.
I think that eventually standardization makes a lot of
sense, especially as we target Dart for the entire open
modern web.
But we think it's very early to talk about that, and right
now we just need to get to a 1.0, get to some sort of a
shipable production-ready version.
And I think only then does it make sense for us to begin the
standardization process.
I do want to be clear about this comparison of VB script.
I don't think that's entirely very fair.
Dart has been open source ever since our initial technology
preview launch back in October.
And it has always been compilable to JavaScript, and
it will always be compilable to JavaScript.
And so, Dart is very much aimed, since day one,
explicitly at the entire open modern web.
So I think it's a way to encourage developers from all
different app platforms to develop and deliver fantastic,
complex, engaging apps for modern web.
And to do that, we'll always have to compile the
JavaScript.
So I don't think the comparison of VB
script is very fair.

Let's see.
Jay from the Google+ stream says, regarding check mode,
has there been any discussion about using check mode checks
to report code coverage?
Since all checks happen at runtime, they don't do any
good if they're not being hit.
Reporting number of checks that are never executed would
be a great quantitative testing tool.
ANTON MUHIN: We really hope that Dart will have
[? great ?] tools eventually which will make
developer life easier.
And we [? could ?]
have something [UNINTELLIGIBLE]
as well [UNINTELLIGIBLE]
which we use currently for checks, can be used to produce
[UNINTELLIGIBLE]
I don't think it will come in just a couple of weeks, but
eventually we want to provide the best development
experience we can.

SETH LADD: So we have about 10 minutes left.
So if you want to get your questions in,
please join to hangout.
There is room here.
Or post to the Google+ stream.
For those who are going to download Dartium later today
and start testing this out, are there any caveats they
should be aware of other than, of course, this technology
preview, and please don't use it for day-to-day browsing.
But for instance, does it create its own profile, or
does it use the existing profile of their currently
installed Chrome or Chromium?

VIJAY MENON: You want to take that, Anton?
ANTON MUHIN: If you don't mind.
I think just to say, once again, Dartium
is the project preview.
So we would really recommend you to create a separate
profile for Dartium, because you probably don't want
Dartium to mess up with all your bookmarks and your
personal stuff [UNINTELLIGIBLE]
profiles.
So it's just a sanity measure to keep your regular Chrome,
if you have Chrome as your regular
browser, and Dartium separate.

VIJAY MENON: If you're running regular Chrome--
not Chromium, but Chrome--
alongside Dartium, and Dartium is the only-- you're not
running Chromium, it should just by default have a
separate profile.
But if you do use Chromium for some other reason, you have
two different Chromium builds, they will
trample on each other.
ANTON MUHIN: And we will provide guidelines in the
Dartium documentation how to use a
separate profile for you.
SETH LADD: That's right.
We'll include in the documentation we'll release
later today how to set up your own profile directory so you
don't trample on other existing compound Chromiums.
That's why it's usually great for testing, too.
You can blow away the specific profile if you need to start
fresh, and you don't mess with anything else.
So, absolutely.
So let's take another question here from the G+ stream.
Are there any difficulties you face as a developer when you
develop Dart because it needs to compile to JavaScript?
Is there anything that will become impossible to compile
the JavaScript?

VIJAY MENON: That's a really good question.
It's certainly not our intent.
I mean, as Seth said earlier, compiling the JavaScript is
very, very important and will be important for
a long, long time.

So Dart, I mean, in my view is one of the reasons why we have
a new language here, is that we wanted to create something
that you could compile pretty faithfully down to JavaScript,
but still you gave a better developer experience.
So I think for the foreseeable future, I don't see anything
where you wouldn't be able to run it on JavaScript.
I think down the line, you'll get benefits running natively
as Dart because you get better performance, better startup,
check mode, stronger checks, and so on.
But your apps should run in JavaScript, absolutely.
SETH LADD: I should probably add that through some of my
experimentation, there are very corner cases we still
have to work out to be totally transparent.
For instance, Dart, its integers are arbitrary
precision, for instance.
You can just bang on your keyboard all day for an
integer, and Dart will go ahead and suck that in.
But when you compile that to JavaScript, JavaScript has
limits on integer precision.
So there is a slight disconnect there.
There's some open bugs there, if you're curious about that.
And so, this is why we launch, I think, in technology
preview, too, right?
We want real developers to test this out, and help us,
first, identify these corner cases, and then help us
understand what it is that they want the system to do in
these kind of cases, as well.
But generally, as Vijay said, the intent is to be able to
compile to logical, same performance JavaScript, and
that's a core tenet of the language, absolutely.
ANTON MUHIN: And for example, we have a huge pile of tests,
and we run both [UNINTELLIGIBLE]
Dart VM, Dartium and compile to JavaScript code.
And we try to minimize the difference between the results
[UNINTELLIGIBLE] absolute possible minimum.
SETH LADD: So as we wrap up here, what's
next for you guys?
What's the next couple weeks or months look like for you in
the Dart team?

Vijay?
VIJAY MENON: Sure.
Well, we're going to make things better.
Dev tools, you're going to be seeing big changes there over
the next few days, actually.
I think Pavel's got some changes coming in that will
help stuff.
Anton said--
I talked about snapshotting as something he's been
working on a lot.
Isolate APIs.
Also dart:html is something under active development as
well, and basically we're working to make sure you get
the same experience on both the JavaScript path and the
Dartium path.
But sometimes one runs ahead of the other, but we're
actually using a lot of the same scripts now to generate
the implementations for both to keep those things
consistent.
So a lot of improvement on APIs, a lot of
improvements on dev tools.
We're doing a lot of performance testing right now.
We just really started on that.
So a lot of things that Anton alluded to the very beginning.
He did a lot of work on v8, which is a fantastic
experience.
He knows where a lot of the problem areas are.
But we're just starting to benchmark,
hammering on the DOM.
And we got a ways to go there, but we fully intend to make
that very fast and yet consistent between Dartium and
compilation to JavaScript as well.
SETH LADD: Anton, anything to add there?
What's next for you with Dart?
ANTON MUHIN: Just one important thing.
We are not complete on the API implementation because in some
cases we had to take shortcuts just because we don't have
enough hands.
We are going to improve our [UNINTELLIGIBLE]
APIs, especially some [UNINTELLIGIBLE]
APIs.
And that would be a constant goal for us, I think, at least
for a couple of months [UNINTELLIGIBLE]
SETH LADD: I think you bring up an excellent point.
A lot of Dart isn't done yet.
We're still in technology preview.
So the main ask for our developers out there is please
do try all these different aspects of the Dart platform.
The editor, the language, the libraries, the virtual
machine, the JavaScript compiler, and now Dartium.
And please do join the mailing list. Please do file new
issues, dartbug.com.
We definitely listen to all this feedback.
Our team is very well-engaged and listening to
what's going on.
So please do try it all out, and let us know.
And it looks like one more question, because I know this
comes up a lot, from John.
So reflection, our mirror-based reflection API.
Do we have any ideas?
Is this weeks, or months, or years away?
VIJAY MENON: I don't know, actually, to be honest. Not
weeks, but I know it's being actively worked on.
I don't know what the timeline for that coming out is.
SETH LADD: Yeah, I get the sense that this is a large
implementation effort than maybe some other, just like,
pure library features.
And so I do know that it's very, very close on the radar,
and there's active discussion to work on it.
But yeah, we're not exactly sure what any kind
of timeline is there.
But definitely we'll be delivering a mirror-based API
at some point for us to experiment with.
Well, I want to thank everybody for joining us for
Episode Two of Dartisans.
We hope to continue these with your support, so please do
leave some comments on what worked and what
didn't on our G+ stream.
And as always, join our mailing list at dartlang.org
and let us know what's working for you and what you'd like to
see from the Dart platform.
So on behalf of the whole Dart team, I want to say thank you
to everyone.
And Vijay and Anton, thank you very much for being our
guests, and congrats on getting Dartium released.
That is big, and we'll open that up for downloads, if all
goes well, later today.
VIJAY MENON: Thanks, Seth.
ANTON MUHIN: Thank you.
SETH LADD: All right.
Thanks, everyone.
We'll see you next time.
Bye.