 All right. Hello, everyone. Thank you for coming out. We have a jam-packed talk for you. So let's get started. My name is Kevin Schauff, and I'm Steve Orville, and we're both lead engineers on the Polymer Library, and we also do a lot of coordinating and planning on the project as a whole. So the two of us spend a lot of time together. Yeah, in fact, we work so closely together that instead of calling us Steve and Kevin, some people just call us Steven. Yeah, we're kind of interchangeable like that, although Steve is the one who talks like way too much and uses all kinds of crazy analogies that don't make any sense, goes on and on and on. Yeah, well this guy, he doesn't even like science fiction, so it's impossible to find an analogy that even understands. All right, all right. Well today, in this talk, we're going to go through where we're at with web components and the Polymer Library. And then we're going to cover where we're taking the Polymer project in the future. And then finally, we're going to talk about where we're going to help evolve the web platform forward and make it even better for us developers. All right, so let's talk a bit about web components and Polymer. The Polymer project started as an experiment to embed web developers right inside the Chrome team. And the goal was to tighten the feedback loop between developers building on the web and engineers implementing the browsers. So the experiment turned into a full-fledged project focused on identifying developer needs and participating in the standard process to address those needs and bring them to the browser. We also produced polyfills in libraries to encourage the use of these new features, all with the goal of driving the web platform forward to make it more capable for us developers so that we can all deliver better experiences to our users. This all started almost six years ago now, when Alex Kamarowski and Dmitry Gloskov got up here at Google I O in 2012 and they talked about how web development at that time was really difficult. It was overwhelming how how much developers had to work around the limitations in the platform and write a lot of code for really basic concepts like breaking down your application into components. They did this whole shtick about how they were these engineers coming back from the future and they were coming back to report that all these problems were solved and that the web platform had become a really awesome capable platform for building applications. They told us about these new things called web components, native web platform APIs that help us create components for structuring our applications and building reusable widgets and the components were built on a handful of new features in the browser. The first feature they told us about was custom elements, which let us extend HTML and make our own elements work the same way that the browser's built-in ones do like inputs and buttons and this meant custom elements would work anywhere the web works regardless of how you're building your app. Next, Shadow DOM let custom elements hide the rendering so that you could create complex UI in a component that was fully encapsulated, including its styling. So you no longer had to contend with this global soup of CSS and come up with conventions on your team to avoid stomping on each other selectors, that sort of thing. And last they proposed a new way to load those custom element definitions called HTML imports and the rendering for your component would just be described declaratively in HTML and then loaded and parsed natively by the browser. Dimitri and Alex put all these things together into this awesome story about an amazing future where you could mix and match components from different authors on the same page. And this was because the rules for coordination were no longer convention that everyone had to agree on. They were built into the browser. And that would allow an ecosystem of interoperable widget libraries, meaning everyone could stop reinventing that same date picker component over and over again. And since web components were built on top of HTML, we got a declarative format for describing components for free. Yeah, that sounded like a really awesome future six years ago when they told us about it. So what's happened since then? Well, it's been a bit of a long road, but web components became a real thing. And frankly, most of what they predicted actually became true. The vast majority of web users have native web components running on their devices right now. Every one of you has a phone that runs native web components. It's true. Yeah, there's a thriving ecosystem of components on webcomponents.org. And most obviously frameworks today work great with web components, as you can see on custom elements everywhere, a site that tracks framework compatibility with custom elements. So the promise of one component model that works everywhere really has come true. And of course, lots of developers are already reaping all of the benefits that Dimitri and Alex talked about. There's a lot of big sites right here within Google that are all in on web components. And awesome companies like Electronic Arts, Coca-Cola and USA Today are using web components to ship really great experiences. And those Google companies, you better tell us what those are. Right, so YouTube, Chrome and Google Earth are all in on web components. So all of these brands and sites have invested in web components to help them reach users on every corner of the earth. And that's the amazing thing about the web. It's what gets Steve and I out of bed in the morning. It's the fact that it's this one platform that reaches every user on the earth. So a ton of people are using web components in that future that Dimitri and Alex talked about back in 2012 really has come true. OK, but really has it, I mean, while it is true that a ton of people are using web components, not everyone is. And if they're truly as revolutionary as they seem, why is it like absolutely everyone using them, like every single website? OK, so to explain that, let's pause for a second and talk about this concept we have on the Polymer team called a weirdness budget. Right, so when you're learning something new, there's really only so many kind of weird new concepts you can deal with at one time. If there's too many things that really aren't compatible with your way of thinking or way of doing something, it starts to feel kind of unwieldy and confusing and you're likely to just punt on the whole idea. So take the electric car for an example, right? So the novel new thing about the electric car is that you never need to go to the gas station, you just have to learn one new thing. You have to learn to plug it in at night. That's it. But in addition to that, say the car had a bunch of other weird things about it, like only three wheels and funky doors and like only one seat. The novel benefit of not needing gas would be lost because of all the other weird things about it. Yeah, I'm not sure I'd buy that car. And sometimes that's how we feel it's been with Polymer and Web Components. While that original novel feature, that single standard interoperable component model has been really compelling and a ton of developers have been really successful using it. We think Web Components have been held back from their full potential because for some people, at least they've exceeded that weirdness budget a bit. So first and foremost were the polyfills. At the beginning, you needed polyfills to do anything with Web Components on every browser. And not just one polyfill, but a bunch of them, one for each big feature of Web Components. Yeah, and these weren't simple polyfills either. So I'm pretty fundamentally changed how the browser worked. So having to load polyfills just to do anything kind of felt weird. Yeah, and early on, using Polymer at least felt like the only way to build Web Components. And this was because those polyfills were pretty tightly coupled to Polymer. And that made it feel like using Web Components was just like styling yourself in another framework. Right, and the entire purpose of Web Components was to break down these silos so that you didn't have to be stuck in a silo when you chose a framework. Right, so being forced to or feeling like you were forced to use a library like Polymer just to use Web Components also kind of felt weird. And then when we started out on Web Components, a package manager called Bower was popular at the time and seemed like a natural fit for distributing client-side code. Right, but in the meantime, NPM has really become the de facto standard way to distribute JavaScript for both client and server code. And having to get your dependencies out of Bower became kind of a drag. Yeah, so having to deal with two package managers, NPM and Bower just also felt weird for developers. And then there is HTML imports, so it's a really good idea, but it never really panned out standards-wise. This is how those guys from the future envisioned we'd all load our Web Components with a platform-based loader for HTML, JavaScript, and CSS. But then once JavaScript modules started becoming popular, it became clear that we couldn't have two different loaders in the browser, one for HTML and one for JavaScript. And so over time, the HTML import spec was abandoned. And because of that, all of the standard tools that we all use, like bundlers and transpilers and editors, they never really adapted to dealing with HTML imports. Right, so over time, at least, using HTML imports also started to feel weird. So while Web Components have been objectively successful, there have been some legitimate reasons for developers to hold off using them. And that's been a big focus of the Polymer team over the last couple of years, to eliminate the weirdness around Web Components so that every Web application can start taking advantage of this standard interoperable component model. Right, so first let's take a look at the polyfills. Now the great news here is that you almost don't need them at all today. Last year, both Chrome and Safari shipped a standard version of custom elements in Shadow DOM. And now Firefox has implementations behind the flag and will ship pretty soon. So you need zero polyfills for both Chrome and Safari and soon Firefox. And for older browsers or other ones, the polyfills now use feature detection to load just what's needed. And then the other thing is that as a Polymer 2.0 release at last year's Google I.O., the polyfills are now totally separate from Polymer and work transparently behind the scenes. So now Polymer is just an implementation detail of your Web Component. Users of your component use it just like they would any other HTML element and don't need to know anything about Polymer, the way it was kind of always supposed to be. And today Web Components are made not just with Polymer. You can make Web Components with libraries like Angular and Ionic and Glimmer. And all of those components can work on the same page through the power of that interoperable component model. So we've come a pretty long way towards reducing that weirdness around using Web Components. But there's still these two other things that have made Web Components but with Polymer feel kind of weird. And that's been the focus of our team for around the past year. All right. And today we're excited to announce the release of Polymer 3.0. With Polymer 3.0 we're building Web Components built with Polymer into the mainstream. Now our boss Matt, who's right there, he really likes flames. He insists on putting them in every presentation so we slipped him in right there. Did you like the flamey Web Components? So the first big change in Polymer 3.0 is that the Polymer library and all of the elements we produce are now being published on NPM. So this means you'll just NPM install them like you do any other dependency in your project. No more contending with a different package manager just to use Polymer and Web Components. Next we're moving from HTML imports to JavaScript modules. And this is going to match how the mainstream of code is being written today in the community. But we're not just authoring in modules, we're also publishing our packages to NPM as JavaScript modules. And this is because as of today's release of Firefox 60, we just tested it this morning, the current version of every major browser natively supports loading JavaScript modules in the browser, all four of them. So native modules let you run the code that you write exactly as you wrote it, with no bundling or transpiling or source maps needed during development, which is an awesome productivity boost during development to just be able to load and refresh your code in the browser. Yeah, it's totally awesome. But there's just one thing we need to do to make this possible. And that's to convert the module specifiers we use to URLs, because the browser is really only to understand URLs. And the convention in NPM, and really the entire JavaScript ecosystem, is to load dependencies by package name, not by URL. And Polymer is going to follow this convention. We're not going to be weird there. So to make those imports loadable in the browser, we need to transform those module specifiers to URLs. Okay, so how do we do this? Well, we've updated the Polymer CLI tools to do just that simple transformation on your source code on the fly, from module specifiers using package names to URLs. So let's take a look at this in action. So here we're loading our shop demo app using the Polymer dev server. So during development, you're loading the exact same code that you wrote in your editor. All the same files right here, no bundling during development. The only change is that the server converts module specifiers from package names to URLs. So you see that there's top couple lines there. Those are converted on the fly to URLs. Which makes the debugging experience great. You can just edit and refresh. That break point right there is on the exact same line as it would be in our editor. So Polymer still ships with this great edit refresh development experience right out of the box. Right. Now, for those of you who really like developing in HTML, stay tuned because we're going to have more to say on that later in the talk. But, you know, the other benefit of this change moving from HTML imports to JavaScript modules is that code built with Polymer also just fits right into the other popular tools in the community. Tools that understand modules like TypeScript and Webpack and Rollup. And of course, you can continue to use the Polymer CLI. You can choose whatever tool works best for you and your team. So in Polymer 3.0, we've held the API stable and we focus on this format change from HTML imports and Bower to JavaScript modules and NPM. So Polymer 3.0 has all the same stuff as Polymer 2.0 just in a slightly different form. So let's take a look at what this change practically means. Up until now, in Polymer, we defined single file components using HTML. So first you import dependencies like the Polymer base class here. So we're using an HTML import, a link rel import tag to import that. And then you'd use a DOM module element to associate your templates class for your custom element with the template. And then you'd register the element with the browser using the native custom elements defined API. So this is what kind of a typical single file component looked like in Polymer 2.0 all in HTML. In Polymer 3.0, we're defining single file components using JavaScript instead of HTML. So to do that, you first just make a standard module. You import your dependencies directly from NPM using the browser's native import syntax. Define your class. That part's the same. But then here's a change. You implement a getter that returns your HTML template. And the change here is that you use this HTML function provided by Polymer to convert the string into the element that Polymer expects. Otherwise, the syntax hasn't changed. And we use the same platform API custom elements defined that we did before. And that's really all there is to it. Pretty standard, nothing weird here. All right. So this may sound like a big change, but providing our users a smooth migration path between major versions has always been a really strong focus on the Polymer project. And so again, I just want to reiterate, with Polymer 3.0, we've held the API stable and only focused on this format change from HTML imports in Bower to JavaScript modules in NPM. Yeah. And to help users migrate their existing code, we're providing a tool called the Polymer Modulizer. It converts HTML imports to JavaScript modules automatically and also generates the package JSON you need to install dependencies from NPM based on what you were previously using in Bower. OK. So that sounds like a tall order in automatic migration between two versions. So next, let's take a look at the Modulizer in action by going to our shop demo application that was written in HTML imports and convert that to modules. So this is the shop demo application. I'm going to reload it here in the browser. You can see in the DevTools, we're loading all of our components there using HTML imports. That's the 2.0 version. Right. So if we pull up the shop app, the main component for the application in our editor, you can see all the dependencies are being imported using HTML imports. The template is right there in the HTML. And then you can see that the class is extending from the Polymer element base class that's pulled directly off of the global because with HTML imports, we didn't have any scoping. Everything had to go onto the global. So now if we run the Modulizer command on our app, that's going to go through, convert all of those HTML files, read those in, output JavaScript modules in their place. So here we can open that same shop app component. You can see all the imports are now JavaScript module imports and the base class is being imported from the module that provides it. We're defining our class the same way. And then here's the template being encoded right there in JavaScript using the HTML function. As Steve said, the Modulizer also generates your package JSON based on all the dependencies you were previously using in Bower. So we can just go to the console here, npm install our new npm-based application, run the dev server. Now we switch back to the browser. I'm going to hit refresh right here. You'll see that automatically all of these modules have been converted. We're now loading them using the native module loader in the browser and everything basically works. There may be a few things that the Modulizer doesn't automatically convert still that you might have to hand tweak, but as you can see the majority of the migration work is automated. Yeah, so that's a pretty awesome tool. And we want to thank all of the users and companies in the community that helped us make that happen. And especially we want to give a big shout out to Vauden that helped us a lot. They have a widget set based using web components that's really great. You should definitely check that out. So Modulizer is available today on npm. It's still in pretty active development and it already automates most everything as you just saw, but there are a few things you need to do. You should definitely check it out and we'd love your feedback. And finally, along with this change, we've made sure that WebCommodus.org, the one-stop shop for the ecosystem of reusable web components, is being updated to host elements distributed via npm, was previously Bauer. And we're encouraging the entire community of Web Component developers to go through this migration to get them onto Bauer and Modules, the same as the rest of the community, and get them published on WebCommodus.org as well. So in this latest release, we really feel like we're removing all of the weirdness around using Polymer and Web Components. Using Polymer 3.0, you can build and distribute Web Components that are truly mainstream. And when you're building a Web application, using a Web Component is just like you would any other dependency. It'll fit seamlessly into your workflow. Polymer 3.0 and most of the custom elements that the Polymer team maintains are available today on npm. Install them just like any other npm dependency and you'll be off to the races. All right, so that's where we're at with Web Components and Polymer today. And that future that Dmitri and Alex talked about back in 2012 really is coming true. So where does that put us today with the Polymer project? Where do we go from here? Well, since we're holding the API stable in Polymer 3, as we said, that release is really mostly about getting our existing users kind of into the mainstream. But we've always really wanted Polymer to be just a really thin sprinkling of sugar over the native platform APIs. And having completed all that work, we're really returning to that core vision. So we've been working on a whole new generation of products that are thinner and lighter and more loosely coupled. And we see these as the future of the Polymer project. So let's take a look at what we've been working on. All right, so the first thing that we did is take a hard look at improving the base class that we use to make Web Components. So the rendering and data binding parts of Polymer's base class have really been unchanged since the 1.0 release a few years ago. And since then, we've had a lot of ideas kind of stacking up on how to make it smaller and use more platform features and focus on how developers are actually building applications today. So to do this, we separated out kind of the lowest part of the smallest part of the Polymer library. It's a roughly 2 kilobyte layer that lets you declare an element's property API and keep it in sync with its attributes and react to changes. And we really see this as a common substrate that any element needs regardless of what rendering model is being used. And then in place of Polymer's legacy template and data binding system, we layered on a new library called Lit HTML that we've been developing over the past year or so. Lit HTML is a lightweight rendering library based on JavaScript string literals and the platform's template elements. So we took those two platform features and kind of smooshed them together into this rendering library. It's less than 3 kilobytes today. But because it's based on new and some upcoming standards that we're going to talk about, even that can mostly melt away in the future. We're calling this new base class Lit element. So let's take a look at it in action. So we start by just making a standard JavaScript module. We import Lit element there from NPM using and its HTML tag. Then we use our standard pattern. We make a class that extends Lit element. We declare our elements property API. Here we're declaring a first, last, and type properties. Users can set those either as attributes and HTML or as properties in JavaScript. This is pretty similar to a Polymer element so far. Yeah. Then we use the render method. And this is where Lit element makes use of Lit HTML and its HTML function. It takes a string containing static HTML and embedded JavaScript expressions describing where the dynamic value should be set. Behind the scenes is converted to a template element with some information about where those dynamic spots are. Lit element renders this content to the element shadow DOM. And then that render method is actually called whenever any of the elements properties change. And Lit HTML behind the scene keeps things fast by ensuring that the static content is rendered only once and that the dynamic parts are updated just as needed. Finally, we call custom elements defined just like we always do. And that's all there is to it. So you may notice that this Lit element uses the functional reactive pattern. That was popularized by React and JSX. But since we're writing standard JavaScript here, the HTML function is a standard part of... We're using tag template literals, which is a standard part of the platform. So we have the full power of the language, but we don't have to compile the code to make it work in the browser. Right. And we see Lit element as a lightweight generation replacement for Polymer 3.0's Polymer element. It's just about five kilobytes. That's around a third the size, but it has just what you need for making elements that leverage unidirectional data flow. And because they're Web components, you can, of course, mix and match elements made with Lit element with elements you made with Polymer 3.0 or any other Web components. All right, both Lit HTML and Lit element are available today on NPM. And you can start using them. Okay, so with Lit element, we have a solid new base class for building custom elements and apps out of components. But when you're building a Web application, you don't want to have to build all the components yourself, right, Steve? No, that would be kind of crazy. So that brings us to our next new product, a new element set. So from the earliest days of the Polymer project, we've always provided a high quality library of UI components to help you get started building rich user interfaces out of Web components. And yesterday, Google announced a new iteration of material design here at I.O. It's focused on theme ability, and our team is making a new set of elements expressing this new design language called Material Web Components. These elements will be replacing the Polymer team's paper elements, which are based on an older version of the material design. Yeah, and for this new element set, we've teamed up with the material design engineering team here at Google that's in charge of supporting all of the platforms that Google builds for. And this is going to ensure that the new set is automatically kept in sync with the latest material design guidelines. So the new set is actually built using lid element that we just talked about. But again, that's just a implementation detail under the scenes. From the user's point of view, it's just a Web component. All right, we have a preview of the Material Web components available on GitHub today. Some of them are published now to NPM, but they're a work in progress, and we hope to iterate quickly and have them already very soon. Okay, so we have a solid new base class with lid element and a new element set with Material Web components. The last product ties all of these things together into the end-to-end app-building experience. And today we're announcing a new PWA starter kit. It has everything you need to build scalable, high-performance, progressive Web apps right out of the box using all of the latest platform features. So of course, we're using Web components for factoring the UI, and again, those are built using lid element, our new base class. It uses Service Worker for offline storage. It uses the purple pattern for efficiently serving your application, and we're integrating Redux for top-down scalable state management. The kit comes with several different starter templates and has tons of documentation for ramping up. There's zero config commands for building, unit testing, screen shot testing, and deploying, all that's included. So you can get going with the PWA starter kit by cloning that GitHub repo, and there's a whole wiki in there that tells you how to get started. But also, Monica and Dinkalescu from our team is going to be giving a whole talk on that coming up in just an hour after this talk at 3.30 on stage three. So you should definitely go check that out. She's an amazing speaker. All right, so to recap, we went over a lot pretty fast there. Polymer 3.0 is bringing the Polymer Web Components ecosystem into the mainstream. And with lid element, material Web components, and PWA starter kit, building Web applications with Web components is easier than ever. Okay, but remember, the Polymer project's mission is not just to build tools on top of the platform, but also to evolve the platform to make it more capable and ergonomic and help people solve real world problems. Okay, so we have 14 minutes and 37 seconds. We're going to finish up with a lightning round through a bunch of new platform APIs and features that the Polymer team is helping shape and providing feedback on in the standards process. Okay, here we go. All right, so first up, we have CSS Shadow Parts. This is a proposal that provides a first-class solution for theming Web components. So we've talked about how Shadow DOM provides styling encapsulation. It protects the inside and outside of the Shadow DOM from being accidentally styled. However, sometimes you want to style elements inside the Shadow DOM from the outside, and the classic case is applying themes. For example, you might want a button to have rounded corners or an input to look special when it's focused. And while you've previously been able to do this using CSS custom properties, that's kind of what we've done up until now. There wasn't that way to style any CSS property on an element in the Shadow root. You can only style the ones that you expose to the API. Right, and this is where CSS Shadow Parts comes in. So it's actually modeled on the way the platform already works. Let's take the native input element, for example. It has a placeholder attribute that shows a value when you haven't typed anything. It's usually used to tell the user what to type. So this is a nice feature, but often developers want to be able to style the placeholder to make it match the theme of their website, right? And what you may not know is that the native input is actually implemented in the browser using Shadow DOM. It's been running for years. And the rendering of the placeholder inside that element, that rendering, that says enter value, that's actually just an element in the native input Shadow DOM. And the platform exposes a special colon colon placeholder pseudo element in CSS that you can select on the input to style it, right? We can make it orange and centered. And we can do that without the input having to leak other implementation details of how it's implemented. We're trying to theme custom elements that use Shadow DOM. So let's say, for example, you have a slider element called My Slider. And you want to allow users to customize the way the thumb looks. That's the thing you drag left and right to set the value. So Shadow Parts introduces a new part syntax in CSS that we can use to select items in the Shadow root. So here we can select colon colon part on the My Slider and pass the thumb as the thing we want to select in there. And give it a custom style. So we can make the thumb orange if that's our theme for our website. And so this gives us the power to define pseudo elements for our own Webcommon just like the native platform has always done for its built-in elements. Right. And to do that, all the developer of that My Slider element needs to do to expose the thumb as a styleable pseudo element is to add a part attribute to the name you want, to that right DOM node in your Shadow root. So what's great about this is the developer decides exactly what styling is encapsulated in the Shadow DOM and what's themeable from the outside. So the CSS working group has already agreed to advance the syntax and it's being implemented in Chrome right now. And we really think that CSS Shadow Parts is going to unlock generalized theming for Webcommon. That's kind of been missing up until now. Yeah. You can go check out the drafts back here in Monica. Write up a really nice explainer on her blog about how CSS Shadow Parts is a big advancement for custom elements, which is the ability to scope new HTML tag names to a specific part of the page. So remember, custom elements allows us to associate a custom element class with a HTML tag name in the browser. Right. However, up until now, custom elements were defined globally for the entire page. Now, in practice, really this has been mostly fine, but it can sometimes be a problem. And to see how, let's walk through a little example real quick. So say you're on a big team building a big application and you're responsible for the contact view. You see, you find a fancy button component, think it'll be great, you put it in right there. So let's say that I'm on a different team and I'm responsible for the detail view and my team finds a different fancy button that looks awesome and I want to use it in my component and both of these components need to work in the same page. So since the fancy button tag name can only be associated with one class right now in custom elements, the browser won't actually let you define two elements with the same name. So both teams would have to, like, cooperate on picking the same fancy button or name it differently or something like that. Right. So let's take a look at how custom element registries will help us address that problem. So with the custom element registries you'll import the class that you want to use and then you'll make a new custom element registry. So previously there was just one of these globally. Then you can define that fancy-button tag name just in this registry, not the whole page. And then finally you'll tell a shadow route to use just this registry for its scoped tree. So this way the contact view and the detail view could each have their own registry allowing you to use that same fancy-button name but with different implementations on the same page. So we think this addition is really going to help large organizations managing a lot of complexity, a lot of dependencies in their application, adopt custom elements. The proposal got positive feedback at a recent W3C meeting this year and you can follow along on this GitHub issue and provide feedback on the issues linked here. And actually for all the things we're talking about go check out the issues and comment on them and give them your use cases and feedback. That'd be great. So with CSS shadow parts and custom element registries a couple of long-standing pain points are going to be addressed really nicely making web components easier to use. Next we'll look at a couple of features that will enhance the way that we load components in the browser. And first we have a new browser feature that will allow you to use the package name maps. And this will allow us to import JavaScript modules by name in addition to by URL. So as we mentioned earlier JavaScript modules can only really be loaded by URL since browsers only really understand URLs right now. But everyone uses package names. This provides a lot of flexibility like the ability for MPM to put the package just where it needs to be on disk. And frankly it's just more convenient. But again it means that you need some kind of a solution to do that. Can it be great if you didn't have to do that? Right. That's the one thing that the Polymer tools during development have to do is transform this. But that's where package name maps comes in. So package name maps introduces a new JSON format that will be understood by the browser that maps module package names to URLs that the browser can load. The idea is that this would be generated by your package manager like MPM or your CDN that's providing your modules and you'll just tell the browser where to load your package map. It might be something like this. The syntax is still kind of up in the air. But then you'll be able to use package names in all of your source code or your dependencies and have them load natively in the browser just the way you would in Node. So we're really excited about how this is going to remove the need to use tooling to load your source in the browser. And we also see this as a really big step forward in unifying the entire JavaScript community both front-end and server-side where packages can work out of the box in either context. There's an explainer for the proposal here on GitHub. You can go check it out again. Please provide your feedback. That's how this stuff gets done. So the next thing we're working on related to loading is HTML modules. So as we mentioned earlier HTML imports kind of failed to catch on mostly because they weren't designed to coordinate with the JavaScript module loader in the browser that started kind of emerging at the same time is actually now shipped everywhere. Right, but a lot of our users they really like using HTML to define components. And there's pretty broad agreement in the W3C that supporting HTML as a way to define components is still a really good idea. So we're helping to define a proposal for HTML modules. Now this is a way to load HTML but with the standard JavaScript module loader. The native module loader today only understands JavaScript. But if HTML modules are implemented that same loader would just be able to load HTML. And this really unlocks a lot of possibilities. The HTML could bring in the components template and then you could use it in a script please. Thank you. And that would be really easy. Use that template in your component just like that. Look a lot like HTML imports does today but you know natively with the JavaScript module loader then. Yeah. All right, so with HTML modules we're really helpful to get away to write single file components that leverages the native parser that keeps HTML and CSS in their native format without needing to encode them into JavaScript which feels kind of weird today. The proposal is being discussed on GitHub in this issue. We're still working out a lot of the details but we've also created an experimental tool that you can check out right now to help refine the design. It lets you write HTML modules in this speculative format and then applies a built-in transform to convert them into JavaScript modules that can be loaded natively in the browser. So if you're interested in this proposal or if you want to continue to write your components using HTML you should definitely check that out. Cool. All right, so package name maps and HTML modules are both going to make loading components in the browser a lot more convenient. And that brings us to the last new browser feature that we'll discuss and that's HTML template application. It's an extension to the existing template element but it adds API for updating dynamic parts of the DOM. So here's an example template with some static elements and you may not actually know this but cloning a template like that is the fastest way to create a tree of DOM. It's actually faster than creating elements imperatively like many libraries do. But in practice, of course, real applications need to update that DOM as well. So like in this case we probably wouldn't put that name in the last myth statically in a template like that, would we? Right, we'd probably fill that in from a variable that's loaded from a database or something and we might need to update that spot in the template later on. And really there's been no way to do this built into the browser. In fact, a lot of JavaScript libraries are focused on this one thing, like creating a tree of DOM and then updating it dynamically. So template instantiation provides a way to tell the native template element where the dynamic parts will be. So we'll be able to create a template part and attach it to a spot in the template to tell it where it can be updated. And so right here this is where we wanted to update the name. And that's the only part of this template that needs to be changed. Everything else is static and we can tell the browser about that ahead of time. And then once we've created parts in the template, there's a new API called create instance on the template element. And this will stamp a copy of the template, all of that static content into a thing that looks very similar to a document fragment that can be appended using the normal DOM APIs. But then the cool thing is that the instance also knows about where all the dynamic parts are in that template without having to walk through. We can just call get parts on the instance and then each part has a set value API that we can call to update that part of the DOM. And then finally you just call commit on the instance to apply a batch of changes all at once. This looks like a pretty low level API and it kind of seems like it's going to be used in library code. But let's take a look at what users are going to gain from adding this to the platform. So as we said earlier, it builds on top of the existing template element, which is already the fastest way to create a static chunk of DOM. But by adding this new part API, we think this will end up being the fastest way to update DOM as well. And this is because today, any library that deals with rendering has to locate these dynamic spots in the DOM manually each time you create an instance of the template. And if you're using the DOM library, those have to walk through what could be a pretty big chunk of static nodes just to find what needs updating. With template instantiations get parts API, you can just ask the browser for that list of spots that needs updating without needing the runtime overhead or the code to walk and find those spots. So another cool thing is that the API is proposed to have batched updates built in. So logic to update the dynamic parts of a template and a component could potentially be spread across multiple frames and committed in one batch. Which is really cool because a lot of frameworks are experimenting with this concept of spreading work out across multiple frames. So this feature is also being designed as low level flexible primitives that can be incorporated into as many frameworks as possible. For example, we think this will replace a large portion of what our new rendering library lit HTML implements make that faster. But the Angular team has also been involved in the feedback process for this spec and is interested in using template instantiation as well. Last while the initial proposal for template instantiation has an imperative API that we've seen, it also paves the way for a future declarative syntax for describing where those dynamic parts are just directly in the template's HTML. And that together with HTML modules unlocks a potential future where components could be defined completely declaratively. Which is pretty cool. So template instantiation promises to make rendering DOM a problem that every framework contends with faster, and with way less code. It's a really exciting proposal, started by Apple. It has strong support now from all the major browser vendors. It's still in very active development. You can check out the explainer shown there, and that issue there has some of the latest discussion. All right, so, you guys with us? All right, let's recap. All of these features that we talked about are going to help make the browser way more capable and easier to use. So CSS shadow parts and custom element features are a lot more robust. Package name maps and HTML modules let us load our source code with fewer tools. HTML modules and template instantiation unlock declarative component authoring. And template instantiation makes dynamic rendering way more performant. And if we take all of these features together, that means that we can rely more on the platform, more on the browser to get our job done and ship less code that has to run and be delivered over the network to our users. So as you can see, we have a pretty exciting next new round of features that will help evolve the platform and make it better. All right, that's it for everything happening on the Polymer project. So here are the main takeaways which you should learn from today. All right, so web components are now a standard part of the web platform that you can use in any app that you're making today. So if you're not using them or you haven't checked them out, now is the time. There's no excuse. Polymer 3.0 is out today. It provides a really smooth migration path for existing users to a more modern development workflow, authoring in JavaScript modules and using NPM for your dependencies. The Polymer project is moving forward with a new generation of products focused on improving the developer experience of building web apps with lit element, material web components and the PWA starter kit. And as you've just seen in that lightning round, we have a ton of great new platform features on the horizon that you can use to improve your experience even better. All right, again, I'm Stevan Shoff. And I'm Stevan Orval. Thanks a lot.