DIMITRI GLAZKOV:
Can you hear me now?
Wow.
The power of technology.
Is the Episode
One the worst one?
Is that what it is?
Or I can't remember?
So everybody had lunch.
A little bit tired right
so we need to get up.
No, I'm just kidding.
Somebody suggested we do
calisthenics and stretch
and all this stuff, but I'll try
to be energetic for you guys.
You don't have to.
So this talk is a
little bit different
from every typical
web components talk,
and believe me there's a
few of them out there now.
Just do a search.
Web components talk, and you
will see a bunch of them.
Because I'm going to
ask deep questions like,
why are we here?
Why you guys here?
I really have no clue.
But why are we doing
what we're doing, right?
Why do we do things that we do?
Well, I'm doing because I
want to make a bunch of money
and retire in Swiss Alps.
Is that why we're doing this?
Sounds good?
Reasonable?
Maybe write a little
science fiction.
Space Opera type stuff.
No, the reason why
we do these things
is because we want
to solve problems.
We want to help users.
We want to make it easier.
Make life better.
Change the world,
some of us say.
Some of us say, I can't
do the whole world,
but I'll change a
little bit of it.
And so about five years
ago now, I basically
was a young web developer who
just joined the Chrome team
and I was really getting into
this whole web development
and browser development
thing I was like,
oh my god, I have superpowers.
I can change the browser.
It was awesome.
And so I started
looking around and I
realized something important.
That great platforms
have one framework.
Terrible platforms have none.
And web platform has a bunch.
And the reason why
we have so many
is because all these
frameworks are really
made by pissed off people.
People don't make frameworks
because they are happy,
like oh my god, I
have extra time.
I'm going to go and build
another web framework.
People build frameworks
because they're sad and upset
and this thing does not
work, and they're like,
OK I'm going to not do
this again over and over.
I'm going to codify this
into something and hey,
maybe some other person
will benefit from it.
Changing the world
type thing, right?
Are you guys with me?
So really, with this
goal, I said, OK,
so if this frameworks
are all cries for help,
what kind of help do they need?
And this really was the venture
that began back then and ended
up being the thing
called Web Components.
And Web Components really is
about solving several problems,
and I'm going to try to
go through them with you
and this is just tip of the
iceberg, but I have 30 minutes.
I can probably talk about
this for days, and I won't.
I have 30 minutes.
And so one of the first
problems that I've encountered,
and something that
people do all the time,
is that composing
things is hard.
Composition is like
the foundational thing
of software engineering, right?
You have a bunch of people
working on software.
Your team consists of more
than one person sometimes,
and you're all working
on achieving success
and then things have to
come together and ship.
And then it's like, success
turns into not success,
because nothing fits.
And so composing things
is generally really hard
and then web platform
is special in the web.
We've always done this
really weird thing
where we-- it's a very
common pattern I'm
going to call it
render and decorate
but you probably
have your own name.
And that is the idea that
instead of keeping everything
in one large DOM tree,
you separate things out
and you bring them
into smaller chunks.
And you make those
chunks separate
and you keep them aside.
And so, for example, imagine
there's a very large DOM
tree there.
I'm not going to bore
you with details.
Just go into Gmail and open
Inspector and look at it
and you'll see it right there.
And so render and
decorate goes like this.
Instead of my actual
widget on the page,
I'm going to put a little
 there as a marker.
