Tip:
Highlight text to annotate it
X
>>Alex Komoroske: Let's get started. >>Dimitri Glazkov: Let's get started. So what
the heck of Web components? >>Alex Komoroske: So When you guys saw that
word component, you probably thought what is that? Well, I submit that each and every
one of you know what a component is because you use them today. You use them in lots of
different cases. So the first case is in embedded widgets. So here if you have a Google+ button
inside your site or a like button or something like that --
>> Dimitri Glazkov: Or a Twitter button. >>Alex Komoroske: This is a third-party bit
of code that's running within your site. It's something where you have trust issues, right?
They don't want to allow you to mess with all of their stuff or (indiscernible) privileged
APIs, and they also don't want you to style their stuff. So they talk a lot about discipline.
Like, "Thou shalt not use anything under -- sell anything under my little ID" and stuff like
that. >>Dimitri Glazkov: Right, and of course we
as user of those widgets go, "Eh, it's more like an etiquette." Try not to do that stuff
and we'll mess with that the way we want to to make it look nice.
>>Alex Komoroske: And so in fact, what everybody does, they give up on these iframes, but that's
not really ideal. So another use case is when you are writing
your own app, and say you want a tabstrip, well, you shouldn't have to create a tabstrip
because there are thousands of them that other people have created; you just want to use
those. So you just want to grab in a widget or a
component that someone else has written, and put it inside of your app.
>>Dimitri Glazkov: And there are entire libraries written nowadays, and some of them are quite
complete, libraries, and widgets and all of the different UI elements that you might want
to put together. And of course, unfortunately, the problem
there is that all of these libraries espouse their own strategy on how to execute the UI
widget composition and how those things come together. And so like one of the top stock
overflow questions would be how do I use the widget
from Framework Foo in Framework R, right? >>Alex Komoroske: Unfortunately, they follow
different conventions, so often the answer is you use a lot of duct tape, a lot of script,
jam them together as best you can. >>Dimitri Glazkov: Don't touch those parts.
>>Alex Komoroske: And don't do this, whatever you do. So the final one is custom-built widgets.
Are you hungry? So bear with me for a second. You are all familiar with spaghetti code,
right? Where you have all of these crazy stuff to do, really hacky. When you are writing
your own apps, you want to have this better fit of encapsulation, right? Because that's
how you build more complex things. But it's hard to do in the above platform, so the best
that you can kind of get is lasagne. You've got layers, but they're still kind of messy,
right? So even when you are building any kind of app, you are building these custom elements
for yourself. >>Dimitri Glazkov: The components is, you
know, one use of that. >>Alex Komoroske: So let's go dive into our
example we will be talking through today. We're going to build a poll app and show you
how we built this today. So here it is. It's a pretty app.
It's got a cool HTML file logo, it's got a title, a subtitle, different options. If you
aren't familiar with them, you can hover over them to see the information about them. You
can select them. I selected things. You can also see the results. See what other people
have voted for. But let's dive into how this stuff actually
works. So I'm going to open up Web inspector here,
I have got this way zoomed in, which is why it looks so funky.
>>Dimitri Glazkov: And if you look at this today, and this is a written -- you know,
this is a pretty cutting edge technology even by today's standard. Shout out for David who
wrote this code. It's using what you would call the modern
principles of Web design, and that is, you know, you do see your components right away.
You see the poll is one component, which is a backbone view; and then you see the choices
view, results view, and all of those different things that are put together into a widget
hierarchy of some sort, right? Unfortunately, some of the things immediately
start jumping out at you and going what's going on here?
See those strings there? Your HTML became just a string, right? It's not a markup anymore.
It's just the cottage cheese in your Lasagne, right?
And so at this point you are starting to go and say, "Well, I'm not really working in
HTML anymore; I'm working in this parallel world that the framework has designed for
me. And then what happens is this framework will do the right thing and project the actual
HTML or DOM tree into the browser for user to see. And, of course, when the user clicks
on something, the backward thing happens, you know. The framework traverses the events
back to your tree to your object hierarchy and tells you what happened. It's not just
the deal that was clicked; it's your poll that was selected.
Ah-ha, I understand this now. So if you look at this markup right now, you actually see
this very clearly. It's that markup is not necessarily representative of what the poll
is; it's actually a lot of things in addition to just what should be a very simple widget
layout, right? You have poll and you have choices and that's it. What else should be
going on here? But there is actually a lot of markup going on. That's because the markup
is essentially a projection. And even worse, today, if you load this page, it's just a
DIV in markup. What happens is the framework then blows up
this DIV using the JavaScript and creates the actual framework out of it.
So -- you think this is bad? >>Alex Komoroske: Right. So I actually have
something that haunts my nightmares, and it will haunt yours, too, after I show you.
So if you open -- if you go to, say, just Gmail which we all use, know and love, if
you switch and look at the Web inspector in here, you inspect some random elements -- what
is going on? >>Dimitri Glazkov: Oh, my God! What is this?
This should be a very simple widget tree, right? There's like a list of things and then
there's -- oh, my God look at this! Stairway to hell. [Laughter]
>>Dimitri Glazkov: Right? What's going on there?
>>Alex Komoroske: This doesn't make any sense. And so -- this is in this bizarro. You know,
I bet a lot of you watching this were saying, "Oh, well that's just how you do it, right?"
Like, why are you talking about why this is insane? This is just how you make it work.
You know what, Dimitri? I submit that everyone in this room who said that is insane. Right?
[Laughter]. >>Alex Komoroske: This is insane, this is
crazy. >>Dimitri Glazkov: We're insane, yay! All
right. But the thing is that -- it is true, we are
doing something to work around the issues in the browser. And we're writing a lot of
code. We're writing frameworks to help us do this -- these bits of code. Then with more
code that we write, we have more opportunities for -- for losing test coverage, for example,
and not knowing exactly what's happening. And clearly more code you ship over the wire,
the slower your application will go, right? And the development time suffers, of course.
Unless you stay in the confines of that specific framework, right?
>>Alex Komoroske: So that's sort of on a low level why this is bad. On a high level, this
is bad, too. Right? If you looked at this DOM, this isn't very
symmetric at all. I had to look through it. I didn't really understand what those things
were doing. The Gmail example, of course, is way on one end of the spectrum. But actually
if we look at our index, Google, we see the Web is getting less and less semantic as we
go. There's more DIVs and spans. It's harder to understand what's going on.
>>Dimitri Glazkov: And more empty DIVs, like I mentioned before, right? You try to index
a page, you go there, you say, oh, there's nothing there, no, no, that's actually an
NPR app but loads all kinds of images. You have to run script to understand that it does
that, right? >>Alex Komoroske: So running script means
that you have to -- to make any kind of complicated app, you have to run script. You can't be
a web author; you have to be a Web developer to make something work today. Okay. So I have
one bit of good news. You guys are all insane, but it's not your
fault. It's the fault of the platform right now and that's why you have to do these things.
>>Dimitri Glazkov: That's right. >>Alex Komoroske: So if you look at this,
the rare thing of it, is the Web platform has all of these amazing technologies that
do all kinds of really cool stuff. But there are a few little potholes. A few little tiny
things that don't work correctly or that are difficult. And you run into them. You're on
this information super highway, everything is working great, you run into a pothole,
and you say, "Ooop, I can't handle this." But that's okay.
I have script, I have an escape hatch. I will do this in JavaScript. It will be okay. So
you go a little tiny bit off road. That's fine, right?
Now you run into another pothole, a deeper pothole offroad. This means you're offroad,
right? And it's a pothole that wouldn't have been
there had you been on the highway, had you been able to use these normal technologies,
but you're offroad. That's okay. You write a little bit more script, you go a little
bit more offroad. Things are wrong, right? Unfortunately, this
leads into a pit of despair, right? Like the more offroad you go, after a certain point
you are drawing your own cursor, you've completely escaped the browser here.
[Laughter]. >>Alex Komoroske: You are sort of building
inside this escape hatch. JavaScript is an escape hatch. If the (indiscernible) doesn't
do what you need, you are now building everything inside of the escape hatch. That's crazy.
Even if you don't think that you are doing it, you think you are doing a very good job
of being semantic and all of that stuff, well, the framework they are using is doing it for
you. They are going completely offroad to do this kind of stuff.
>>Dimitri Glazkov: Right. And a lot of this framework becomes so robust. And in order
to become robust, in order to offer the experience to you that makes sense, they build entire
rendering engines into the browser, so you have this turducken of the thing. The rendering
engine is just a rendering surface, and then there's another one that's being loaded to
the js file that actually does the stuff for you. And so it's pretty sad.
>>Alex Komoroske: So, yeah, we've been talking all doom and gloom so far. We're going to
turn the page here, and the good news is that although we look like normal people, Dimitri
and I actually come to you from the future. [Laughter]
>>Dimitri Glazkov: Yes. We did come from the future. You must know there are multiple versions
of the future, and there is one, for example, where the alien invasion begins in 15 minutes
and the Web platform essentially becomes irrelevant. >>Alex Komoroske: But there also good time
lines. The time line we're from is the one where there's free beer and there's Web components,
so it's not all bad. So what we want to do is we want to talk to
you about how Web components solves this problem. >>Dimitri Glazkov: So the Web components is
this new set of technologies that we looked at -- we created by looking at those potholes
and decided to fill them naturally as things that fit inside of the Web platform as a whole.
Rather than building a whole new crazy thing on the side, which we always have done before,
we decided we're going to fill those holes naturally into something that feels like just
part of the Web platform. Just part of the standard things that you normally do in the
browser. Not a script and not some crazy invention that is completely brand new.
And so what we did is we kind of found out that there's three pieces that are missing
and these pieces are Shadow DOM, the custom elements, and the templates.
>>Alex Komoroske: So let me walk you through what each of these ones means in practice.
So again, all of these three things are what come underneath the umbrella of Web components.
So the first is Shadow DOM. Shadow DOM is what allows you to encapsulate stuff in the
DOM to hide away all of that crush that you need to make it look correct.
Custom elements is what allows you to define your own tabs. When the HTML parser runs into
your widget, it can instantiate it immediately for you.
Finally, templates allows you to define HTML DOM snippets very easily. So today you are
doing this in long bits of strings and script, or you are doing script tags with some -- with
some templates there. This basically just allows you to define it directly in your HTML,
have it sort of frozen off to the side, so you can swap it in when you need it.
>>Dimitri Glazkov: It's kind of neat to decide that developers are -- really like this master
framework, right. There's problems with the Web platform, but no matter what, developers
force will work around them or flow around those problems.
>>Alex Komoroske: They will find a way. >>Dimitri Glazkov: Exactly.
>>Alex Komoroske: So this is sort of like the low level what the technologies do, but
what does this actually mean in practice? >>Dimitri Glazkov: Well, in practice, what
you are really are looking for is something that allows you to tell -- allows you to tell
the browser exactly what you mean. This, for example, would be the markup that
you are actually are trying to communicate to the browser. I have a poll, I have choices,
and there's things that -- that are essentially data for my poll, right? Why should there
be anything else? Right, right, right?!! >>> Right!
>>Dimitri Glazkov: All right! So the three pieces fit very neatly into this idea. First
Shadow DOM allows you to take the scaffolding all of the weird DIVs that are really irrelevant
to the semantic of the markup, and hide them into the Shadow DOM -- which we will talk
more about later. Then the custom elements allow you to define new tags, right? New tags,
awesome? X-poll, right? And specify behavior and assign things on top of them.
Then, of course, the templates allow you to stop treating markup as string, which is always
nice. >>Alex Komoroske: So that's how they help
tactically, but they also, of course, are really important on the high level. So if
you have this world, this is all you need to pass down to the browser to have that rich
poll experience exist, that means that you don't need this bizarro script. DOM can be
your only hierarchy. You don't need to have this parallel bizarro hierarchy on the side.
>>Dimitri Glazkov: You no longer need to build your widget hierarchy as just a, you know,
an object tree somewhere off to the side. The one that projects the DOM is a kabuki
theater of some sort. >>Alex Komoroske: So DOM can become this lingua
franca of the Web. It also means that you would have real encapsulation, so you wouldn't
have to worry about people coming in and messing with your innards and messing up how your
component works, because they can't because it would be a barrier.
So it's not just etiquette or discipline. It's an actual encapsulation barrier. Also
if DOM is the composition mechanism, it already composes really nicely. You can put a span,
DIVs, all kinds of stuff, right? If you have that as the framework that you
use for composability, that means that you have compatible composability. So if you have
a widget from Framework A and Framework B, they can live together harmoniously without
having to figure out which widgets they have -- it's just DOM.
>>Dimitri Glazkov: Right. And where that one widget begins and where one widget ends. That's
another important thing. Let's be clear. Web components is not a set of those widgets.
It's just a platform on which the future frameworks, you know, the future where we're from? Can
build those new frameworks. >>Alex Komoroske: So it's a foundation for
this stuff. Okay. So this -- actually, Web components
as you may have guessed, makes all of this stuff real. So we're going to show you what
it looks like in practice. So let me switch. This is the demo that we showed; it's built
using the best practices of today. And this is what the -- what the one with
Web components looks like. Right? Looks exactly the same.
>>Dimitri Glazkov: Yeah. Right. So in the future, all applications are going to look
exactly the same, right? This is the lesson that we are learning? Well, actually, no.
What's interesting here, this is actually a functional application, but instead of all
of these weird spans and DIVs inside of it, it has a very clear, very concise markup.
This markup is exactly the same as the actual DOM structure off this document, right?
So whatever you ship over the wire is exactly the same thing that is represented as DOM.
You don't have to create this thing that the frameworks -- the rendering decorate where
you just first load the page and then you go find those things that you want to upgrade
and make them into the right stuff, you don't have to do that anymore. All of this happens
magically? >>Alex Komoroske: Magically, that's actually
a good point. I was going to ask, clearly we saw all of the extra stuff that's required
to make this poll demo work. But it's not here, so what's going on? All right. Well,
let's look. >>Dimitri Glazkov: And kind of the way that
you look at this is in the Web platform, we never had this opportunity to -- to build
in layering. Layering is like a cool thing. It's not -- it's also related to the lasagne
thing. But all of the frameworks, if you look at
them together, all of the JavaScript frameworks that are built out today are nothing but attempts
to provide a layering in the browser. Because what they want to do is they want to create
an environment in which the users of this framework don't have to think about the details.
And then the developers of the new widgets, the builders of the components, the ones who
work inside of the framework, actually have flexibility and power to, you know, provide
those new services to the -- to the higher level.
>>Alex Komoroske: By having this built into the browser, it means that there's no build
step, there's no extra framework you can use, you might be able to build the users of this
components, which is what the vast majority of the Web developers will be doing, it's
super simple, you do an import, you use these tags, it just works, however, if you really
want to understand the magic going on behind this, you need to go a little bit behind the
scenes, you have to see these more powerful concepts that are a little bit more confusing
that have a lot more to learn about. >>Dimitri Glazkov: We have a choice here,
do you guys want to continue or should we just stop right here, behind the scenes!!??
Yes. >>Alex Komoroske: Okay. So we're going to
go behind the scenes. If at this point you say what the heck is going on, that's okay,
you can just be a user of these components and not have to worry about it. Dimitri, why
don't you take us behind the scenes? >>Dimitri Glazkov: First we're going to talk
about Shadow DOM. Believe it or not, Shadow DOM already exists on the browsers, well and
alive, and the one and good example would be a video tag. Let's take a look at this
video tag right here embedded into this presentation, because, you know, our presentations are actually
HTML as well. Right? Okay. So as you can see you have really neat video tag right there,
right? Video/video, everything looks great, but there's actually more stuff happening.
There's slider there in the time line, and all these things. How do browser developers
do this? Right? How do they draw those things? Well, they have a couple of choices: One of
them is build the whole thing from scratch to build their own, testing right into this
thing, and we're kind of actually lazy and we didn't do that. What we did instead is
we invented a way where we could stash away a DOM tree where we can build those things
out of just normal CSS and DOM, and operate on them just the normal way, and then we present
it to you as if this is a built-in functionality, and this DOM tree, we obviously called Shadow
DOM, right? It's in the shadows.
>>Alex Komoroske: So how can we see what's going on here?
>>Dimitri Glazkov: So one of the interesting things is in Chrome browser, today you can
opt in to this experiment and you can say, well, I want to be able to show Shadow DOM,
and so if you're a load inspector, you will see that, when you inspect the video, suddenly
there's more stuff inside of it. It's that thing called shadow root. That's that hidden
DOM that you can't see. Let's go inside of it. Oh, there's a DIV. Oh, interesting input
type button. That's actually the play button, and then the input type or this style, open
that one right there, that will be a type range. That's the slider, right? That's the
thing. So what we did is we really, really cheated in a pretty big way, right?
We just -- instead of building all this stuff in C++, you know, and all this stuff, it's
just DOM. And, in fact, when you play this video, and you know how the timeline goes
away, that is just a CSS transition, right? It's nothing special.
>>Alex Komoroske: So what you're saying is that this stuff, this isn't new, Shadow DOM
has existed in some browsers already. What is new is exposing it to web developers.
>>Dimitri Glazkov: Right. So what we did next, we said, well, wouldn't it be cool if Web
developers could have the same power, and wouldn't you agree that would be cool? Would
that be cool? All right. So that's what Shadow DOM is about.
It's about encapsulation and providing you with the ability to add these extra chunks
on DOM tree and render them as if they're part of the bigger rendering.
>>Alex Komoroske: Okay. This is kind of complicated, so let's go through this in a little bit more
depth. >>Dimitri Glazkov: All right. Sounds good.
So the next slide here that we see, we have a nice diagram. As you can see it's peas and
radishes, clearly. So the green notes, the peas represent the document tree, that's the
actual tree that you see when you go into the inspector, and that's the one that is
parsed, when the browser parses your markup, and the pink stuff is the Shadow DOM tree,
so the Shadow DOM allows you to associate a special subtree with every DOM element,
and then this subtree, you can build and create DIVs and all kinds of things inside of it,
but then when it's rendered, you actually see the shadow subtree rendered instead of
the contents of that node, the element that you associate it with.
>>Alex Komoroske: Okay. So let me go over this one more time. So what we have here on
the left, we have these green nodes, or just the logical DOM that we're all familiar with,
and then off to the right we have a sort of parallel DOM hierarchy.
>>Dimitri Glazkov: That's right. >>Alex Komoroske: And so it's sort of stashed
off to the side. But if the Shadow DOM is defined, when we render, what we see, is as
though the pink nodes were underneath the green nodes.
>>Dimitri Glazkov: That's right. >> Alex Komoroske: So magically the green
ones are still there. >> Dimitri Glazkov: Right. So this is a really,
really cool concept right here, it's a render time composition. You don't have to move those
nodes around. They're still there -- if you walk your, you know, first child, next child
thing, next sibling, there's going to be only the green tree inside of it, but at render
time, the shadow DOM tree will be placed on top and rendered as if it's there.
>> Alex Komoroske: I had real stuff in that -- in that real in the green DOM tree. I want
to show that. It's kind of weird this is sort of (indiscernible)
>>Dimitri Glazkov: Right. Yeah, this use case is pretty good for a video, but you suddenly
lost that other green peas things that were hanging off the element, so what do we do
there? We have this really, really cool concept called
insertion point. Insertion points are special elements that you can put into your Shadow
DOM subtree to designate where the children of the shadow root will poke through, and
so as you can see there, I have two insertion points and when it's rendering, again at render
time only, those children will shine through inside of the Shadow DOM tree, so in a way
it allows you to have this way to compose the Shadow DOM subtree around your documents
node. >> Alex Komoroske: This is the same thing
that frameworks are doing today, right, because you have like your markup, then you call this
magic decorate method on it, then it swaps your DOM directly into the place it needs
to be to render. >>Dimitri Glazkov: That's right.
>>Alex Komoroske: This leaves it in the same place as before so you can still interact
with it like you did before. >>Dimitri Glazkov: The cool thing here, exactly
right, is that this is entirely render time, so you don't have to touch the DOM, in fact
the DOM stays exactly the same. What happens is this happens only at render time, so only
when this stuff shows up on the page is things appear in the right spot.
>>Alex Komoroske: Okay. So this is all very abstract. Let's go through a more concrete
example. >>Dimitri Glazkov: Sure. For example, the
element that we have just seen in the markup example here is implemented
using Shadow DOM, so you can see there it's a very simple subtree. The Shadow DOM subtree
has a DIV in it and has a little mask which stands for the little icon there, but then
you have this really interesting thing called content. Content is a name of the insertion
point; it's the HTML element which represents the insertion point. And then you see it has
a select attribute in a value that looks very similar to something. What does it look like?
People from the audience? Is that --
>>Alex Komoroske: CSS? >>Dimitri Glazkov: Right, so that's what you
use. You use CSS selectors to say which items will show through in my insertion point? And
so what we say here is the H3, first of type, which is the first H3 we find as child,
is going to show up right here instead of this thing when rendering, and then we have
a little aside item for our tool tip, and then we say, eh, everything else, universal
selector goes inside there. >>Alex Komoroske: So what we're doing basically
is we're using CSS to decide which elements to sort of funnel and tele-port where when
we render. >>Dimitri Glazkov: That's right.
>>Alex Komoroske: Okay. So what we're actually kind of doing here too is we're almost defining
a declarative API. We say if you provide some H3s, the first ones, what we'll use as the
actual name for the thing and later ones we'll just establish another --
>>Dimitri Glazkov: So you have this not only mechanism to stash things away into the subtree,
you also have a mechanism to now declaratively project some of the items. You don't have
to write a bit of script to do this. This is all built in. This is standard stuff. Awesome?
Awesome. All right. Okay. And so the next thing is we need to take these
Shadow DOM subtrees and build them into something useful, and that's where custom elements come
in. Custom elements allow you to define a new element, and for that purpose we have
the new HTML element -- that's a good name for it -- which allows you to specify and
say, well, there's my element, , and inside of it, the template. Remember the
template? That's where my Shadow DOM subtree instance is. Every time I create a new ,
that will be stamped out and create a new instance of the Shadow DOM subtree. And then
you can run script inside of it to do lots of cool things. For example, you can declare
an imperative API, and say, well, the method needs extra methods -- or
object needs extra methods or properties on it, and you can do this. And also you can
define things like life cycle hooks, like I want to run some scripts, register events
every time a new instance is created, right? That's useful stuff.
>>Alex Komoroske: So that's how you define it as a component author. For component users
all you have to do, you include this link to the components and point to the document
where this thing is defined, and then you can just use it like any other built-in tag
in your page. And also, so you talked about those imperative APIs we defined here, was
selected on this thing. If I go through and grab this element out of the DOM using various
lectures, say, I can just call that method directly on that object, the DOM object. The
DOM object is the object. >>Dimitri Glazkov: Right. And there's no faking
there, right? There's no need to create separate objects or view or things, your DOM objects
are the actual things that you operate on. When you query the standard DOM APIs, use
them, whatever comes back to you is going to be those things that you define.
>>Alex Komoroske: You don't have to know the convention of the framework, how we stash
things and how DOM are related. >>Dimitri Glazkov: And also the link rail,
the new rail components, gives you the opportunity to create the packaging mechanism to build
packaging right into the browser. You don't have to have a build script that then compiles
all this thing into one gob of code. You don't have to have five script tags loaded into
your page. One link rail, you can load other link rails if you want, you will have more
components that you want to reuse, and that's all it takes. So it's packaging. It's reuse.
And also the ability to have one DOM hierarchy instead of multiple tree objects.
>>Alex Komoroske: So one of the problems we have today on the Web platform is styles sort
of naturally go all over the place. And so when you're designing a style for your component,
it might go and mess up somebody else inadvertently. >>Dimitri Glazkov: That is a very common problem,
especially if your object tree is pretty complex. At some point you really start losing sight
of where -- which selector, and you know, how many of you guys have committed the Cardinal
sin of pound important? Okay. Be honest here now. And so in Shadow DOM, there is some really
cool stuff here. In Shadow DOM the styles are implicitly or explicitly scoped inside
of the Shadow DOM subtree. So even if you put a universal selector inside of the Shadow
DOM subtree, it will only apply instead of inside of the Shadow DOM subtree. So it will
not go and bleed out into a document. Similarly, styles that you apply in the document will
not bleed into your Shadow DOM subtree. So you have a very nice style separation boundary
which really works extremely well for widget case scenarios where you want to have the
boundaries defined and you don't want people to stomp on your styles, and you want to keep
some sort of sanity inside of your application. >>Alex Komoroske: Okay. So that is sort of
behind the scenes. Thank you for that, Dimitri. I actually just got a call from a designer,
he's watching on the live stream, and he says that we shouldn't have used accordion, we
should have used a tab strip in our demo. >>Dimitri Glazkov: I actually agree with the
designer, accordions are kind of weird anyway, right, a cross between a piano and a harmonica,
really? Oh, you're talking about a widget. I'm sorry. Okay, yes. So that is actually
really easy, because we're using just markup, we're just
swapping tags, so the idea of swapping out components now becomes just changing your
markup, right? So now we have to just include in your component and then change X accordion
to be X tabs, and it's, you know, it's -- we'll just see what happens, right?
>>Alex Komoroske: Okay. So you say I have to include the new component, which I actually
already did when you were talking, and I needed to change X-accordion to X-tabs, is that right?
Save that, switch back to the demo and just refresh.
>>Dimitri Glazkov: And now we have tabs. Applause, please. [ APPLAUSE ]
>>Dimitri Glazkov: No wing suit drop, no wing suits, but at least, you know, some cool tricks,
right, at some point. All right. So this looks really, really awesome and I'm already kind
of enamored with this. I don't know about you guys. But I really want this poll on my
website now. >>Alex Komoroske: On your site.
>>Dimitri Glazkov: On my site. >>Alex Komoroske: just so guys know, I'll
show you what Dimitri's website looks like. It's beautiful. It's really special. It's
awesome. So, no offense, Dimitri. I definitely hear that you want to have this poll on your
site. I'm a little bit concerned that you might mark with it a bit, but that's okay.
I'm going to package this up for you so that you can include it on your site without you
worrying about how you're going to set this up. First of all, I don't want you to be able
to change the text for the choices, that way you could stack the deck.
>>Dimitri Glazkov: I could add my own choices, right? CSS 3. Why not CSS 4 or 7?
>>Alex Komoroske: So what I'm going to do actually is I'm going to create a new element
called awesome poll, obviously. >>Dimitri Glazkov: Has to be awesome, awesome
site, right. >>Alex Komoroske: And then to hide it from
people who are vetting it, I'm going to take and put in my Shadow DOM one of those polls
so you can't see it. >>Dimitri Glazkov: Okay.
>>Alex Komoroske: Then what I'll do is I'll allow yourself to define sort of where this
configuration is, and I'll then create all the stuff inside the X poll in my own little
area. >>Dimitri Glazkov: Have you guys seen inception?
And if you haven't, please leave the room now. It's like we have to go one level deeper,
right? Shadow DOM inside of the Shadow DOM. You know, seriously cool stuff.
>>Alex Komoroske: Okay. So what we'll do, so then you can just put that right in your
page and you will have the poll right there. Awesome.
>>Dimitri Glazkov: Wow, this is -- well... >>Alex Komoroske: What?
>>Dimitri Glazkov: It kind of looks not like my site actually. The place my vote clearly
doesn't have enough exclamation points. I don't know. I kind of want to customize it
a little. >>Alex Komoroske: Okay. Okay. So you're right.
This is actually technically just as good as an iframe basically. Doesn't give you any
way to customize it. So you have such an interesting vocabulary and way of speaking.
>>Dimitri Glazkov: I do. I'm a very colorful person.
>>Alex Komoroske: I don't want you to have control over everything, but I guess -- I
guess subtitle and the button will allow you to override. So I'm going to define in my
poll, I'm going to allow you to have a declarative API, allow you to define your own aside for
that subtitle and your own label text. >>Dimitri Glazkov: That sounds good.
>>Alex Komoroske: What we'll do is we'll switch back to your site. Right here. I already wrote
in here where you had this customization, save that, switch back to my demo, refresh,
and vote for CSS 3 because it's awesome, and vote now.
>>Dimitri Glazkov: Now I have plenty of exclamation points, right, guys?
Think about what just happened. Just stop for a second. I have customized a poll without
mucking it up, because Alex is a developer of this custom component, of this web component,
the awesome poll, only gave me the guardrails to step into this specific areas, and that's
all. And the way I do this is by markup. I don't have to go GS and do some weird muckety
muckety JSON stuff. Well, you know, the font kind of looks like a clean and creepy. I want
something huggable and wonderful. What could be more wonderful than comic SANS? It's from
the perfection, right? So what we're going to do -- I want to say
that I'm not going to do this unless you let me customize the font.
>>> I admire design aesthetic, I think it's very unique, but I don't want you to be able
to run all over this stuff and break everything, so I guess what I'm going to allow you to
do is change a couple of things in here, before I do that, I'm want to walk you through how
I'm going to do this. So CSS variables is one new technology, the spec is nearing completion.
We actually have it implemented in Chrome behind the flag. CSS variables --
>>Dimitri Glazkov: Wait, wait, wait, did you just say CSS variables? Guys, are you getting
this? Are you getting the CSS variables? >>Alex Komoroske: Yeah, it's kind of cool,
right, because today you have to have, define pound FFF, one, two, three, four, like 8,000
places in you're CSS. This allows you basically to define it once. So they're actually really,
really powerful. You can do all kinds of cool stuff with cascade and referencing other variables.
We don't need that today. I really encourage you guys to look more into CSS variables and
all the crazy, amazing stuff it can do, but the cool thing about CSS variables is it allows
a very natural place for me to allow you to override what I want. So when I'm writing
my poll, I'll use CSS variables very deliberately in places that I want you to be able to hook
in and change my stuff. >>Dimitri Glazkov: So these are my styling
hooks. I can't go anywhere and mess with anything else.
>>Alex Komoroske: I'm only giving you -- allowing you to change a few things. So in this case
I'll allow you to change maybe the font and also the color that we use as the primary
color. >>Dimitri Glazkov: Colors are important.
>>Alex Komoroske: What you'll do on your sheet is you'll just style -- direct some styles,
these variables at my poll, and then it will magically just work.
>>Dimitri Glazkov: I want to see this. >>Alex Komoroske: I'm going to switch to CSS,
and I'm going to uncomment -- I've already written --
>>Dimitri Glazkov: You made the right choice. >>Alex Komoroske: Comic sans, I thought you
would like that. I'm going to switch back to my -- to your site. Refresh. There you
go -- >>Dimitri Glazkov: This is now awesome. I
can do this. [ APPLAUSE ] But again take a second to think about this.
Now you as the developer of the widget or a component can give specific instructions
to the browser on what to permit the user of the component to do. Isn't that awesome?
Isn't that styling APIs? Who wants this? Who wants this? [ Applause
] >>Alex Komoroske: I want this.
>>Dimitri Glazkov: All right! >>Alex Komoroske: Cool. So we've walked you
through a couple of examples of how to use this stuff and also some of the tactical uses
you can have with this. And actually is a bigger deal than just that.
The way that I think of that actually -- I'm actually a little bit dramatic, I guess sometimes,
is the declarative Renaissance. So way long time go, you just used HTML, you just wrote
(indiscernible) code straightforward, and then we started using JavaScript a lot for
a lot of stuff, right? But now this allows people to return back to writing things very
declaratively in most cases. There's a lot of stuff that allows that to happen.
>>> And like one of the most important things that I think is -- the ability to actually
talk via an API. Or tell the browser, specify to -- to let the user know: These are the
things that you can do and no more. And no matter how much you hack about on this or
do whatever this -- whatever, you can't mess up my stuff. My stuff is safe. I gave you
these hooks, that's all that you can do. You have CSS variables for the styling API and
you have the components, the Shadow DOM technology, to allow you to have the markup API. And then
you, of course, can define -- define the imperative API on custom elements. So the Web components
give you those three things. To essentially explicitly define APIs on the components now.
Awesome stuff. >>Alex Komoroske: So another one that's really
cool is we talked about before, if DOM is your composition mechanism, then components
from different libraries just work together. This is neat, I'm like oh, cool, you can get
whatever widget you want. But it also means that today we have to spend all of this time
recreating tabstrips and calendar controls and everything in each and every framework.
And, of course, each time you do it, you probably aren't going to get 100% perfect, but 80%
of the way there. But if everyone can use any calendar component, then people will start
using the better one, it will be more of an incentive to build really, really awesome,
accessible, beautiful, interactive components. You will see a lot better components as well.
That little mini browser that was built inside of your browser, you can say well, no longer
I am just specifically a backbone man. I can just use markup and mix them around, because
this is just markup. It's a common media. Just standard stuff is in the DOM, in your
browser. If you look at this, you can clearly see another
advantage. For a -- for a company or a team of people working on the same Web applications,
ability to encapsulate offers tremendous advantages, right? Because now you can work on this stuff
that you have to do today when you build complex applications.
>>Alex Komoroske: Cool. So the other case is that again most cases are fully declarative.
So these people who don't know script, they don't have a CS degree, they can still be
really productive. They can build really cool stuff with these components.
>>Dimitri Glazkov: Right. And one of the other things here is because the browser is taking
care of loading and understanding the packaging obligations, the rendering of the things,
one is kind of crazy, so bear with me, is the rise of shared semantics. So today your
But if you allow people to define these tags that are useful to Web developers, it's very
obvious if we are -- for example, we will see these x-polls, it's very obvious that
people find that useful. And so this is a great way for Web developers to experiment
with new components and things. After a while, maybe you will see that everyone is using
tabstrips, they are using it in the same basic way, well, we just roll that into the spec,
roll that into the standard. >>Dimitri Glazkov: Directly into HTML.
>>Alex Komoroske: Directly into the browser. Why do you have to define your own? This is
a great place for Web developers to experiment, show us the way as browser developers, about
what stuff we should be directly baking in. >>Dimitri Glazkov: Right. And if you look
at it from another slightly different perspective, is that today there is no path from local
semantics, the semantics of your framework, to the global semantics, the public semantics
of HTML. Once you've built that thing imperatively, there is no existence of the actual tags,
there is no path to the tags. You can just study those things, and look at the patterns
and wonder what is the right thing. But there is no path. With the custom tags, you actually
start having this path because these are just tags. And now all that you have to do is run
a really, really large query, which Google can do actually,
and figure out which elements are common. Then you can know precisely which tags are
winning, which tags deserve to become more public and at some point make it into the
-- into the HTML spec, for example. >>Alex Komoroske: It's really cool stuff.
Again, Dimitri and I come from the future, so that's why we can talk about all of this
amazing stuff. The good news is actually that the future isn't quite as far away as you
might think. We aren't from, like, years in the future; we're from, like, a few months
in the future, basically. So shadow DOM and CSS variables are both implemented
in Chrome today. They are behind the 5. They aren't released on the Web yet, but if you
really want to you can go on and play with them. There are lots of effective polyfills.
Polyfills are basically shims that allow you to use functionality before it's directly
in the browser. We'll talk about those in a second. And another thing is this is not
a Chrome thing. This is being done in standards, we have a lot of other browser vendors are
extremely excited about the number of folks from those are in the audience today. We are
really working, this is a collaborative effort, a concerted effort with everybody to build
this. So this is something that you can actually look forward to using relatively soon.
>>Dimitri Glazkov: It's happening, guys, it's coming, seriously.
>>Alex Komoroske: So what can you guys do that you are all jazzed up about this stuff?
Well, you can help the future arrive faster. The one way -- there's lots of links and information
on this slide. What you should do right now if you are already a member of the Web components
plus page is follow us. We have a Google short link right there for you. This is where we
post interested updates about the spec, the implementations, cool examples, blog posts.
It's the one place that you can really learn about all of this stuff going on. And right
after this we're going to post all of these links to that plus page. If you want to, you
can read the introduction to Web components. You probably learn that
specs are really hard to read and they often are, but actually Dimitri has done an amazing
job writing an explainer, that goes through all of these concepts, in quiet some depth
but in a very readable way. >>Dimitri Glazkov: I promise there's no comic
sans on that page. If you are scared. >>Alex Komoroske: You can also read the CSS
variable spec, understand more how that stuff works, all of the amazing stuff that you can
do with it. It's really more powerful than it looks.
>>Dimitri Glazkov: The other thing is that there is actually a lot of really cool discussions
happening right now in your present about the Web components and working out all of
the corner cases, working out the kinks of how things should work precisely. I mean we're
in the future, all of those things are solved, we don't have to worry about them, but you
guys have to worry about it. Because getting this stuff done just right and making sure
this does not suck is really, really important. So, please, if you have any, you know, gumption
for bike shedding, or really, really endless discussions with no end, please join the standards
list and start listening in, start understanding what's going on, what's happening.
>>Alex Komoroske: It's also possible to start building with this stuff today. Dimitri has
written a polyfill for Web components, all it requires is Shadow DOM, so you would have
to turn it on in Chrome to play around with it. That's a really cool thing that actually
makes the polyfill for this entire thing, everything that we have shown you today is
how we actually did -- >>Dimitri Glazkov: You know those self driving
cars? It's like that. It's like a very, very early prototype that you can possibly drive.
Bad things may happen, I can't guarantee-- >>Alex Komoroske: Don't use that one for anything
in production today are written by Daniel Buchner, who I believe is right there from
Mozilla, he's built this really cool library called x-tags. X-tags is basically a polyfill
for the custom elements part of what we showed you today. The cool thing about that is this
actually works in all major browsers. It uses a number
of very clever hacks to do it, but you actually can start building real apps on top of this
today if you want. >>Dimitri Glazkov: Daniel is actually actively
at work building a pretty, pretty solid toolkit on top of this, the UI widget library that
would potentially power some really, really cool applications in the future.
>>Alex Komoroske: That's really cool, so check that out once we post the link to that plus
page. All right, great! So that's all that we have
for you today, we wanted to share a little bit more about Web components, it's a really
exciting thing for the future. Thanks so much for coming out. [ Applause ]
>>Dimitri Glazkov: And -- and in the future -- the future bus leaves in 10 minutes, but
until then we can answer your questions if you would like.
>>Alex Komoroske: Come up to one of these microphones that we've got here in the aisles.
>>> What about events? >>Alex Komoroske: What about events is the
question we got from the audience. >>Dimitri Glazkov: The events are actually
also handled by the Shadow DOM specifications, and there's really neat things that we do
to make sure that the information in the event never escapes outside of the Shadow DOM subtree,
but the events are heard. It's called retargeting. What happens is that if something fires, like,
for example, if you click a play button in your video element, the event or the click
event propagates out, but it looks like it came from the video element. Does that make
sense? So it's actually a really complex part of those things, and we fought extremely hard
to make sure that Shadow DOM feels transparent to the user and it doesn't look like it's
affecting any actual normal operation of the events. But the information from the inside
of the Shadow DOM subtree never leaks out on the outside.
>>Alex Komoroske: We've got a question at this mic.
>>> So it sounds like a lot of this is helping you with bringing in dependencies and encapsulating
code. Have you guys thought much in the spec about dependency management, you know, I mean,
obviously a lot of Java developers and a lot of developers in general use Maven for that,
so you don't get dependency explosion with inside your app. There's that encapsulated
part but, you know, in a team you want to try and use consistent dependencies across.
Has that been addressed in the spec at all? >>Dimitri Glazkov: At this point there is
just early discussions on how this actual linking of the custom elements, the packaging,
will happen, so this is actually a good time to start talking and start discussing this
type of thing. I mean you saw that in the future and you saw it works but, you know,
later on. >>> What about like with media queries where
the widget, the component need to adapt based on certain break points, and usually those
break points are going to be different based on whatever context of the app they are used
in. Right. So one of the interesting things there is that first of all we made sure that
Shadow DOM actually operates within the confines of CSS, we are not inventing anything abnormal,
so all of the CSS machinery the way that you operate on it will just work. It just feels,
it has the same -- it will feel like it's just part of the documents. So you will get
all of the same information about the size and media queries, things like that.
>>> (Inaudible). >>> I'm an extension developer in the users
group aficionado, and there's lots of templated sites out there that don't use that yet, but
that would be great to extend. And are you thinking about how to integrate this into
the Chrome extension API so that we can add components where there are none and change
one of the really, really use cases for extensions, the ones that modify the page on the fly.
Because what you can do is you can build a Shadow DOM into an element and the document
doesn't know that it's there. And so yes, it's a very common use case, yes, it's coming.
was thinking could you invent the map API into the Shadow DOM so it would build a custom
tech for example a store locator and give that to a customer and say, hey, do this and
case, doing exactly that. In fact, one of the components of x-tag --
>>Dimitri Glazkov: Talk to this guy, he's already got one.
>>Alex Komoroske: That's an awesome use case for it. Yeah.
>>Dimitri Glazkov: Come on, bring it on! >>Alex Komoroske: Anything else?
>>> What about the SCO, like there's potential information like the SI tag that would be
less important, would Google bot pick that up because it's not potentially rendered on
the page? >>> We don't work on the search team so we
don't know the answer to that question. We can imagine there's going to be interesting
changes in the way that people -- >>Dimitri Glazkov: It doesn't have to be on
the SI tag, it can be on H1 or poll, if you want it to. It's up to you to define it as
the author of the API. >>Alex Komoroske: If there are any other questions,
Dimitri and I will be hanging around for few minutes afterwards if you want to ask us any
>>Dimitri Glazkov: Yay!