Dartisans ep 12 - Dart + Web Components

SETH LADD: Sweet.
JOHN MESSERLY: Hey, John Messerly, working on Web
Components with Sam and Jacob.
JACOB RICHMAN: Hi, I'm Jacob Richman, another [INAUDIBLE]
up in Seattle, working on Dart Web Components.
SETH LADD: Thank you very much, guys,
for taking the time.
I know Web Components is a pretty big topic.
And so we're going to skip over the news.
Probably the big thing just to reiterate for everyone
watching at home is M1 is getting closer.
JJ BEHRENS: Yeah, that's really exciting.
I see that Google just pushed a new update to the spec.
That's good reading to--
I don't know.
I get excited reading those things.
SETH LADD: Yeah, definitely.
And we've got a lot of breaking changes coming in,
trying to get in under the wire under M1.
You can follow all those at news.dartlang.org.
So lots going on.
But let's go ahead and dive into the big topic here, Web
Components.
You've read the spec, JJ, right?
JJ BEHRENS: Yep.
And watched the video.
SETH LADD: And watched the video, awesome.
So is there a way for you to sum it up in just a few words?
JJ BEHRENS: Yeah.
Well, there are these guys.
And they like object-oriented programming.
And so they walk around, and they're classy guys.
So, of course, we need to have classes.
And they want to subclass things.
And they're looking at the web page, and they see elements.
And they're like, well, I want to subclass that.
And I want encapsulation.
And I want stuff like well hidden.
And then I want templates.
And then I want to configure my CSS with variables.
And then you cram it all together, and you get
something wonderful in the browser instead of just at the
framework level where every framework has to implement
their own widgets.
SETH LADD: Perfect.
And I think that's one of the key points, at least for me,
is that this isn't just happening in user
space, if you will.
This is happening at the platform level.
And so let's turn over to Seattle.
And I'd like to learn how Dart is actually intersecting with
Web Components.
Because it's my understanding Dart is language and libraries
and virtual machine.
And then we're coming in with Web Components, things
happening actually deep inside the browser.
So I'd like to start off with learning how did these two
worlds actually intersect?

SAM HOPKINS: I can talk about that--
make myself be in the picture.
There we go.
So Web Components and the technology behind it are
language agnostic.
So they should work equally well in Dart and JavaScript.
They're an entirely declarative technology, or a
mostly declarative technology.
So in Dart, just as you would be able to in JavaScript, you
can do something that looks like
subclassing a DOM element.
So you can generate your own custom subclasses of divs and
videos and legends, like this Hangout.
You can add custom Dart behavior to those, and you can
use our templating tool that is inspired by the stuff that
comes out of Web Components to hook up data to your
components.
Anybody else want to speak about the intersection of Dart
and Web Components?

