Muckety

Transcription

>>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 <x-choice> 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, <x-choice>, and inside of it, the template. Remember the template? That's where my Shadow DOM subtree instance is. Every time I create a new <x-choice>, 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 <x-choice> method needs extra methods -- or <x-choice> 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. >>Dimitri Glazkov: Right. No longer you have to pledge allegiance to a specific framework. 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 without worrying about stepping on each other's toes, you can have a clean separation, you can build work flows that actually make sense and not have this crazy schemes of discipline built into this. Making that sure your selectors have to start with #foo and all of that thing 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, it can go much faster because the browser ultimately kind of knows more about rendering than any author or any JavaScript engineer could do because we have a little more hooks than standard JavaScript application could. >>Alex Komoroske: The final one, and this one is kind of crazy, so bear with me, is the rise of shared semantics. So today your semantics might only apply within your site because there's no good way to share them. 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 them? >>Dimitri Glazkov: Shadow DOM is actually 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. >>> Thank you. >>> I'm a (indiscernible) developer but I 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 -- >>Alex Komoroske: That's a phenomenal use 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 other questions. Thanks so much. [ Applause ] >>Dimitri Glazkov: Yay!