Eric Bidelman: Polymer and Web Components change everything you know about Web development

All right. That's my cue. What's up, everybody? Thanks for coming. [AUDIENCE CHEERS] Web Components! It's going to change everything you know. Well, maybe just a few things. But the field is open. That's the web development. It's open to you, to use Web Components. My name is Eric Bidelman. So let me turn my clicker on. My name is Eric Bidelman. I work on the Chrome team. Feel free to follow me on Twitter or Google+. We probably won't have time for questions. I've run this a number of times, and I always end up at 45, exactly. But feel free to shoot me questions there or ask me questions at the end of the show. I'm happy to answer stuff. I've been focused on Web Components for a couple years now, because I really do think it's a fundamentally different way to develop for the web. I think it's a really exciting time to be a web developer. And so that's why I'm here, talking to you today. In this presentation, I want to focus on three areas. Let's keep it simple. The first is the state of the union. A couple people asked about browser vendor support, where the API is in flight, as far as other browsers. I want to catch everyone up, get us all in the same space, and kind of get you thinking about what's happened in the past year. A lot has changed. Second, I want to talk about what problems do Web Components actually solve. Why am I up here barking at you guys in the first place? Why are we adding all this new stuff to the platform, if all these libraries and everything else exists today? It turns out there's actually a number of things that Web Components really do address. That's why this stuff is being baked into the browser. And the last thing, I want to get everyone in the same mental space. We have to actually think differently about how we build apps now, in the world of Web Components and Polymer. So I want to get us thinking in Web Components. What does it mean to design an app, architect an app, and kind of conceptualize what that means? So that's what we're going to cover. But first, let's tell a little story. So once upon a time, the web platform looked like this. The web platform was kind of a conglomerate of duct tape and nails and strings, and we pieced in some CSS over time, and maybe some JavaScript over time. But it was pretty infant, right? And it was pretty primitive. This is all we had at our disposal, though. We couldn't build complex apps. You could drop in a form tag. Right? We could build-- that was the app at the time, was forms. And over time, what happened is, of course, yes, we got HTML5. This is going to cure cancer. It's going to solve all the world's problems. And it certainly did, right? Well, it didn't do that. But it addressed a number of things that we needed on the web, right? Geolocation, local storage, new semantic tags-- a lot of great stuff came through HTML5. And over the years, we've just kept building on that, right? We've kept adding to the web platforms. We added media APIs, and WebGL, and Web Audio, and all this cool stuff to make the platform really viable and really awesome as a development platform. But what about us regular developers? What about myself? I write JavaScript, and I write HTML every day. But I don't write WebGL code. I've never written a shader in my life. What APIs are the browser vendors adding on our behalf, to make us more productive? And so this is where this journey started, now four years ago. If you go all the way back in time to 2010, this is when the Web Components journey started. So if you look at the first kind of tinkering of Web Components, Dimitri Glazkov, who is one of the sort of godfathers, the forefathers, of Web Components, sent an email to the public web apps mailing list and said, hey, you know, a few of us have been tinkering around with ideas about things we can add to the browser to make developers more productive. So this is actually kind of telling, at the time. They identified things like templating, right? Every development platform out there has templating. Why doesn't the browser have native templating support? Shadow DOM-- being able to abstract things and encapsulate them and kind of bring the best practices of object-oriented programming to the web-- was identified four years ago, now. And things like data binding. Now, we're not getting data binding, properly, as part of Web Components. But this is something that Polymer has built-in and iterated on top of the Web Components APIs. So it's been a long journey. And so what they said, was, hey, let's take our web platform. Let's strip it back. Let's identify the core APIs, the core primitives that we need, in order to make this really productive for developers. And this is where the different specifications came from. So we have about four specifications that make up Web Components as an umbrella technology. The really cool thing about all these different APIs are that they can be used totally separately by themselves. But when you put them together, it allows developers to tweak and do really amazing things. And that's what Polymer's doing. It's having opinion, on top of Web Components. But the lowest level is all standards-based. So last year, I gave this presentation at I/O. It was called The Tectonic Shift for Web Development. We're still shifting. The stuff is still new. But it's actually a really exciting time. If you look back, even just a year ago, a lot has changed since 2013, when I gave that presentation. So I probably painted a picture that said, hey, the native stuff is in browsers everywhere. But it's actually mainly just in Chrome, with a couple of APIs in the nightly build. So you can see that's what the partial support means, in those logos there. Firefox had landed templates. They're just starting to implement custom elements. Of course, if you flash forward today, this matrix is completely different. It's completely lit up. This is a milestone in web development, you guys. Chrome 36 is the first browser to have all the native APIs for Web Components. Opera gets all this stuff natively because of their use of Blink. So that's two browsers with all this stuff. Firefox has got templates and custom elements now, and the other partial support for the other APIs is in their nightly builds. You can flip that on with the developer flag and try that stuff. Of course, the other ones, we don't know. But with the polyfills of Polymer that the Polymer team is kind of building over time, you get all the support in all modern browsers, for all of the APIs. So as I said, if you want to follow the progress of Firefox, they have a master bug for all the APIs you can check out. They're heads-down implementing all this stuff. Apple decided to remove Shadow DOM. Some of you may have seen this come up on Hacker News. And I just want to point out, this was on Valentine's Day. They broke our heart. But they said, no, that was kind of just a joke. We're actually experimenting with this stuff in a branch of WebKit. And so what happened was they didn't have a maintainer for all the code base that happened due to the WebKit Blink fork. And so then they said, hey, we're actually checking this stuff out, seriously. So we're adding stuff back. Of course, the one that everyone asks me about is IE. And IE has hope, OK. So there's hope here. If you go to their Platform Status page, all of the APIs are under consideration. So there's hope. There's promise here. But just between you and me-- and I think Matt alluded to this before-- we've had some really productive conversations with them. And they're asking the tough questions, which means they're taking and seriously looking at this stuff. So that's the browser landscape for the native stuff. The other thing that happened in the past year is people built stuff. Developers got excited about Web Components, and so they built stuff. On the Polymer team, we said, hey, we might as well dog-food what we're building, what we're really preaching here. Let's build some stuff. So we built the Polymer site, to use Polymer's components and to use Web Components. I built chromestatus.com, which the Blink team uses to sort of maintain the features in Chrome and for developers to see what's on the landscape of Chrome. These are really good examples of just using small chunks, small components, and putting them on a larger site. Chrome Status is a database-driven website that has a component that talks to the database and gets the JSON feed. It renders the versions of Chrome on the side there. That's a Component, responsible for that. Another thing that happened, we got wind of early, a couple weeks ago, was the WinJS team started to experiment with moving some of their controls and testing some of the WinJS components as Web Components. This is really exciting. And they were starting to use Polymer to do this. So if you want to check that out, that's up on GitHub. GitHub, in production, launched custom elements. This is so cool. I use GitHub every day. And I saw this, and I got really excited, giddy in my pants, actually. The local-time tag is something they're using on the site. So any time you see a pre-printed date on a GitHub page, that's a Web Component. Very cool. They're using Polymer's polyfills for that. A little-known fact-- Chrome OS's keyboard, any time you fire that up, that's a Web Component. That's implemented using Polymer. And when you kick back and listen to tunes or media in Chrome OS, the media player is also a Web Component. It's also a Polymer element. Very cool stuff. You'll see some more examples from Rob. And Matt showed you some stuff that we built, also, in the Polymer team. So that's where we're at. That's the state of the union for Web Components. I want to focus now on problems Web Components actually solve. The grass is greener on the other side of the field. So most people see "BCE," and they say, "Before the Common Era." I actually say, "Before Components Existed." So there's a time before Web Components, in the world of web development, and there's a time after Web Components. And now we're in this sort of other spectrum here. And what I mean by this is that we have to conceptually think how we build apps differently. So if you take an example like the Polymer site, right? This is the Polymer site. It's using Components. But what we've chosen to do is I stack this in different pieces that are logical. So for instance, the top nav here, this app bar, is responsible for when you click that search icon. It expands and it is responsible for that functionality. The center content is actually a Component, too. It's a scrolling Component, that when you scroll the page, the headers kind of shrink down. And when you scroll back, it grows again. So it adds its event listeners. It does all that stuff. It's all baked into that Component. And of course, we have the menu bar. The menu bar is a Component that has sub Components inside of it, right? So we can just reuse that on different parts of the site. So it's about compartmentalizing the problem, no longer thinking of a site, or an app, just as a bunch of JavaScript, a bunch of CSS, and a bunch of HTML, just all hoping it'll kind of work together. There's a logical separation now. So the first API of Web Components is Custom Elements. And Custom Elements allows us to define new HTML and DOM. And the problem that it solves is this. So this is an actual application. This is not just a made-up example, right? This is Gmail, if you fire up the DevTools and you look at the markup that Gmail's constructed from. I call this div soup. There's just a bunch of divs. It's meaningless. I don't know what it's actually saying. I can't read this as a developer. And this application is not descriptive, whatsoever. And that's no fault to the developers. It's no fault to the Gmail team. It's basically that HTML didn't keep up with the times. It didn't actually allow us to build the complex apps that we needed to build. As the web evolved, as demand of applications evolved, HTML got stuck in the '90s markup, right? Divs. Even an example like a tab strip, right? Let's take this, just as a small Component. Let's create a tab strip. This is a really common thing to do. If you look at that today-- or I should say yesterday, now that we have Web Components-- every single version of every library, every UI framework out there, does it differently. Some use a little bit of HTML. Some use HTML with JavaScript. And some just go the entire JavaScript route. So it's not so much HTML versus JavaScript. The point here that I'm trying to make is that these are all different, right? Everyone wants to create a tab strip, but it's all different. And that's the problem. The APIs haven't existed. The Web Components APIs haven't been there to make this a standard way to create a tab strip. So as a developer, you come into this. You have to learn somebody's new API, calls, to use a tab strip, or put it on your page. And that's just no good. So this is where Custom Elements come in. With Custom Elements, we can just declaratively define a new element. We'll create a paper-tabs element. It's got a selected attribute. It's completely declarative, and you know exactly what's going on in this application. I can click this around. This is an example of one of the material design elements we have. You see that property changing. And that element is firing the event, the core-activate event. So we can use querySelector with this thing. We can use addEventListener. The rest of the platform comes along, because we're just creating HTML. We're just creating DOM. It's meaningful. It's maintainable. I can read this code. I know what's going on. And the last thing that I want to point out-- I'll talk to this in a few slides-- is that we have a common way now, with Custom Elements, to extend other people's stuff. It's in a common extension model. So we can extend native HTML elements. You can say, I want this div to be a super-div. Or you can say, I want to extend somebody else's paper-tabs and create my own version. Very cool. So for these type of slides, I'm going to show you sort of the vanilla Web Component way to do things, the way Polymer uses the technology, and what we do to sugar it, and then the usage of the Web Component at the bottom. So let's go through this. The way you use Vanilla Custom Elements is just document.registerElement. And the thing that you give it is the name of the tag that you're going to create. So I'm going to create the paper-tabs element. Now, in Polymer, what we said was, hey, we really think declarative is awesome. It's very powerful. It's very easy. So we created a polymer-element. We created a Custom Element that allows you to create Custom Elements. It's super-meta, but it's actually really cool. And it shows you the power of all this stuff. You can create an element from an element, declaratively. So in Polymer, we say, hey, declare a polymer-element. And the name attribute that you give it is the tag that you're creating. So those are the two different versions. But the really nice thing about this is it doesn't matter if you're using vanilla Custom Elements. It doesn't matter if you're using Polymer x-tags or anything else. The usage, the way you use this thing, is exactly the same, right? You declare paper-tabs on your page, or you create it in JavaScript, and then you're good to go. I mentioned extension, a common way to extend other people's stuff. In vanilla Web Components, you can say, I want to create a super-button. So you'll give it the tag you're creating. And this time, you're going to inherit the prototype of the thing that you want to create it from. So I'm going to inherit the HTML button elements prototype, because I want that functionality in my JavaScript prototype. And I'm extending the button tag. In Polymer, we say, hey, we'll make this declarative, too. We'll make this a one attribute that you put on your element, extends='button.'" So we're creating a super-button. And then, again, the usage of this is exactly the same. Button is a super-button. This is a type extension Custom Element. We can also extend other people's Custom Elements, not just native HTML. So is this really better than before? Great, we can create some HTML. We can tell the browser about it. Is that cool? Yes. It's totally cool. I think it's cool. But the reason it's cool is, there's a couple of really great examples. The first is that we're integrated with the browser now. The fact that we're creating HTML, and the fact that we're creating DOM, is actually really important. We can take advantage of other parts of the platform that are new, like MutationObservers, querySelector, and addEventListener. These are things that already exist. We can just reuse those in the world of Web Components. We can take advantage of the browser's parsing and caching logic. All that stuff that's been set up, and the browser engineers have worked very hard and long nights to actually make really fast for us, we can take advantage of that, because we're integrated at the browser's lowest level, which is DOM. That also brings us interoperability. So it doesn't matter if a component is built using x-tags or if a component is built using Polymer. The fact that, again, they all speak the same language now, which is DOM, means you can use these things together. And you can mix and match them in your app. It doesn't matter who vends them. You just use the stuff. So it's interoperable. I'll admit, I don't make all my demos and all my apps accessible. You guys should. You, out there in the live stream, should, too. But it's actually really cool. Now we can take advantage of keyboard stuff that the browser has. Focusability, ARIA roles, all that stuff that's there for us-- we can build that into our Custom Elements, just by default. And the last one that I'm super-excited about is DevTools support. So first-class support for tools. I want to show a video of this because I really do think it is that cool. This is Polymer's site. And we have this little tab strip widget in different places of the site, where you can select kind of a code view and see a live preview at the right here. I'm going to just show you this in action. So that's what it does. Now, the fact that we're creating HTML and telling the browser about this new element means we're integrated with the tools. So I can poke around in the Elements panel. I can inspect that, just using your common inspector. I can fire up the console. And I can auto-complete this element's APIs and discover its properties and methods. So that's really cool. I can change this thing, right? You're changing the tab dynamically, just by changing that selected property that the element has. CSS and HTML work really well together. So I can change the styles in the Styles panel, and it just updates itself, right? So I can tweak and use the DevTools Save functionality. So all that really cool stuff that the DevTools team has been building-- remote debugging of the console, auditing-- all that great stuff, you can take advantage of now that you're kind of integrated at the browser's lowest level. So first-class Tools support. Very huge. The next API is templates, HTML templates. And what templates does is bring proper, native client-side templating to the browser. Templates yesterday looked something like this. So the way a lot of libraries and frameworks do templating is that they say, hey, put a bunch of stuff in a script tag, and we'll change the MIME type so the browser doesn't actually throw that off to the JavaScript engine. And so that's great. But what you actually put inside is not DOM. It's just strings. So we're pushing strings around. And it feels kind of icky. The other way that people do this is they have a template, a constructor or something, and they'll have a template string. So it's just you're scaffolding out using a string. And then you have a render method. So template, render, template, render. And so what the Web Components folks said was, hey, we should just bake this in. Why do every framework and library do this differently? So what they brought us is the template tag. And the template tag has some really amazing properties. So the first is that anything you put inside of it is going to be totally inert. It's not going to do anything until you clone this template, until you stamp it out, until you activate it. So for instance, this image in here, this image.png that I have in my template, is not going to make a request. It's actually not going to be requested until I clone this template and use an instance of it. So script's not going to run. Video's not going to play. It's got a lot of great inert properties like that. It's display:none by default. So I can't actually see this template. It's kind of hidden away in the document. In fact, you can't even traverse into it using the DOM APIs. It's truly a template. It's out of the scope of your page. And the last one is we're using DOM here. So this is truly DOM that you're scaffolding this thing with. You're not pushing around strings anymore, which is really, really good. You're at the browser's lowest level. So the way you do this in vanilla Web Components, using template, is just you drop a template on your page. And you can scaffold out markup using markup. In Polymer, we said, hey, any time you create a Polymer element, all the guts of your element are going to be inside of a template. So you get all that inert properties that I talked about. Scripts are not going to run until an instance is created of your element. Now, the other thing we've done is we've said, hey, we want to teach template a couple new tricks. So we have the outermost template, which is the thing that your markup of your element is created from. But the inner templates can do things like use data binding features. So you can have an iterative template that says, for user in users, stamp out this markup, declaratively. You have conditional templates and that sort of thing. So it becomes really powerful. The entirety of inside of your Polymer element can be declarative, just by using these features and the data binding stuff. The next API, one of the big daddies of Web Components is Shadow DOM. And what Shadow DOM brings to the table is DOM and CSS scoping. If you take anything away from Shadow DOM today, or in the future, it's that it brings composability and scoping to the web platform. So we can kind of look down this little lens and scope the problem, design our apps in small chunks, and have some guarantees that things are protected. So in vanilla Shadow DOM, the way you use this is say, hey, I have an element. I want to put some Shadow DOM behind it and abstract that stuff away from the user. So you call createShadowRoot. And then you fill the inner HTML of the ShadowRoot with a bunch of DOM. In Polymer, we said, hey, let's just get rid of all that. You don't have to call those explicitly. We're just going to say, anything you put inside of your template, inside of your elements template, we're going to create Shadow DOM from. So by default, all polymer-elements use Shadow DOM. Because we think the scoping features and the composability features that it gives you are very, very powerful. So let's walk through an example of showing you what composability means, and also CSS and DOM scoping. Right now, I have some markup on the page here. I have an image, my profile image, an h2 and h3 for my title and description, and my Twitter handle. So right now, we're not in the world of Web Components whatsoever. We just have this markup, just as it is on the page. So let's first wrap this thing in a Component. We're going to create a reusable Component somebody else can just use. We'll create a profile-card element. Inside of the elements template, I'm just going to drop in all that markup that I had before. So now this thing's encapsulated in Shadow DOM. And the way somebody uses my element, they declare a profile card. And they get my name, and my image, and my title. And that's probably not something they want. So we can make this thing even better and make it composable. But the first thing we need, nobody's going to use our element unless it's styled really cool and looks great. So I went to Michigan. Go Blue, if anybody's out there that went to Michigan, as well. So I'm going to style my name and my title as maize and blue. So any time you put a style tag or a style sheet inside of your Shadow DOM, it's scoped to that element. So this is big, because it means styles from the page are not going to bleed in. You can see the h2 and h3 at the top of my slide here is not affecting the way my Component's h2 and h3 behave. And you can see that my maize and blue is not leaking out. It's not changing the two titles at the top. So we have scoping of CSS. This is really big. The next thing we can do is add a content div, add a wrapper. Now, this might not look that cool, but it's actually a really big deal. The fact that we have DOM scoping, we have a local DOM tree, as encapsulated by the Shadow DOM, means that we can use IDs again, willy-nilly. They're not going to conflict with the outside world. ID info is a really common ID, right? But we can use class names and IDs again because it's local to my Shadow DOM. And the last thing we can do is make this thing more composable. So what I've done in this step is I've actually removed the markup from my Component. And I'm saying, OK, I want users to be able to pass that data in to me. I want them to be able to configure their own title and their information. So what I've done was I've replaced that markup with a content tag. And a content tag is called an insertion point. And it basically just says, hey, this is a placeholder for rendering stuff from the user's world into my Shadow DOM world. And so what it's doing is actually taking that h2, h3, and the a tag, and it's rendering it at that location in the Shadow DOM. Now, something else I've done is I've leveraged Polymer's data binding features. So this profile card has this attribute's image on it. So it understands an image attribute when you put it on the profile card image. So I've kind of left the image itself as an implementation detail of the Component. But all users give to me is just a string with an image. It's super-easy to use. Now, for anybody that's paying attention, you've noticed a difference here, between this step and this step. I've lost my styling, right? I've lost that maize and blue that I worked so hard on. And so what we can do now is take advantage of some of Shadow DOM's new styling features. So there's this content pseudo-element. And this says, hey, if you're in h2 and you're going through a content tag, style yourself blue. So that's how I can regain those styles back. The reason for the difference is that my selectors in my style DOM style sheet no longer affect the stuff in the user line. So I actually have to care about that and bring that in. Because they're logically in a different place. They're not part of my local DOM. So this is how we can get composability and DOM scoping and CSS scoping with Shadow DOM. The last one of the four Web Component standards is HTML imports. And what this brings is loading and dependency management to Web Components. If you take an example like Bootstrap today, you have to do a bunch of stuff to use Bootstrap. So bootstrap.css. You load the style sheet. You're going to load in a font icon. JQuery is a dependency that you have to load in order to use the widgets for Bootstrap. You load, of course, Bootstrap itself. And then anything that you're going to use in order to put on your page, all their widgets. In the world of Web Components, in the world of HTML imports, this becomes a single line. So we can wrap all that stuff up in a single bootstrap.html file, link rel="import". And then that's how somebody brings in Bootstrap to their application. Imports actually changes the way we develop for the web. Instead of going off and finding API documentation and piecing stuff together, the first thing we can do is say, hey, does something else out there exist that solves our problem? We'll go off and find it. Second is import it. Once we have found something that's useful to us, let's import that to our application. And third is we just use it, right? We declare on our page we're creating JavaScript. And we just start using the stuff. So what do I mean by find? You go up to a registry. You go up to customelements.io. You go up to Polymer's catalog or some other catalog. And you say, hey, I want a core-toolbar. I want to put a toolbar on my page. I want a core-icon-button, for people to be able to push these awesome buttons. So you use a tool like bower, or something similar, to install that and bring that down to your application. So you go off and find something. The next thing is you use an import to import it into your app. In the head of your app, you'll declare an HTML import for a core-toolbar. And you'll bring in the core-icon-button, as well, using import. And the last step is just to use it. Right? You just declare core-toolbar on your page, once it's imported. And this is a composable element. So it understands core-icon-buttons. It understands spans with flex attributes on them. And what you get is a toolbar. No surprise there. But it's really cool, right? We're finding stuff. We're finding stuff that's reusable for our purposes. We're using it. We're bringing it in, using HTML imports. Imports are cool. Imports are really cool. So they give us a way to bundle related JavaScript, CSS, and HTML. So a lot of people say, hey, what about RequireJS? Or what about ES6 Module Loaders, or something like that? And those are all really awesome technologies. But right now, if we want to use JavaScript, HTML, and CSS, we're going to be writing Web Components that do that. We need a way to load all those resources, those different types of resources, together, in a single URL. And that's what, really, HTML imports is all about. It can also be used for dependency management. So the way Polymer kind of uses HTML imports is exactly like the native stuff. Exactly like the vanilla Web Component stuff. So typically, what we do is we say, hey, if you're creating an element, put that in a file. Put that in its own file. Call it menu-bar.html. And inside of that, you're going to define your element. So at the top of the file, you're going to actually use imports to load in the dependencies for your element. So we're creating a polymer-element here. That's the implementation of this element, this menu-bar element. So we'll load polymer.html as a dependency. We're going to load the paper-tabs and paper-tab element as a dependency. Because we're using those inside of our own Custom Element. You declare your element using polymer-element. And then the way somebody uses your stuff is, again, they just declare a link rel="import" to the menu bar file that you've created. And it's that easy. So you can have imports that reference other imports, and it becomes a dependency management. So that's a little bit about the four main specifications of Web Components. Now I'm going to switch gears and talk to you and start getting people thinking in Web Components. The first is that we have to actually think about what HTML even means. What does it do? So a lot of people see HTML, and they say, hey, there's all this visual stuff, right? This is stuff that renders to the browser. Your select tag. Your progress tag. A button, right? It has these amazing controls. You can declare an audio tag on the page. And you have all these amazing controls wrapped up inside of Shadow DOM. That's the UI side. But there's a whole other side, which is the non-visual elements. And Matt talked about this a little bit before. But I really want to drive home this point, because it's important. The non-visual elements provide utility. They do something, right? They exist there for a reason. But they don't actually render anything. So two of my favorite examples are the style and script tag. If you put text inside of a style tag, somehow the browser knows to throw that off to the CSS engine and use that for CSS. If you put text instead of a script tag, somehow the browser knows to throw that one off into the JavaScript engine and interpret that as JavaScript. I talked about template, right? Template's a new tag that we get with Web Components. What you put inside of the template is meaningful. And it does something interesting with that content. But it doesn't actually display anything. In the world of Custom Elements, we have the exact same thing. So Polymer has its set of core, non-visual elements-- things for loading libraries, and working with local storage, and doing things like selection. We have a set of visual elements. So these are things like, hey, I need an infinite scroll list. I need a scaffold for my mobile application, or a toolbar, or an icon. We have the highly visual and highly interactive material elements that Rob Dodson is going to talk about more to you in a bit. But I just want to show these. These are actually really awesome. They have all these really great effects. You just declare these on your page, and you go. They're responsive. They're accessible. This one's really fun, because it's got a little penny guy. Whee. So you get shadows. You get effects. The input's really cool. A lot of people think Shadow DOM is this encapsulated security boundary, like Matt said. I just want to point out that using Shadow DOM styling features, you can actually drill in. If we have a theme that we want to apply these elements, or these Components, you can do that using Shadow DOM. So now I've gone to Batman mode. So all of my ink affects are now these awesome orange. And everything is kind of fitting the look and feel that I desire. So that's just using Shadow DOM styling features. When thinking Components, we actually have to think about how we interact with APIs, libraries, and services again. So what I mean by this is if you take the example of Google Maps. Google Maps is one of my favorite APIs. It's very rich. And you can do a lot of interesting things with it. The hello, world for just throwing a marker at the current user's location, onto a map, is actually a bit of a boilerplate code that you have to write. So a little bit of CSS. You have to have a map container. You have to load the JavaScript library. You have to do geolocation to get the current user's location. Add a marker. Add an eventListener for the Info window. You have to wait for the map ready callback to fire. Duh-duh-dzz. It's actually a lot of stuff, just to render a marker to the map. It's a lot of stuff. In the world of Web Components, this becomes a single tag. I'm going to switch over here. [APPLAUSE] A single tag that doesn't actually render a map. [LAUGHTER] Hold your horses. A-ha. So you declare the Google map element on your tag. And voila, you get a map, exactly as you expect, right? You don't have to know to style the map using CSS. You don't have to have a div container. You don't have to load the library. You just compose it on your page, and you're off to the races. Super declarative. Maps is a really rich API. It has things that are valuable to us, like centering the map using a latitude and longitude. In the world of Web Components, we can expose that functionality of that Library API as a declarative attribute on the element. So I can center the map. I can center this map using a latitude and longitude attribute. I can set its zoom level using an attribute. And underneath, the implementation of this is totally transparent to me. But it's calling the Maps API under the hood. But as a user of this element, as a Component, I don't care about that, right? I just care about declaring this. And I get a map. Exactly what I want. We can make this element composable, using Shadow DOM Custom Elements. Inside of the google-map tag, I can put google-map-marker elements. And those are meaningful to this map tag. So if you put those inside of this tag, it renders a marker to the map, exactly as you'd expect. The other cool thing about this is I'm reusing parts of the platform that exist. Again, since I'm tied in to HTML, since I'm tied in to DOM, I don't have to reinvent the title attribute. And you can see the marker, it says, "Home." I don't have to reinvent the HTML5 drag-and-drop API. If I call draggable="true" in my element, the underlying Maps API call is made to make that element draggable. I can make the map marker itself composable. So if I put stuff inside of it, if I put an h2 in an image tag, that can be part of the Info window for the marker. And so that's what this element does with that information. So this thing is now growing as an application, just by composing the elements together. Another really common thing to do in the Maps API is say, hey, I want to fit all of the markers on screen that I have on my map. And so you have to know a little bit of JavaScript to do that. You have to loop through all of your map markers and set the bounding box on them. In the world of Web Components, we can expose that API call as a single attribute, the fittomarkers attribute on this tag. And when you have that, any time you add an extra element to the map, the map just knows, under the hood, to set the right zoom level. So this is really cool, right? That application's entirely readable. This is an awesome future of using Web Components with libraries and services. If you care about the example I showed before, I didn't actually show you the Geolocation API in that last step. This is the world of Polymer, using the same example. Instead of all that boilerplate code, it simply drops down to a couple of elements. And we're using Polymer's data binding feature here, to tie in all the latitude and longitudes together. And I can tie-in a paper-slider element to set the zoom level and zoom this map. So there's no JavaScript that this is running. It's literally just declaratively tying these things together. Google has 250 plus APIs. That's crazy. It's crazy awesome. So we've been actually thinking, on the Polymer team, how do we bring the best of Google's awesome sauce to the world, this declarative, amazing world of web development using Web Components, and vice versa? So we actually started a project on GitHub. If you want to check it out, googlewebcomponents.github.io. There's a lot of really cool things here. So we have Components for things like Google Maps, working with Google Spreadsheets, working with OAuth, doing Street View. We have a component for Analytics that allows you to declaratively create a dashboard, just by declaring a couple Analytics charts. Awesome. We have an element for creating Google Cloud Compute VM instances in the Cloud. You declare this element on your page. And you create a VM instance in the Cloud. It's crazy awesome. But it shows you the power of this stuff. This collection is growing. It's probably buggy. Feel free to submit pull requests and ask for more Components. We're happy to take them. So do we need Web Components? Yes. We need Web Components. Web Components are totally cool. I hope by now you've seen, sort of, where this stuff is going. They bring a lot to the table. So productivity, we can be productive. We can rapidly develop stuff, just by reusing what somebody else has built for us and iterating on top of that. We can be declarative, right? Just declare stuff on your page and go. Markup is meaningful, again. It's composable. So we can compose applications using smaller chunks, using Shadow DOM. It's maintainable. This is big. I can read Gmail source one day and actually know what's going on just by reading that stuff. It's reusable. I can find, I can import, and I can use an element and just reuse it in my app. Extensible. Right? We have a common way now, with Custom Elements, to extend Components. Other people's stuff. Or extend what the platform gives us, like an h1 tag, or a div tag. Scoping. This is a really big one for Shadow DOM. What Shadow DOM brings to the table is DOM and CSS scoping. Our styles don't leak out. Our DOM is all local. And it's a per-element API. So Custom Elements. You're defining your Elements API. The prototype, the JavaScript-- all that stuff goes just on the element. It doesn't leak into this global world. It's interoperable. We're at the browser's lowest level, which is DOM. And you get access for the tools. And the last one is accessibility, which is on by default. So before I leave you guys, I want to leave you with this quote, this awesome quote by Dimitri, again. He said that, "Custom Elements is a bedrock API. We should be able to build all HTML elements with it." So that's crazy. Can we build all of HTML with the technologies that we're adding to the platform for Web Components? The answer is yes. We can get very far. So over a holiday break, I actually experimented with this. I implemented the select element using Polymer and Web Components, using Shadow DOM styling features, using encapsulation, DOM scoping. And you can see the Polymer version at the top here. I don't want to bump it up, because it'll totally mess it up. So you can see the Shadow DOM, right? You can have a little overlay, and it behaves exactly like the native version of select, which is this little overlay. You could select different properties. You can change the multiple attribute on this element. And it has multi-select now. Right? So the really cool thing about this is you can't tell the difference between the two. Right? We can implement HTML using the low-level primitives that the Web Component APIs give us. That's what I wanted to show. So my question to you, my thought experiment to you, is, hey, what if the entire web platform was hosted on GitHub? What if the browser didn't ship all these native tags by default? What if you had to go find, import, and use those tags? Bring them in using bower and other tools? And you said, hey, I want to use an h1. I'll go off and get that. I want to use a marquee tag. I want to go get that. Maybe not a marquee tag, but. This is a really kind of cool and mind-bending experiment. But there actually is some folks on GitHub who are experimenting with this. They're seeing, can we implement all of HTML's cool stuff, using just the primitives of Web Components? It's really amazing stuff. So if you want to know more about Polymer, you want to learn more about Web Components, check out polymer-project.org. There's a lot of great tutorials and information there. [MUSIC - TEGAN AND SARA AND THE LONELY ISLAND, "EVERYTHING IS AWESOME!!!"] Components are the building blocks. So I implore you to go off and try them. Please don't get left behind. This is a fundamental shift for web development. It's a really exciting one. It's a great time to be a web developer. It's a bullet train, too, so it's speeding away. So make sure you're on that. Feel free to give me feedback on this presentation. I really thank you guys for your time. The presentation is up at this URL here. And if you want to tweet at me or see the code on GitHub, those links are there, too.