JJ BEHRENS: One of my favorite things when I think about Dart
versus Web Components is that when you look at JavaScript,
there's what?
16 different ways of implementing object-oriented
programming?
And every framework has its own approach to subclassing.
And Dart comes along and has a way to do classes and
subclassing.
And it is the way for all of Dart programs.
So all Dart programs can interoperate, because they
understand what a class is.
And Web Components do that at the browser level for widgets.
So we'll have a way of having a great calendar widget from
this team interoperate with the great maps widget from
this other team.
JOHN MESSERLY: And that's actually why I think it was so
important for us to do this in Dart.
Because we're already trying to bring structured web
programming.
That's kind of what we're doing in Dart.
And we finally have addressed this idea that you can have
one way of doing object-oriented programming.
So it seems very natural to--
oh, and the other thing we're doing, of course, is
improving the DOM.
And it seems very natural to take those two things together
and say, hey, well if we're improving the DOM, why can't
you just extend from it, as if those were just normal Dart
objects, as if it had been written in Dart.
SETH LADD: So in the Web Components world, I can now
finally create a subclass of button, which I think is huge.
And so that's a big point I want to make sure everyone
understands, is that you have all these elements today, part
of the normal DOM, dibs, spans, buttons, paragraphs, et
cetera, and all of the existing web development
frameworks out there today always have to wrap a lot of
these elements to provide extensions and behavior.
In a Web Components world, you can actually extend the button
and create your own specialized button.
Is that true?
SAM HOPKINS: Yeah, absolutely.
We should make clear that the mental model is that you're
creating a Dart subclass.
But because there's this extra DOM stuff going on, you also
get to attach custom DOM to your subclass.
So you're subclassing in the sense of adding Dart behavior.
But you're also subclassing in a sense of customizing what
happens on the DOM when you instantiate your fancy button.
You might say that your fancy button has some extra images
in it and some text.
And those will get encapsulated just like the
Dart behavior that you've attached to it gets
encapsulated.
JJ BEHRENS: That's one thing that I really like, is that
the web has traditionally lacked a way of encapsulating,
so that if you're going to have a widget, you have all of
this DOM stuff that's in the tree.
And you're trying to see the widget, but all you can see is
a bunch of divs.
And finally, with the shadow DOM, we could have one tag
that has some semantic meaning with all the stuff hidden away
in a nice, encapsulated way inside of it.
[AUDIO LOST]
more beautiful markup.
SETH LADD: So Jacob, JJ just mentioned the shadow DOM.
Can you tell us what exactly is this shadow DOM?
Sounds a little bit nefarious to me.
JACOB RICHMAN: Yeah.
So what the shadow DOM is is when you're creating your own
custom element, they say it's extending div, you're going to
want to implement how it's rendered.
And you're going to implement that just using the same HTML
that you're used to and ready to create.
But you're going to implement it in what's called the shadow
DOM for the element.
So this is going to be a DOM that only you as the component
creator sees.
When someone opens up their Web Inspector, by default they
won't be distracted by the non-semantic divs and side
divs that you might be using to make your component
rendered the way you want it.
JJ BEHRENS: That's huge.
When I first saw the shadow DOM I thought it was Bob
Nystrom's doing.
SAM HOPKINS: Ah, yes.
SETH LADD: Well, the evil Bob, his evil twin.
JJ BEHRENS: The evil Bob, where it was Google's evil
plot to take over the world and make
web programming easier.
JACOB RICHMAN: And the interesting thing about the
shadow DOM is this was technology that actually did
exist in the web platform but was only used for native
controls, like video controls.
SETH LADD: I was just going to point that out.
We actually can see real-world application of this, as you
just mentioned, that if you embed a video tag into your
page and the player controls, like play, pause, and the
slider, that's actually implemented with actual DOM
elements like divs and spans, right?
JACOB RICHMAN: Yeah, exactly.
And it's just in a shadow DOM that as a user you haven't
been able to see or been able to manipulate.
But now you'll be able to have that
same power as a developer.
JJ BEHRENS: So another thing that I like about the
encapsulation is the boundaries that Web Components
place around the Web Components so that they can
have their own CSS.
And the CSS from the outside doesn't leak in, and the CSS
from the inside doesn't leak out.
Do you guys want to talk about that?
JOHN MESSERLY: Sure.
It kind of all goes back to what we're talking about with
the shadow DOM, which is it would be really mean if we're
like, hey, here are these components, but to render them
you have to draw at a canvas or something.
That would be really hard.
So we say, well, you can use DOM primitives.
And, of course, once you're using browser primitives,
well, if you just display dibs and spans on a page, they're
going to look like nothing, right?
They're no good without some styling.
So you need to be able to style your shadow DOM in such
a way that nobody else can affect it.
And they call that the--
there's basically an upper boundary and a lower boundary
that prevents your styles from leaking to your children and
prevents styles from the page from leaking into your shadow
DOM unless you want to.
So you can always turn on--
they also give you the power, if you want to turn on, styles
flowing in, and you can do that, too.
JJ BEHRENS: Yeah, and [INAUDIBLE], and it kind of
goes for events as well, where if an event generates within,
kind of deep inside the Web Component, and bubbles up,
it's kind of sanitized so that the stuff from the inside
doesn't get to the outside.
Do you guys want to talk about that?
JACOB RICHMAN: Yeah.
So you'll just see the event's firing on your component
instead of firing on the specific element deep within
your component.
That's what's going to make sense.
If you're using a fancy input element, you want to see the
event firing on the fancy input element.
You don't want to see it firing on--
SAM HOPKINS: Some random div.
The idea is that the user of your widget, just like we've
been able to do for 15 years outside of the web, the user
of your widget should not be able to tell the
implementation details by any way.
They can't query for them.
They can't figure it out with events.
They can't figure it out by setting crazy styles and
seeing how your widget changes.
It has to be real encapsulation.
SETH LADD: It always comes back to that encapsulation
term, which, as, JJ, you were saying in the beginning, is a
concept that a lot of other programming languages
environments have always had.
And now we're bringing it to the web.
So we've talked about encapsulating the structure.
And then you can place that inside the
shadow DOM of an element.
We've talked about encapsulating the styles using
scope styles sheets so they don't leak outside.
So now I want to talk about encapsulating behavior.
We've talked about structure.
We've talked about styles.
But what do Web Components bring to
encapsulating behavior?
We mentioned Dart.
We mentioned JavaScript.
What can I do now?
What can I have these elements do?
SAM HOPKINS: Anything you want.