And then later when it's time
for me to inflate this marker
I'm going to do a
magic incantation.
We call it applying senses.
And then we're going
to query Selector.
By the way, if you guys
don't know JavaScript
and can't follow me
along, I apologize,
you probably are in
the wrong conference.
But, you know, nevertheless
that's all I have.
And then you just,
you do something
like you create a template.
You create a widget
template there.
You put stuff in it,
and you blow it up
and everything looks
wonderful, right?
Except, what is the problem?
When you go back
into the Inspector,
and you look at the--
Turns out, well,
when you look into
the tree, it's
all back together into
one big tree, right?
So now you can no longer
think of these widgets
as separate things,
you're thinking of them
as one large, big DOM
tree in the document.
And so to solve this
problem, we came up
with this thing
called Shadow DOM.
And Shadow DOM allows us to
add one line to this code.
Just one line right here.
But what this line does--
you guys can see it?
You guys with me?
Is it now keeps
all of this tree,
right here in this thing as
a separate little subtree.
So now I can still
move it around,
I can still reason
about it by itself,
it's no longer a part
of a larger whole,
but at the same time it renders
as the same widget there,
right?
You guys with me?
So what we did is-- it actually
solves the DOM composition.
So developers out in the field
or working as a team no longer
need to worry about a large
DOM tree as the final result.
They can still think
of all these pieces
as separate little chunks
of code and chunks of trees
and then compose
them together as one
big, large, beautiful
document or an app
or whatever you guys
decide to build next.
Are you guys with me?
Yes?
Right.
Well, right after this we
ran into this next problem
that is a little bit
more interesting.
And actually we've gotten so
Stockholm Syndromed into it.
We'd go like, no it's
OK, it's not a big deal
let's-- we're all right.
And that problem is called CSS.
All right.
There was this Comment Lander
thing on Google+ or Twitter
that you guys have
seen probably seen.
We can land the
thing on the comment
but can't position
the box on CSS.
And really the biggest,
beautiful problem with CSS
is that CSS is a wonderful
bit of machinery that
allows us to separate concerns
of style and presentation
from the concerns of structure.
But it's also an all
or nothing thing.
So for a larger web app,
this becomes a really weird,
spooky action at
a distance thing,
where you have to
basically say, hey,
I actually have 1,000 widgets
in my dock or in my app,
but all of them ultimately
feed from one stylesheet
and it's somewhere
there, and actually I'm
going to pretend they're
multiple stylesheets,
but no, they're still
one style sheet.
So once you change a thing it
becomes this weird thing like,
am I going to break anything?
I don't know.
If I did, what am
I going to do now?
And so, here's a simple
illustration of the problem.
I'm just going to take
this thing and say,
hey, I'm just going to add
this little  down below
over there, and I
want it to be red.
And it's very simple.
You have top here, I have 
here, and so all I need to do
is put this simple Selector
there.  top  .
D'oh!
Because of the
render and decorate
that comes after the fact,
that is not visible on my tree
right there, the widget
title is also red.
And that's where the wonderful
bang important comes in, right?
You go like, OK, specificity.
And we need to remember
the numbers zero, one, ten.
Anybody can rattle off the bat
what the specificity rules are?
That's OK.
It's all right.
Because we can actually
solve this for you.
And we did this with
the Web Components
with the same line of code.
It's the same line of
code that we had before.
And the beautiful part here
is that CSS is scoped inside
of the shadow tree.
So whatever you write
inside of the tree,
CSS is encapsulated
inside of it.
So nothing leaks in,
nothing leaks out.
You don't have to start
reasoning about global things
and how the global stylesheet
applies to this widget
because all those things
are completely separated.
As you can see, the
widget is no longer red.
The widget title.
Awesome?
Yes.
Yes.
And trust me, when you start
building with Shadow DOM,
one of the amazing thing happens
is your Selectors get simple.
You no longer write
this really weird train,
wacky train of wagons.
That's like, + 
(dot) pound foo pound foo
And it's like, no, everything
is just pound foo or pound blah
and  dot whatever.
And it's very simple
because you no longer
think in the global document,
the global app sense.
You no longer have to worry,
oh will the next state
change affect what I've just
done with the stylesheet?
You basically think
about it as hey,
I'm working inside of my widget.
And that's all I
need to worry about.
And I'm OK, and nobody's going
to mess my stuff up, right?
So we solved-- don't do that.
We solved two problems.
There are still a bunch
of them remaining.
Let's go ahead and start
solving all of them.
And the common thing is the
House of Divs that we have.
Or the Jacob's Ladder or
whatever we call this thing.
It's like this amazing
thing where we just
soup up our document with 
    ,
