 Hey, everyone. My name's Steve Vorval. I'm an engineer on the Polymer team. And we're here to talk about the next generation of Polymer elements, like Matt said. We're still pretty early in this process, but we're iterating pretty quickly, as I hope you'll see. So it's this kind of reusable elements that we're talking about. They're used in almost every app. And we have a pretty large catalog of them that we've published on the Polymer project. They've been out for a while, a couple years, since Polymer 1. So we've been asking ourselves, what needs improvement? Matt gave you a preview of that. And luckily, we've gotten a ton of feedback from our users, both inside and outside of Google. And YouTube's built a whole application with Polymer. They've asked us to make elements faster. People come to YouTube to watch videos. So we make Polymer faster. That will make YouTube better. The Chrome Settings UI is built with Polymer. And they've actually asked us to make Polymer elements smaller, which is kind of crazy, since you don't actually have to download them to load the Settings page in Chrome. But they do have to download with the Chrome app. So they told us, if you make Polymer elements smaller, it'll make Chrome download faster and users like that. And our own team has asked us to make elements easier to maintain. They've specifically voiced concerns about our behavior system that we had in Polymer 1 that was a little bit cumbersome to use and a little bit hard to make maintainable code with. So they asked us to work on that. And of course, all of our users always want a lot more features. We've gotten a ton of GitHub issues on that. And we actually know that all of our users actually want all of these things. They want elements to be faster, smaller, easier to maintain, and have more features too. Size is especially critical if you're making PWAs that need to load on slow 3G networks. Of course, you need things to be as small as possible. So we thought about all of this feedback when we were designing Polymer 2. And we realized that the needs of these reusable elements, like inputs and checkboxes and buttons, are really not the same as the kinds of elements you're making when you're making big applications. When you're making these application views, you're concerned really with getting data from a server and transforming it to the UI, managing those complex interactions. And you really want the ergonomics of that experience to be good. When you're making reusable elements, you're concerned more with size and speed and look and feel. So we realized that one size does not fit all in Polymer 2. We decided to throw out our behavior system in Polymer 1. And in Polymer 2, you really embrace the new features in JavaScript, classes, and mixins. And this would allow us to make Polymer 2 modular, pay for play so that features are there only if you need them. And that would allow us to hit more of these use cases more optimally. So we did this for Polymer, but the existing set of elements we've made, what we call hybrid elements, and these are really a bridge to the future. We really haven't addressed the feedback we've gotten in these elements. They're there really to let you transition from Polymer 1 to Polymer 2 seamlessly. So with that in mind, we're now starting to think about what it means to make that next generation of elements where we can start addressing that feedback. So we're just going to take a look at some of the topics that we're thinking about. And you're going to get an early peek at that. So first, we're going to look at addressing that feedback that we've gotten to make things smaller and faster really directly. Then we're going to look at using extension, which is a new feature in Polymer 2, and what that means for elements. And finally, we're going to dive into some improvements that are coming in the platform around styling. All right, so let's start. And we'll look at making elements smaller and faster. And to do so, we're going to go ahead and remake an old friend of ours, PaperInput. Inputs are used in almost every web application, so if we can make a small, fast one, that'll be great. This one has this material design look and feel, has that animation, that validation effect with a customizable message. And of course, we know we need all of the native features from the input element, accessibility, all of the types, and all of that. So as we want to remake this to make it smaller and faster, we need to ask ourselves, what's the minimum that we need? And we'll start by making a base class. And we can use this for this input element, and then maybe for some other elements too. So let's go back to the modular design of Polymer 2. We build on top of HTML element. And we have a number of mix-ins here. Property accessors exposes, helps us manage getters and setters, and react to properties changes. Template stamp helps you stamp a template. Property effects gives you data binding, and we wrap it all together in Polymer Element, which we think is actually pretty good for building these application view elements. It's just about 12k minified in GZIPT. And that's actually a pretty good trade-off here. But when we're making a really small and fast element, it's a lot more than we need. So we're going to actually go down to property accessors and use that. And that's actually just 2k out of the box. So it's going to really help us with making the element really small. To make it fast, we'll go ahead and just use this mantra, do less and be lazy. We want to do as little as work as possible to render the element, and then do work lazily only as the user needs it. So the last two slides were actually from previous talks that have been given. At Google I.O. this year, Monica gave a talk, Polymer Billion Serve Lessons Learned, all about the modular design of Polymer 2. And I gave a talk last year. You can see my standard uniform, which has all about practical performance patterns you can use with Polymer. All right, so let's dive in a little bit to property accessors and see what it gives us out of the box. So it helps us make accessors, which are getters and setters, where we can react to changes when properties are set. It also helps synchronize with attributes, which is important when we are using HTML. It has a explicit API for turning on the system called Enable Properties. And that's there to better integrate with the boot up process as a custom element comes in. We take those attributes and reflect them to properties and we're able to process that as one set of changes, which is more efficient. It also triggers the ready method, which is lifecycle method that we add to allow us to do one-time initialization work. And finally, we have an entry point called Properties Change, which allows us to react to this batched set of properties changing. And in Polymer element, this is implemented for us. And this is where we get data binding and property observers and things like that. But in this element, we'll go ahead and implement this and do the work that we need when properties change to update our rendering. All right, so now that we understand property accessors, let's go ahead and build a little base class on top of it that we can use to make our paper input replacement. We'll just call it Simple Element. We're just kind of experimenting, so that sounds good. And the code is just going to take HTML element, apply the property accessors mix in. It's going to call Enable Properties. At the connected callback is a good time to do it to get that proper turn the system on. And then it'll define a template getter. And we'll use a string, which is going to work well for modules. This is something that is actually currently optional in Polymer element. And it's all that we'll support here. And then we'll implement the ready method and stamp the template into the shadow root, which is great for custom elements. We'll steal a feature from Polymer element, the this.$n node map for IDs in our template. And we'll do this because we're going to be working with those elements directly in this. And this is just so we don't have to find them. We'll call Super Ready. This is actually the easiest way to have a broken element is to forget to call Super. So definitely remember to do that. OK, so that's basically all we need to do to put into our base class property accessors. And then we made simple element. And then we'll make a thing called simple input. And this is just going to replace our paper input. So let's take a look at a few things about this. We'll look at what we call a decorator pattern that I'll explain in a second. Then we'll look at the template. And finally, we'll look at some of the code, specifically the ready method and the properties change method. So first, we're going to use an approach we call the decorator pattern. We're going to ask our user actually to put the input and the label in the light dom of the element. And this is actually a change. We didn't do this in paper input. And it was a big pain. And the reason is because if we put the input in the shadow dom, and we want to customize or expose all the power of the input element, we have to forward all that information. It's a lot of complexity to manage. And it's not a good trade-off. So if we use what we call the decorator pattern here, it makes the element a lot simpler. And we get all of that native accessibility and the type capability of the input out of the box. All right, so let's define the template. And we have some styling. This is kind of the minimum that we could do to get that material design look and feel. I won't bother you with that since you're all CSS gurus. We have a slot for the input, which allows us to project from the light dom into our shadow root, a slot for the label, and then some non-semantic nodes that we get out of the way. And here we have an underline node that helps us manage that animation. And that's really all there is to it. All right, so let's look at the ready method. Again, this is sort of our boot up work. And since we're using a simple element, we call super ready, which is where we stamp the template. This is going to happen before the element gets rendered. So that's fine, but we have to be aware of that work since we want to make our element fast. And so anything else we're going to do, we're going to do after the first render of the element. We set up that CSS so the initial render is free. We don't have to do anything to get it to show right. And then after the render, we're going to immediately find the input in the light dom, just using some shadow dom API to do that. And then just add a couple of event listeners and use a private property here to track the focus state. And I do a little bit more for the label too. And that's really all we need to do in ready for that setup work. And then we're going to go ahead and implement properties change where we'll react to those properties being set, like focused and a couple others. And basically we'll be manipulating the dom directly. Here I'm just going to add a class to that underline element just to tell whether or not the element is focused and that'll manage the animation. We do a little bit more of this for the label in the error message and we get this, which is hopefully looks almost exactly the same as the paper input. Material design look and feel has a little validation guy and it's looking pretty good. So how do we do on size and speed? Well, pretty good. It's just a little over 3K using property accessors, the little base class that we used and then the code that we had for the simple input. And now compared to paper input, which is a hybrid element, which means it really is not leveraging Polymer 2's modular design and has all of the legacy API from Polymer 1. It's actually 10 times smaller, so that's a huge improvement. And by using the decorator pattern and cutting out some of the features, we made it five times faster to render, which is again a pretty humongous improvement. But of course we know from our feedback that the features that we eliminated, users are going to want. So what are we going to do about that? Well, let's move to our next topic, which is extension and see if this will help us at all. So extending elements, as I mentioned, is sort of a new feature for Polymer 2 and we just get to rely on JavaScript for doing this. And here's some things to kind of keep in mind as you're using extension and making elements. And the first is to keep our base classes simple. We kind of did that with simple element and simple input, so that's good. Using extension to add features, that's kind of an answer to how we're going to deal with those missing features that we didn't support in paper input yet. And then importantly, if we can design our base classes with extensibility in mind, at least in the sort of obvious ways that we can anticipate, this is going to make it much easier for us as we extend them. So as I said, JavaScript classes really give us a lot of help with extending elements because it's native now and that's great. But when we were kind of designing this, we were thinking about what about the templates? Especially when we're defining those templates at HTML, we were kind of concerned that we might need a system to help us do the kinds of things you want to do when you're extending elements. But if we're using modules, specifically if we're using those JavaScript string template literal to define a template, then that might actually change things. So we want to investigate that. And specifically we want to look at two use cases. The first is you're making a subclass of an element and you want to wrap some content around the superclass template. That's a common use case. And then the other common use case is we're making a subclass of an element and it wants to insert some content somewhere in the middle of the superclass template. And hopefully we want to do this in such a way that we don't have to copy and paste the entire superclass template. So let's take a look at both of those use cases really quickly. And this is just a contrived example so we can kind of see what's going on. Just a simple element that asks how do you feel and then has a little input to respond. Now if we make a subclass of this, we'll define the template here and just use a string template literal and the native syntax here to refer to the super template. We get that kind of for free. And then if we want to do the wrapping, we can just go ahead and insert the content like that. Adding a header there and then adding another question. Kind of get that for free, so that seems pretty good. But now let's go ahead and say, what if we wanted to subclass this? We realized that the way that we've organized this here, well, there's a header and then there's some sort of list of questions. Can we make, can we design this element to make it better as a, you know, better to subclass, easier to subclass? So if instead we have a template for the header and we expose that, then now we've created an override point that a subclass can customize. If we do see the same thing for the questions, then you can see that we've added very little to our base class here and the rendering is exactly the same. But if we want to subclass the element and make it look like this with a different header and maybe a couple other questions, then all we need to do is override the header template like that and the questions template like that. It's just that easy. So we can kind of see that extending templates when we're using those string template literals is possible to do a lot without a system, especially as I said, using those string template literals and using classes and mix-ins for polymorphism, just like we saw. So how can we apply any of this to the simple input element? Let's go back to the template. And we know from our experience with paper input that people want to do a lot of customization with how the input looks in the material design look and feel there. They want to add icons to the beginning of it, maybe icons to the end of it. And we could add a lot of complexity to our base class to support all of those needs or we could just expose an override point for the input template. And that adds a very minimal footprint to our base class but it's going to expose a lot of power as we subclass the element. For example, if we make something like this, a credit card input, to make sort of show a credit card after the input, we could customize that input template, add some styling, call super, add a little icon for the credit card. And then it would look like that. Obviously we want to do a little bit more to make a full credit card input, maybe restricted to numbers and validate the credit card but our subclass gave us a nice helping hand and it was really useful. So we're really excited about leveraging extension to build new elements. And we know this because it's going to help us factor our code better. If we factor our code better, it's going to be easier to maintain. It's easier to maintain. We're going to have more time to add features and we're going to have a good helping hand there to address some of that core feedback that we've gotten. All right, so we'll move on to our last topic which is some changes that are coming to styling. So you might ask why we're talking about styling. Isn't this a solve problem with web components? We have ShadowDom which helps us encapsulate styling, preventing styles leaking into or out of our elements. And we know that that encapsulation is intention with theming which is a more global concern. But we have an answer for that which is CSS custom properties natively available on all major browsers now. They naturally flow down through the ShadowDom boundary where we can use them in our custom elements if we want to. And let's sort of sketch this out a little bit so we understand it. So I didn't show this but here's a little custom property that we can set here in a content view that might have one of those simple input elements in it. And then that CSS that I didn't show in the simple input we might use a custom property like this where we say, okay, we're going to default that underlying color to navy but we'll make it setable in this case that it's going to be orange. And that's all we need to do to expose that color to be themeable to the outside world of our element. And that works great. And we also had in the styling here in the simple input a little bit of opacity and that was just the designer said that was there to make it look good. But then we might have a user that says like, oh, you know that opacity I want to be able to set that too. So now we actually have a little bit of a problem and that is because we could expose a property for the opacity but then the user might want to make the padding different or any of the other hundreds of properties in CSS. We have a scaling problem with custom properties like this. So there's something missing here and on the Polymer team we helped propose AdApply which a lot of you may be familiar with as an extension to custom properties. And we worked with Tab Atkins who is a CSS spec guru that works at Google and he told us he actually put whatever information you want as a custom property and here we're putting the opacity for the underline but we need a way to make that go at the spot in the custom element and that's where AdApply came in. If we changed our variable name to match here then all of those properties could be applied at this spot in the custom element and this would totally solve our scaling problem. So we see we have a pretty good story with styling with Shatterdown for Encapsulation and custom properties for theming but AdApply is a really important piece of that puzzle to solve that scaling problem. So I have some good news and a little bit of bad news and then some more good news. So first the good news. Although AdApply is not standard in any browsers today we have a shim in Polymer that's been around since Polymer 1 and carried forward to Polymer 2 and is used out of the box in all of those hybrid elements. Along with the sort of spirit of the modular design of Polymer 2 it's an opt-in feature that you can load with the apply shim. But now the bad news it's looking like AdApply is probably not going to make it into native implementation in browsers and the reasons are complicated. There's some issues with nesting there's some issues with how it integrates with what are called pseudo classes like colon focus, colon hover didn't really play nicely together and this is a link to Tab Atkins blog where he has all the gory details and a lot more information about that if you're interested. But back to some good news. Tab and crew in the CSS working group have a better alternative and that's part and theme. So why is it better? It's actually kind of how the platform itself accomplishes this type of theming as we'll see in a second. And it's also a revival of a previous proposal from a couple years ago but the issues with that earlier proposal have been addressed. So let's take a look at that really quickly. So this is a native input element and it has an attribute called placeholder which probably a lot of you are familiar with. It controls what's gonna be shown in the input if there's no value there. And when this was out of the platform of course users immediately said well I gotta style that I wanna style what that looks like. And the platform answer is what's called pseudo elements and they have this colon, colon syntax here and you can see it's sort of similar to ad apply you can specify a whole set of properties here and that's gonna customize how the placeholder looks in this case it'll be orange and centered. So that's how the platform does it with pseudo elements and a custom element with this new proposal would do it like this. Here's a slider element and it's shadow root I can expose these pseudo elements by specifying part attributes. So I make the slider have a track and thumb that's styleable, demable. And then users would be able to target these elements these pseudo elements like this with that same colon, colon syntax now with part and then the name of the part in parens. And so this kind of solves some of the same problems as ad apply so that's looking good. It works better with pseudo classes so that's great. But notice one issue which is we had to be able to target the slider element it had to be that element had to be in our shadow root in order to style its part. We can't do it from outside so it's not great for theming where theming is more of a global question. This is actually the fundamental problem with the earlier proposal for part. It didn't support this kind of composition. So the new proposal has an answer and that is forwarding. So here is kind of a crazy syntax that may change it's a little early still but using this fat arrow I can say users of my content view element here can style this slider's thumb by this new name here slider one thumb. And it's comma separated I could do the same thing for the track but we also have a catch all that's proposed here and that would expose all the parts with the prefix or suffix. And then from say that content view element was in some my app element I can target that exact slider's part there with a slider one thumb and it'll go and make that one blue. So that's actually pretty powerful. Looking good for theming. There's of course probably the more savvy of you are figuring that okay well that looks a little cumbersome I gotta forward all that information. And that's good that's explicit. That's probably what you wanna do most of the time but there's an answer for if maybe you can't do that all the time and that's colon theme colon colon theme. It avoids this need to be required to forward everything. So if we use colon colon theme then that part name will be targetable anywhere in the shadow root of the my app element even in shadow roots in elements inside of it. So how might we use this in our simple input example that we've kind of been going through? Well let's go back to the template and look at that div that we had here that was for that underlying animation that users wanted to apply that styling to that we used at apply for. We can just add a part and that's all you need to do. So that's actually looking pretty good and promising. So part and theme were proposed earlier this year at the CSS working group meeting. There's a lot of enthusiasm for it because again as I said it's kind of how the platform itself accomplishes this same goal. And tab is currently fleshing out this back. You can have input on it if you want. We're actually right now in the process of sort of thinking about what this means and when this is gonna come actually natively in the platform which we think is at least a year or two out and how we might make a shim for this in the meantime. And so then if we kind of zoom out again and go back to the feedback that we had at the beginning here, making elements faster, smaller, easier to maintain and add more features. We kind of think that if we make things sort of along the lines of that simple input using extension, adapting to the platform as we need, squint a little bit that we actually might have made a lot of progress towards that. So let me now go back to the sort of demo that I showed at the beginning here and this actually is not it. This is a new version that's sort of, we've been prototyping with some elements made sort of along the same lines as that simple input element. You can see that there's some missing stuff yet. It's not all there, but the old version was built with hybrid elements and it's actually a lot of code. It's bringing along all that Polymer One legacy API and it's more than 100K. The new version so far, again, not done, is just 6K. So that's actually a ton better and we're really happy with that. So there's still a ton of work to do, still early, but we're iterating pretty quickly and that's all I have. So thank you.