As far as Dart is concerned, if you factor out all this DOM
stuff, these are just subclasses of DOM elements.
They really are.
You get--
JOHN MESSERLY: Fields.
SAM HOPKINS: Huh?
JOHN MESSERLY: You get fields.
SAM HOPKINS: You can add fields.
You can add methods.
You have all the stuff that you would
have imagined already.
You have private fields and public fields and getters and
setters and so forth.
And you will really just write this like it's a class body
for this element.
And then when you query for it in the page or for some reason
you get a hold of this fancy element, you'll be able to
call methods on it or access its fields and so forth.
SETH LADD: That's so cool.
JJ BEHRENS: Yeah, I remember we gave a code lab at Google
I/O. And when I looked at the code, it was kind of
interesting.
Because you guys were structuring it in such a way
where you would hide the DOM stuff inside of it.
And then you would expose these methods, such as if you
have a stopwatch widget, then you would have a method that
would say start timing.
And so I'm excited about the fact that Web Components are
going to give us the same thing, where we have a list of
methods that these are the official approved ways of
interacting with this Web Component.
SETH LADD: And we should say that
sometimes it might be methods.
Other times it might be setting attributes or creating
subelements inside your custom element.
Through your work with working with Web Components so far,
have you seen any--
I don't know, maybe it's too early--
design patterns emerge?
Or what seems to be the flavor of the day in terms of how you
might actually interact with these Web Components?
Or is it too early to tell?
SAM HOPKINS: You want to talk about it?
JOHN MESSERLY: Yeah, I can say something.
It is pretty early to tell.
But there's definitely some patterns where you're using
attributes.
So if you have properties that can be expressed as
attributes, it's really nice.
Because in your HTML page on your element, you can just
write your attribute.
You can easily data bind it.
We haven't talked about the data binding yet, so maybe I'm
jumping ahead a little bit.
But it'll interoperate better between Dart and JavaScript.
So we know we can make attributes work really well.
So that's definitely one pattern we've seen.
SETH LADD: But let's actually talk about that for a second.
Because I want to make sure everyone understands what
we're talking about.
So we've talked about these kinds of components.
And you can create them, put them on your page, and even
interact with them programmatically, or set
attributes.
And so can you give an example of a case where setting the
attributes is more or less equivalent to calling a method
on the component?
JACOB RICHMAN: Suppose you had a component that was
a Google Maps map.
And so you have an attribute that's latitude and longitude.
Now set the attribute, the position of
the map will change.
SAM HOPKINS: And we should be clear that when you're writing
a Web Component, all the plumbing to make this happen
is abstracted away for you.
So when you write a Web Component, you'll implement
some method, like attribute changed or
something like that.
And eventually the browser, or for now our polyfill runtime
system will just call that method for you whenever your
attribute has changed, and you can handle that appropriately.
So you don't have to worry about mutation events and
observation and all this business.
It just all works.
SETH LADD: Cool.
JJ BEHRENS: Great.
SETH LADD: And before we get to that, because you're kind
of leading towards how do we actually all make this work in
today's world, first, how do you package these Web
Components, at least what the spec is saying?
What do these things really look like?
What are the tangible assets?
SAM HOPKINS: Can we do a demo?
JACOB RICHMAN: Yeah, let's do a demo.
SAM HOPKINS: Let's do a demo.
Give us two seconds to get the screen sharing up.

JJ BEHRENS: But you're not allowed to spend any more time
than it took us to actually get the show live today.
SAM HOPKINS: So we've got about half an
hour, is that right?
JJ BEHRENS: Yeah, we're really sorry about that, guys.
We had some audio issues.
SAM HOPKINS: All right.
So I think this is the one I want.
Screensharing working?
Everything happy?
SETH LADD: Looks great.
SAM HOPKINS: Awesome.
So I don't know if I'm going to do MVC.
It's a little app that people write in their various
different frameworks to demo what code looks
like in that framework.
So it's a to-do list app.
I'm going to close the Web Inspector here so we can play
with it a little bit.
It's a to-do list app.
We can add to-dos.
Today the web, tomorrow the world.
And I can mark them done, remove them--
SETH LADD: So awesome.
SAM HOPKINS: --stuff like that.
So not a super exciting app, but it's a good way to demo
what stuff looks like in the Web Components world.
So let's pull up the Inspector.
And let's first look at a super simple component.
So you see this little photo down here that just has some
text in it, double click to edit a to-do.
So I've made this a component.
And I should preface this by saying that it's not
necessarily the case that you would want to make something
at that small level of granularity
component in a real app.
But it's a nice way to demo how these suckers work.
So down here in the Inspector, you can see this div is x
to-do footer.
Another note is that we're not totally settled
on the final syntax.
So you will probably actually have a tag that says, x to-do
footer, instead of this div syntax.
But the semantics are the same.
So you can see this div is equals x to-do footer, which
we can't open up.
We can't see anything below it.
What actually is below it is a shadow root.
And we will be able to turn on an extension in a minute that
lets us actually see the shadow DOM down there.
But what's actually below it is just some paragraph tags.
So let's look at the code for that.
Let me share a different thing really quickly, one sec.
Actually, it's the same thing.
I'm sorry.
I didn't mean it.
OK.
So again, this is another place where the syntax is all
kind of in flux, but the semantics is not likely to
change all that much.
SETH LADD: I'm sorry, Sam, what are we
looking at right here?
What file is this?

SAM HOPKINS: How should say this?
This is a source file that doesn't actually go through
any existing compiler yet, compiler that will exist
pretty soon.
SETH LADD: But moving one level up, what we're looking
at here is actually a component.
It that true?
SAM HOPKINS: Yeah.
So let me highlight.
What we're looking at, what's highlighted, is the source for
that footer component.