and sometimes I wish I
could use a button here.
But because IE or
something, I need
to use a  for
my button as well
so everything is a  Yay.
Well, no, it's OK, right.
Because like even in
the solution like I
said like I made it better.
This is much better.
I still go, look, this
is  class my widget.
Why can't I just
call it my widget?
Why can't I just say,
look, this is my widget.
This is not 
class my widget.
This is my widget.
And turns out, there's
a thing we invented
called Custom Elements
that allows us to do this.
And Custom Elements
is really neat.
It basically says, HTML,
it's been a pleasure,
but it's time for me to
start saying things the way
I mean them.
Right?
Saying what you mean.
Alex Russell invented this.
Alex Russell everybody.
Say what you mean.
And the basic idea is this.
You just declare a new tag.
You just register a new
tag with the HTML parser.
You proclaim.
You suddenly have this power and
say, I'm going to extend HTML.
I don't have to be
the Inspector editor.
I don't have to be a
browser implementer.
I just call this thing called
Document that Register Element.
Give it my tag name and
provide a prototype.
And suddenly a bunch
of code falls away.
No longer I have to do
this Apply Instances thing.
I don't need to do this anymore.
Because as the parser
encounters my widget
it will invoke a thing
called the Creative Callback,
which is like effectively a
life cycle callback for the HTML
element and it will
run this code for me.
So effectively what I'm
saying, hey, HTML parser,
do something useful for a
change instead of just spitting
out stuff and objects.
Create my objects for me.
Instantiate them,
so I don't have
to come behind and decorate
them with something.
Create them as they are.
As they were meant to be.
And so this allows me
to effectively remove
the extra calls at the end here
that were present that says,
Apply Instances thing.
I don't need to do this anymore.
It's all now a part of the
Creative Callback of the HTML
element.
So now I've invented my own tag.
I gave it behavior.
It's not just about
new tags, right?
It's about making parser do the
work of instantiating things.
So now is to help
our server that
runs as fast as it could
possibly go not only just
spits objects of
predefined shape,
it can spit out your
objects as well.
And you can build
entire object trees
and you will see in a few
minutes about how this happens
and what kind of magic it
can achieve with this stuff.
So, yes, awesome, right?
Custom tags.
And finally, let's like just
turn this just one more time
and say, well, this
was really fun,
but, Dimitri, this still
looks a little wonky.
You're still doing things that
look somewhat unpalatable.
Like you're doing things
like creating document object
tree using JavaScript and
mashing strings together.
That seems bad.
Can we fix that?
And the answer is, I guess
you figured that one out.
The answer is yes, we can.
And the way we do that
is with a special thing
called a template.
Template is a magical,
magical HTML tag.
Everybody, after you
leave here, if you've not
played with a template,
go play with it.
It's awesome.
Because what it does is
it gives you nothing.
Nothing in the bad sense,
but in the good sense.
Things inside of the
template do nothing.
They are inert.
There are the Han Solo thing and
frozen in time or whatever that
thing-- I can't
remember the compound.
But it obviously was some
sort of amazing stuff.
And so once you put a thing in
here inside of this template
right there, styles
will not apply,
images won't load, the views
won't play, things are inert.
They're basically, like,
it's parsed, it's there.
It's ready to be stamped out.
But it doesn't do anything.
And that allows us to instead
of doing this crap right here.
Look at that.
That's a lot of code.
Break it down to this.
Where we basically say,
hey, widget template,
all we're doing is just
creating a template.
Getting it out of the tree
and then stamping it out
right there.
Does that make sense?
Templates are wonderful.
Not to say that everything
else is wonderful as well,
but these are pretty
awesome things.
Still, this looks OK, right?
Now we have all of our
HTML in HTML space.
All of our JavaScript
in JavaScript space,
but, you say,
Dimitri, yes-- I am
channeling Emeril Lagasse here.
Dimitri, why are templates
in my document now?
Can you help me get rid of them?
Because if this is a
large app won't there
be like a bunch of templates
hanging around in that thing?
Wouldn't that be kind of bad
and then this JavaScript seems
to be like just somewhat
sitting by itself.
That seems bad, right?
Well, we can fix that.
And that's where we came up with
this thing called HTML imports.
HTML imports.
HTML imports are
amazing because they
allow you to create HTML
files-- that you can do what?
Import.
That is pretty cool.
So as you can see here, this
is our template right there,
and there is our JavaScript
code right there.
And then, we import it
using this very simple, very
familiar-looking line that's
called link rel import.
Instead of stylesheet
you're importing HTML5.
You're importing,
instead of styles,
you're importing Markup.
And so what happens is
now your apps suddenly
does not have to look
like a bunch of stuff.
It can be now separated.
And you can build
Dependency Trees out of it.
And by the way, link rel
imports, HTML imports,
provide dependency
management that's very nice.
So all the duping happens,
so if you include it
twice in different places you
will only get one instance.
So it does really well.
And it also allows
you to start reasoning
in about larger apps in a much,
much simpler frame of mind.
So there's our import, and
there's our final result.
HTML imports, everybody.
The neat thing is these
building blocks are just
the beginning of what can
happen and what will happen.
By giving developers
the power to harness
HTML5 parser so they can
create their own object trees,
giving them ability,
giving them-- them?
You.
Giving you ability
to scope your styles
and to compose DOM dynamically
on the fly instead of mashing
it all together, and by enabling
a reasonable Markup reuse
scenarios with HTML
imports, you open
all kinds of possibilities.
First of all, interoperability.
This one is really crucial.
Because every framework
invents this system
in slightly different and
completely incompatible
way with another framework.
They all have to deal
with reuse of elements.
So widgets from one framework
are not compatible with widgets
from other framework
because they were invented,
the composition
model, was invented
in slightly different way.
When Dom is your
composition model,
when elements, when Shadow
Dom is the web standard,
and custom elements is the
standard way to compose things,
everybody can now compose in
using the same common lingua
Franca, which is Web Components.
So that allows or
enables the path
to where every framework can
reuse each other's widgets,
and things and you don't
have to think about which
one is compatible equation
which one is not it's
a long road because
there's lots of really
strong opinions about how
composition should happen.
A lot of this is again,
laden, with Stockholm syndrome
and understanding of the world.
But the path is open.
It's available now.
The other thing that
is pretty amazing
is the fact that now the browser
understands your composition
model.
So the rendering
engine can make smarter
decisions about how to
do things faster for you.
For example, the Shadow DOM
can be a performance primitive.
Because instead of reasoning
about invalidating styles
across the entire document
all the time when your app has
multiple pages, like a single
page app type of thing,
you're all confined
to tiny little trees.
Stock [INAUDIBLE] is much faster
and much more predictable.
So hitting those 60
frames per second
becomes a more real
and achievable goal.
And things like HTML
imports are also
really cool because parsing,
which HTML turns out,
many browsers do on
a separate thread.
So you could potentially start
loading multiple imports,
and they would be doing all the
work of parsing and tokenizing
and loading those
imports in parallel.
And so you could gain
performance benefits just
from that.
And the third and pretty
most important thing
is that all these primitives
are designed in such a way
that they provide the
developers, especially
developers of frameworks,
a better framework.
A better way of thinking
about coordinating actions.
Instead of arbitrary
points at which
your components or your
deals become components,
there's now pretty fine
checkpoints like micro tasks.
And there is callback cues and
execution of those callback
cues that is
designed in the spec.
So you can now reason
about how much work
do I need to be doing
now, how much more work do
I need to be doing later,
in scalable fashion.
And of course it all
results, at least in my mind,
in really green
circles of awesome.
I'm not sure why
the circle is green,
but it's definitely awesome.
This is about it.
If you guys want to
ask me a few questions,
we have six minutes left.
Yeah?
AUDIENCE: What's the
status of browser support?
DIMITRI GLAZKOV: What's the
status of browser support?
They are available in
Chrome, and they're
available in the
Opera, obviously.
No laughing.
And then Mozilla is
implementing components as well.
It's right now in
experimental track,
but I've been talking
to Microsoft folks.
They're excited
about it as well.
So hopefully, fingers
crossed, soon.
There is a thing called
webcomponents.js,
which is a set of
poly fills that
allow you to take advantage
of most of this functionality
across browsers.
What is this IE 10+?
So it's pretty awesome.
But it's definitely a
native implementation
and it has certain
performance benefits.
Yes?
I'm sorry.
You were first.
AUDIENCE: Do HTML
imports [INAUDIBLE]
support name spacing at all?
So when you use name
space, how does it
work when it gets pulled in?
DIMITRI GLAZKOV: Right.
So HTML imports
and name spacing.
I have to repeat your
question obviously for people
out in the internet.
I hope you're watching.
I don't even know if this is the
camera, but I'm assuming it is.
There is no name spacing
for external tags,
because there's just one HTML5
parser so custom elements will
be parsed according
to one registry.
But the notion of
registry exists
and we can improve
this in the future
to enable multiple registries.
So an import can
declare and say,
I have my own set of elements
that I want to do on my own
and please don't touch mine.
I speak my own language.
As far as how it is imported
into a main document
it is not important
in the main document.
So it just as a
separate document.
An import is a
separate document,
and the only way
you import data is
if you run script
inside of it and you
decide to do something with it.
So you have to take an
extra step to do that.
Is-- am I done?
I'm done.
[APPLAUSE]