So you see, we have this element tag that allows you to
declare a DOM subclass.
And this component doesn't have any Dart behavior.
We're just talking about the DOM subclassing stuff here.
So I can tell the system what tag I'm extending.
I can tell it what the name of my custom element is. .
And then I can add some custom DOMs.
So remember that double click to edit a to-do
line that we saw?
There it is.
It's this DOM that gets injected
inside the custom div.
Does that make some sense?
JJ BEHRENS: Yep.
SAM HOPKINS: Awesome.
So that's how the DOM subclassing part of it works.
Let's look at a slightly more complicated one, with some
Dart behavior.
So if we open up the actual app here--
oh, I can't open beneath but the to-do list, because the
extension's not on.
That's OK.
So here's the--
JJ BEHRENS: I'm sorry.
You said something about an extension.
You want to mention just a little bit more about that?
SAM HOPKINS: Yeah.
I'm using a laptop that's not mine, which is why this is a
little bit iffy.
There's an extension to the Web Inspector that you can
turn on for development purposes that lets you look at
what's in the shadow DOM.

JOHN MESSERLY: So imagine if you could look
inside your video tag.
SAM HOPKINS: Right, exactly.
But for now, we can work without it.
So here's the actual to-do list component,
which is a big thing.
It actually wraps some other components inside it.
And we have a couple of different design patterns for
how to do that.
And we'll look at another example of it in a bit.
Sorry, that was the wrong tab.
So let's look at the to-do list component.
So here it starts now at the top of the page.
We have this element that extends div.
The name is to-do list component.
And here's some fancier features that happen in here.
So you see in these template tags, like before, we've got
the custom DOM that's in this element.
So it's got an input, and it's got a list,
and it's got a footer.
JJ BEHRENS: Oh, I love that.
How many times have I wanted to have a style tag
that was just for--
SAM HOPKINS: So check this thing out.
So this is how we do this scoping the CSS business.
So this style scopes tag makes it so that the CSS declared
inside will only apply inside this widget.
It doesn't leak outside the widget, which is super cool.
This allows us to just set the footer font.
In this case, we're using for something fairly silly, but
it's a good demo.
But here's the cool part.
And again, as I said, the syntax is in a little bit of a
flux, but the semantics are the same.
So here's a class body inside this script tag.
And I can't actually put the whole thing on the
screen right now.
And this class body contains the fields methods and so
forth that get attached to the to-do list element.
So you can see I have this add to-do method that gets passed
to to-do, which is some other object I've defined elsewhere
that just encapsulates the information about
a particular to-do.
And when you add a to-do, the widget will create a new to-do
list element.
It'll bind the data to it.
And we'll talk about how to do that automatically later.
And then it'll add it to its own DOM.
JJ BEHRENS: I'm a little bit confused.
It says, script type application slash JavaScript.
But I see types.
So it looks like Dart.
Can you tell me--
SAM HOPKINS: Right.
So remember how I said this is a source file that doesn't go
through any compiler right now?
We haven't actually been able to check it.
That's an error.
That should say application Dart.
I apologize.
Or it may--
I don't know if you know, Jacob, what the current
version of the syntax is.
That script tag may not actually exist.
It may be in a separate file.
JACOB RICHMAN: No, you could write it like that.
We could look at the syntax, the version
that's currently there.
SAM HOPKINS: OK, well, in a minute, we'll look at one that
actually runs through the compiler as it exists.
Sorry for the slight disjointedness here.
SETH LADD: That's OK.
SAM HOPKINS: So hopefully this gives you an idea of how these
suckers work.
Let me find--
OK, so here's one other piece.
There's these lifecycle methods that you can subscribe
to that will be called on your component at
the appropriate times.
So here's this created method that I have that I'm never
actually calling in my code.
But the runtime system knows when I've created one of these
components, and it'll call this created method for me.
And it allows me to set up some fields and so forth.
It acts a little bit like a constructor, except it doesn't
actually do the construction itself.
Again, there's this inserted method that gets called when
the component is inserted into the main DOM that allows me to
set up event listeners and so forth.
And you can see, I haven't actually done
anything with them.
But there's these other lifecycle methods, in
particular, the attribute changed one that we were
talking about, that'll just automatically get called when
one of your attributes gets changed.
SETH LADD: This is great.
So we see an element tag here that encapsulates, quite
literally, actually, the structure of the new element--
we saw that there--
the style of the element, and then the
behavior of the element.
And it's all one self-contained package.
That's really cool.
JJ BEHRENS: So I assume these components can call each
other's methods?
SAM HOPKINS: Absolutely, especially when you're in an
all-Dart universe.
And we can talk about the inner operation later.
But if I query for one of these guys on my page and then
I have a reference to it, and I just call one of its
methods, it'll work as you would expect.
So as long as one component can get a reference to another
component, it just treats it as a Dart object.
JJ BEHRENS: Great.

SAM HOPKINS: Do you guys want to launch into--
let me turn off the screenshare here
so you can see us.
There we go.
Hi, again.
SETH LADD: Great.
So this might be a good transition.
We saw the demo to-do app, which is cool.
And then we saw the code behind it.
And that showed us the examples of encapsulation,
behavior, and all that good stuff.
But now I'm kind of curious.
Well, that was Dart code.
And Dart doesn't actually run in production browsers today.
In fact, Web Components is very much a set of standards
being born as we speak.
So how do you guys take all these new technologies and
techniques and actually make them available today?
What's your secret?

JOHN MESSERLY: Our secret for Dart, we have Dart to JS.
And that's our compiler text Dart code to JavaScript.
Everyone who's listening is probably familiar with that.
The other thing that we're building--
SAM HOPKINS: Screenshare.
JOHN MESSERLY: Yeah, how do I do that?
SAM HOPKINS: What do you want to demo?
JOHN MESSERLY: Do you want to show this one?
SAM HOPKINS: You just do screenshare, and then you do--
JOHN MESSERLY: Actually, the Dart editor first, if you can.
JACOB RICHMAN: You might just give them a-- screenshare the
whole screen.
JOHN MESSERLY: Yeah, can you screenshare the whole screen?
SAM HOPKINS: Yeah.
Screensharing the whole screen.
JJ BEHRENS: Don't leak anything.
JOHN MESSERLY: We'll leak our open source
Web Component secrets.
SAM HOPKINS: I'm going to have to biggify the font.
JOHN MESSERLY: Oh, you're right.
JJ BEHRENS: It's not nearly as exciting in the Chrome world
as it is in the Android world.
JOHN MESSERLY: What?
The leaking options?
JJ BEHRENS: Yeah, leaking.
SAM HOPKINS: Yeah, that's the thing about six-week releases.

How's the font size?
Can you guys read that?
SETH LADD: A little bit.
If you can make it bigger, great.
But I think that's as big as it gets.

JOHN MESSERLY: So what we're looking at here, this is a
version that's actually running.
And the way that we--
this is a similar version of the app that Sam showed you.
But what's interesting about this one is that we actually
have a compiler now that can look at--
so this is our--
to run in browsers that aren't going to--
like potentially versions of IE that aren't going to get
native Web Components for a while, they're very
excited about it.
They're on a different timeline than we're used to on
Chrome and Firefox and Safari.
So what we want to do is basically the same strategy
we're using for Dart.
We're going to make a really good compiler that's going to
take these input files with elements and templates and all
this great stuff and generate a combination of HTML pages
and Dart files to back that.
And then eventually then the Dart is compiled to
JavaScript.
So you end up with a set of files that can just run in
existing browsers.
So I'm going to show you how that works.
It's pretty simple.
We basically have a--
SAM HOPKINS: You want to biggify the--
JOHN MESSERLY: Oh, yeah, I should.
SAM HOPKINS: Just Alt-plus should--
or Command-Plus should do it, right?
JOHN MESSERLY: Good call.
SAM HOPKINS: More "embiggening."
JACOB RICHMAN: More bigger.
JOHN MESSERLY: Yeah, we basically have this project on
GitHub, which will be a package on Pub as soon as Pub
is ready for us to put it up there and we get a little bit
further along.
But basically, it's GitHub.
It's under Dartlang and then Dart Web Components.
That's the name.
And we have this little compiler for Dart Web
components, which you can just run.
So I'm going to run it on that file I just showed you, that
template tool main HTML.
So it's pretty fast, as you can see.
And it basically scanned all of our HTML files and it picks
them apart and creates HTML that will work in existing
browsers and Dart code, which then you can either run
directly in Dartium or you can run in Dart to JS.
I don't have it set up at the moment to run it through Dart
to JS, but it's normal Dart code.
So there's no magic to that second step.
SETH LADD: I'm sorry, John.
Just so I'm clear, what you just compiled was not into
JavaScript.
Is this just split in between?
JOHN MESSERLY: Yeah.
It's a two-step process.
Because we already have the Dart to JavaScript compiler,
which is working great.
So the first step is basically to do a few things.
So we want to implement this data binding.
We haven't talked as much about this.
But this is another important part of their overall Web
Component story, which is some folks on our Chrome Web
Standards team looked at this proliferation of JavaScript
frameworks.
And they're like, what are these common elements?
Because everyone has to keep reinventing this.
And they don't interoperate with each other.
And people can't easily share code that's written in these
different frameworks.
And one of the common features was components.
So we've talked a lot about that.
The other one was data binding, some
kind of easy way to--
I've just got a field here, and it's a string, and I want
to make it show up in my text.
Or I've got the onBlur event, and I just wanted to call my
Dart method.
So it's a set of things that we do.
So when we run our compiler, we have a few things.
We have to process these template element tags and
admit the right code to construct the Dart object at
run time and bind it to the element on the JavaScript DOM.
And then we also have to generate code to handle all
these little expressions and to do the right data binding.
So those are essentially the things that compiler does.
I can show you.
The output is kind of ugly right now.
We need to make it more pretty.
SETH LADD: Sure.
But the idea is then you run this Dart to JS so that it can
work in today's modern browsers.
JOHN MESSERLY: Exactly.
JJ BEHRENS: And I assume one of these days we might have
some integration with the Dart editors so that this stuff is
kind of automatic.
JOHN MESSERLY: Yes.
In fact--
SAM HOPKINS: It's coming.
JOHN MESSERLY: We're getting close to it.
Many of these things are different
things going in parallel.
So one of the things we have been looking-- oh, this is
going to look small again.
Well, the important part is we're basically looking at a
way that you can have this file down here, which is
build.dart, which is a special file you put in your--
the editor landed support for this pretty recently.
It's a special file you put in the root directory of your
project, and they know to call that when files change.
And that means that we can then handle the template tool
automatically.
So you edit one of these component files.
So I go up here to my footer, and I edit something.
I change some text here, and I save it.
And then immediately, they'll generate the new version.
So I go to my browser and refresh--
actually, in fact I may only need to go to
the browser and refresh.
And it will just know to compile it on the fly.
It's going to be a pretty sweet story.
SETH LADD: Yeah, the feedback we get is that the editing
experience in the Dart world is really fantastic.
Because you sit in the editor, and you run the application
which spits out Dartium, which is just Chromium
with the Dart VM.
And you get that great, make a little change, hit reload.
And it's cool to see you guys trying to emulate that and
make that work as well.
JJ BEHRENS: I'm addicted to that.
I have to have that.

SETH LADD: So those are great demos.
And it looks like we're on track to make the future
happen really, really soon.
And that is the part that really excites me.
Talk to me a little bit about who else is supporting this
whole idea of Web-- is this a Chrome-only thing?
Is this a Google thing?
Where is this coming from?
JOHN MESSERLY: Well, a lot of the work has been driven by
some of our open standards folks at Google.
But there's a lot of excitement from especially
Firefox and IE.
So the people who are behind our web standards, they meet
very frequently with those guys.
Mozilla has done a project called X-Tags, which if you
search for "Mozilla X-Tag" you can easily find it.
That's the part of it where you can put x dash John's
fancy button on your page and it will know to instantiate
the Dart or JavaScript object that's backing that.
SAM HOPKINS: We have that.
JOHN MESSERLY: Yeah, we have that, too.

SETH LADD: Cool to see how their browsers also try to
make this whole vision.
SAM HOPKINS: We should note that the--
I believe, X-Tags project was a JavaScript polyfill, right?
So you can also just last week or maybe two weeks ago, there
was a patch that went up on Mozilla.org to implement the
beginnings of custom element support right in the C++, in
the parser and the rendering engine and so forth.

Because it's a standard that's in progress, there's lots of
different proposed APIs, and they're implementing one
that's a little bit different from the way Chrome was
talking about implementing it.
But it's the same semantics.
And eventually, we will converge on the way this will
work for all browsers.
But they've got a patch.
It's going to happen in Firefox.
JJ BEHRENS: I love the term polyfill.
Not everyone understands, but to define polyfill, polyfill
is this bit of magic that makes tomorrow's
web available today.
SETH LADD: Yeah.
And I think what the team was showing off earlier are
compiler step.
Let's take advantage of that.
Let's make that work for us and translate a world in the
more pure Web Components world back down into the existing
tech we have today.
And so I'm interested.
I'm sold.
What's the status of the project?
And can I use this today?
And how can I follow along?

JOHN MESSERLY: Following along is easy.
I would say go to our GitHub project and just watch it.
And you can watch what's going on there.
SETH LADD: And is the sample we saw also in
GitHub, the to-do MVC?
JOHN MESSERLY: Yeah.
There are two versions right now.
We're still working on merging them.
We have our compiler and our version that just runs in
Dartium with no need for a compiler
or a server or anything.
It just runs in the client.
So those two versions, right now they have some very small
differences.
So we're working on merging it now.
As soon as we get that, I think we'll have a pretty good
place where people can start using it to build components
and see what it feels like.
So I would say it's coming pretty soon.
SETH LADD: Good to know we can follow it along in open source
and try it out and send feedback.
JOHN MESSERLY: Yeah.
And listen to the Dart mailing list as well for anyone who's
not subscribed to that.
Because we will definitely be sending some news there when
we're at the point where, hey, we need a lot more people to
try this, because it's gotten solid.
SAM HOPKINS: And I think the plan is that parts of this are
going to roll out of piecewise.
So I think you'll be able to play with the template
compiler before you'll be able to interact with components.
You'll need to start by just doing your interaction with
components via the template compiler.
And you won't be able to do it in Dart code that doesn't run
through that compiler.
And eventually, hopefully, you'll just be able to write
any old Dart code that can query for an element on a page
and do something with it.
Stuff is going to roll out piecewise as we develop the
necessary code and infrastructure.
SETH LADD: That totally works.
That allows us to be a little bit more responsive to
feedback, too.
SAM HOPKINS: Exactly.
SETH LADD: Great.
Well, hopefully, we've got some time for some questions.
I don't know if we'll hit every one, but there are some
very highly voted questions for you guys.
So JJ is going to fire them out.
JJ BEHRENS: Yeah, I don't think we're going to get to
every question, because there's four pages of them.
SETH LADD: That's good.
People are very interested.
I like it.
JJ BEHRENS: So Ravendra from Bangalore said, "What are the
list of Web Components targeted for the M1 release?
Will there be a data binding, for example, list views for
dynamic data?"
JOHN MESSERLY: That's a great question.
Where we are right now is we're laying this foundational
layer that makes it possible to build on this.
I think after that it makes a lot of sense to start building
out some base widgets and other things like that.
I think we'll have more to say about that soon.
But right now, we're still focusing on just enabling
components to work well in the browser.
SAM HOPKINS: I believe, though, that one of the
versions that you've already seen that we demoed uses a
very prototype dynamic list component.
So we won't necessarily endorse any particular list
component yet as this is the Web Components list component.
But you can see how you might go about writing one if you
look at that demo.
JOHN MESSERLY: Yeah, that's a great point.
There will definitely be data binding on lists.
So if you're mainly looking to data bind and say here's my
list of Dart model objects, I want to bind these two to
individual rows in a list, something along those lines,
you'll definitely be able to do that.
SETH LADD: I'll make a plug for Pub here as well.
I can see Pub, our package manager, also being a
mechanism to discover and distribute Web Components
themselves.
And so you might find lots of different list binding
components out there.
So that's pretty cool.
JJ BEHRENS: So next up, I think we've partially answered
this, but maybe you guys could refresh our memory Ernesto
from Granada, Spain, said, "Web Components is a
technology that's still finding its way to build
things and requires additional flags in the stable Chrome not
fully supported at all in other browsers.
How will we interact with that?" So we talked a little
bit about polyfills.
SETH LADD: I think we answered this one.
That's what makes me so excited is we can actually try
this stuff today, hands-on experience with this
technology in today's browsers.
Love it.
JJ BEHRENS: Polyfill magic.
JOHN MESSERLY: I will just throw out one other comment,
which is I think that one thing that has actually
surprised me a little bit working on this project is
that it seems like the web is starting to move a lot faster.
And I think there's a lot that Firefox and Safari are on very
fast updates.
And IE really wants to see a programming
model improve, too.
So things are coming faster than you might think if you're
used to the pace that the web used to be at.
JJ BEHRENS: Yeah.
I don't know about you guys, but as soon as I wake up in
the morning, I look to see what's been committed to
Chrome the night before.
SETH LADD: That's why we have Peter Beverloo.

JJ BEHRENS: So Pablo says, In the UI lid, you
have a widget hierarchy.
For example, panel class extends to component class and
the window class extends to panel class.
That way, you can reuse components and
decrease the code size.
Is it possible do the same with Web Components, ie., can
Web Components subclass themselves?"
SAM HOPKINS: Absolutely.
JJ BEHRENS: OK, good.
I was afraid you were going to say that they could only
extend existing things.
SAM HOPKINS: Oh, no, no.
JOHN MESSERLY: That would be no good.
SETH LADD: Not on my watch.
JJ BEHRENS: He says, "Can I use a Dart Web Component with
a JavaScript Web Component?"
SETH LADD: That is he.
I am him.
That was my question.
JJ BEHRENS: The answer to that is, absolutely.
SETH LADD: I kind of want to hear a little
bit more about this.
And we touched on it a little bit when we were talking about
attributes versus methods.
But can you guys give a couple words on what the interops
story between these components would be, JavaScript, Dart,
vice versa?
JACOB RICHMAN: Today if you used attributes, you're good.
In the future, you'll be able to invoke methods as well, but
that part of the story is a part that we aren't really
ready to really say is ready for public consumption.
But the nice thing about Web Components is you've got an
object that makes sense to talk about referencing from
both Dart and JavaScript in a way that you don't really
have, talking about just an arbitrary object in the Dart,
either for JavaScript or [INAUDIBLE].
Because in both Dart and JavaScript, you've got a
concept of what an element is.
SAM HOPKINS: And
discoverability is easy, right?
A way for the thing from either Dart or JavaScript.
But we so we believe that a large amount of the APIs on
these things can be implemented just using
attributes.
And any API with its attributes is really easy.
You just set the attribute from JavaScript or Dart.
And the other side, Dart or JavaScript, can pick up that
attribute change and respond accordingly.
SETH LADD: I'd like to really make a personal plug towards
that type of a design, let alone interop.
I think at least when we're talking about components in,
as Sam, you like to call it, the declarative renaissance of
web development, which, I love that term.
To me, the key one there is declarative, right?
It's declaring the elements.
They might have attributes.
They may have their own subchildren.
And at least I'd like to see us make an effort on designing
APIs that way and see what happens.
JJ BEHRENS: So the next one is from an Antaro.
"Can you explain to C Sharp and Java developers before you
go into detail as to what Web Components are?" Now, I know
that we've already covered what Web Components are, but
can we take another Java C Sharp spin on this?
No, I'm just joking.
Let's move on.
Vadam from Russia.
"Having watched some presentations about Angular
JS, it looks that Angular and Web Components have very
similar central ideas.
What is the relationship between these two projects,
and what is the difference between them?" I think it's
really about which cafeterias we prefer.

SETH LADD: You guys have any thoughts on that?
I know by Angular JS is mostly a Google project.

SAM HOPKINS: The key is that these are going to be part of
the web platform.
Angular JS is a great framework, but it's one among
many frameworks.
And it has all the same problems in terms of
interoperating with other frameworks, being written in
JavaScript and not natively in the browser, and so forth.
And in a future coming to you, Web Components will be part of
the browser and part of the web ecosystem.

JJ BEHRENS: I would say that this Web Components idea is a
lot more ambitious then Angular JS, whereas Angular JS
works really solidly for a lot of apps already today in
production.
SETH LADD: So let's take three more.
I like these two questions.
JJ BEHRENS: "Can you give one or a few examples of how to
use--"
SETH LADD: We definitely did that.
Let's skip to this one.
[?
JJ BEHRENS: Gundmund said, "What are the performance
implications of using Web Components?"
That's a good one.
SETH LADD: Well, there's a lot of different ways to look at
performance--
raw computation, initial load times, loads from cash.
JJ BEHRENS: It's all about latency.
SETH LADD: The latency.
But what I heard today was we have a compilation step.
And so we can do really smart things to help our
performance--
early binding, late binding, minification, taking advantage
of particular platform capabilities that might exist
for your browser.
So I don't know what you guys think, but I'm hoping that in
terms of performance, if you were to write this with your
declarative capabilities today, and you were to write
this with Web Components, the performance should be
basically the same, right?
JOHN MESSERLY: That's exactly right.
SAM HOPKINS: One of the design goals for the way that we
implement all this functionality--
and we're still in design and prototyping phase for the
final implementation of all this-- is that they cannot
have any performance cost above standard view model
frameworks or even just standard
hand-coded view model stuff.

JJ BEHRENS: The next question is, "What would be the role of
Web Components in developing games with Dart?" Let me try
to take a stab at that one.
SETH LADD: Go for it.
JJ BEHRENS: If you've coded games in JavaScript, obviously
you have the option of whether you want to stick with just
functions and closures or you want to put
together an OOP system.
And I think that the same thing kind of goes for Dart.
And the same thing also goes for Web Components, in that
Web Components allow you to structure your app in a way
that might be helpful, especially for a larger app.
What do you guys think?
JACOB RICHMAN: I'd say for a game, you're going to use Web
Components for the UI of your game.
But for the actual main rendered game area, Web
Components aren't going to really impact
your life that much.
You're going to be using Web TL or Canvas directly.
JJ BEHRENS: So I'm going to create a new term here--
PODO--
Plain Old Dart Objects-- all the way down.

Gundmund also asks, "How is model-driven views related to
Web Components?
How is Outlook browser support for MDVs?"
SETH LADD: This is a good one to end on, yeah.
MDV and Web Components.
Is that the same thing?
Are they two buzzwords of the same flavor?
What's the difference?
JACOB RICHMAN: They are two pieces that we think together
really form a compelling story for how you create your MVC
apps in Dart.
The two pieces are designed to be pretty separable.
So a user who really likes Web Components but doesn't really
like MDV can still go ahead and live in that world.
SAM HOPKINS: Just so we're clear, MDV is another name for
the data binding stuff that we already showed off.
SETH LADD: MDV is model-drive use.
JACOB RICHMAN: So MDV's how you really closely define how
you're binding your plain old Dart data objects of your
model to your UI of your view.
SETH LADD: And I think one of the design considerations
around MDV is that it should feel very webby.
So you might have data in the forms of ULs
and LIs on your page.
And you might say, that is my model, which I really love.
Because then as you get more declarative with these sorts
of things, you can play off of what makes the web so great
today, which is crawlability, indexability.
And I believe one of MDVs design constraints or
philosophies is maintain this crawlability,
indexability behavior.
JACOB RICHMAN: You'll define your templates for your views
with standard HTML.
But your model will be Dart code.
Your model will be Dart lists and maps.
SETH LADD: Can you have models that are also in the page like
JSON objects or actual HTML objects?
Maybe this is an old version of the spec.
JACOB RICHMAN: No, your models would be [INAUDIBLE]
classes.
You're not going to force yourself to represent your
model as XML instead of--
SETH LADD: Oh, hopefully not.
JJ BEHRENS: So guys, I want to thank you guys for taking the
time to meet with us.
This was a lot of fun.
I know that a lot of us are looking forward to this Web
Components stuff.
And I think this is going to lead to a nicer the feature of
web development.
SETH LADD: And thank you very much to Sam, who I know made a
special trip back to Seattle Google office.
So I appreciate that, for showing us what you've been up
to all summer.
And so on behalf of the whole Dart community, we thank
everyone there for working out in the open, especially on
this project.
I should probably remind everyone watching that we've
got an open mailing list and open bug
tracker, open issue tracker.
This an open source project.
We definitely love the feedback.
We've made numerous changes based on feedback on Dart.
And we look forward to people trying out Dart Web
Components.
And I think it's going to be big.
JJ BEHRENS: Absolutely.
OK, well until next time, take care of yourselves.
SETH LADD: Thanks, everybody.
See you next time.
Bye.