 Alright. Thanks, everyone. My name is Taylor Savage. Great intro. Yeah, my name is Taylor Savage. I'm a product manager here on Chrome on the Polymer project. I'm here with Monica, who's an engineer on the Polymer project as well, to tell you all things Polymer. So I'll start off by talking a little bit about where we are with the project overall and how we think that web components are really changing how we do web development. And then Monica will go into some of the more technical details around how to take best advantage of Polymer of web components to build a really great, high-quality, modern mobile progressive web app. But first off, let's talk about the mobile web. And we've been talking about the mobile web a lot at this conference. It's kind of like the mobile web conference. And there's good reason for that. The mobile web is incredible. There's never been a more important time to have an open, decentralized communication network where anyone in the world can access this information coming from anyone else in the world. And as developers, this is incredibly exciting. You can put something up on the web and a user somewhere halfway across the globe is just a URL away from accessing your application. That's great. But for developers, there's also a dark side to the mobile web. And if you've been doing mobile web development, if you've been really trying to get the best possible user experience across to your users on their mobile devices, you know this dark side, which is that we are at war with phones. Phones are our enemy. There are users best friend, but as developers, they are our enemy. And it can feel like as we're trying to produce the best possible user experience, the phones are fighting against us at every possible turn. Mobile networks are vast. There are over 2 billion users with a mobile smartphone in their pocket to access our web applications. But chances are a large percentage of those users are on slow, unreliable, expensive data connections, or they're not on a data connection at all. And that's something that we've never had to really deal with as web developers, as developing for the desktop web where you're plugged into the wall at all times. Mobile devices are everywhere. They're in everyone's pockets. You're a pocket reach away from a great user experience on the mobile web. But that means that mobile phones are fundamentally performance constrained. They need to have this tiny little battery that can power them all day long, and they need for when you take them out of your pocket for them to not burn your hand. And that means that to power, for the battery to last all day to power the sensors and the radios and not to mention this high resolution screen, it's going to be very constrained in the terms of the power that it can actually deliver to the CPUs that are doing your math for you that are running your application. And we've got a lot of tools available to us, a lot of open source tools available to us as web developers to allow us to create these web applications. Then these tools are incredibly diverse and incredibly powerful. But it can seem like more and more the tools available to us are getting continually bigger and continually more complicated. Building a great mobile web experience is hard. It's a little bit like climbing Mount Everest. It's challenging. It's expensive. To really do it right, you need kind of a lot of training and a lot of good guidance. And this is a shame. It should be much easier to deliver experiences on the web to users, especially in this important mobile context. But there's good news. We have a mantra on the Polymer Project. We have kind of a philosophy about how we think we should be building web applications, how what we should be thinking about as we're constructing these new mobile applications to make our lives easier and to make our users' lives better. And that mantra is to use the platform. The web platform is getting increasingly powerful, with new primitives like service worker, like web components, with new serving mechanisms like HTTP2. We have more tools at our disposal as developers than ever that allow us to build and deliver a really high-quality web application. And so it's our responsibility now. In fact, it's our advantage to take advantage of what's already there baked into the browser sitting on our users' devices in their pockets in the form of the web platform. So the Polymer Project is the Chrome web platform's team set of libraries and tools for web developers to help developers take full advantage of the modern mobile web platform, to take advantage of what's right there sitting on the browser. Now, the primary feature that Polymer, the library, has been focused around is web components. And web components is an umbrella term for a set of low-level APIs baked into the web platform, new web platform specs that allow you, the developer, to create reusable, composable components on the web. They create a new component model on the web allowing you to essentially extend the HTML language to create your own HTML tags that get understood by the browser just like any other baked-in HTML tag. Now, if you've been following web components, they've been around for a little while now. So the first spec came out in 2012, which was a while ago. And frankly, back then, we were over-optimistic. We were over-optimistic as to the speed at which web components would become broadly cross-browser supported. But this is okay. We went back to work. We went back to work with all other major browser vendors to work out an updated set of these APIs. The idea was sound. Everyone was on board the idea. We just needed to kind of work out the kinks in the APIs themselves. And so I'm very happy to say that as of today, we've turned a major corner with the web components APIs with an updated version of some of these web component specs, web components v1. So previously, web component support was scattered and it was varied. Template was supported across the board across all major browsers. But Shadow DOM and custom element support was either behind a flag or unsupported in most browsers. Today, with web components v1, as you heard earlier at the keynote, this story is completely changed. So all major browser vendors are on board with shipping Shadow DOM and custom elements v1 versions of the specs. In fact, Safari, in Safari 10 that just shipped recently, has Shadow DOM v1 shipped. Chrome has Shadow DOM v1 shipped. It's on the high priority roadmap of Edge. This is a very exciting time for web components. HTML imports are still on hold as we're working out how they're going to interact with ES6 modules. But I'm confident we'll come to a really good solution for how to load HTML with HTML. So I can't say this enough. This is a huge turning point for web components. At Google I.O. earlier this year, I said that cross browser web components was not a matter of if, but a matter of when. And when is right now. Cross browser web components are here with web components v1. Which brings me to Polymer. So the Polymer library, the library itself that kind of forms the soul of the Polymer project is a lightweight layer on top of these web components APIs. And it's designed as an opinionated way to pull together these different low-level specs, these low-level APIs, and make it easy to build for us developers to build a reusable web component, a reusable custom element. Now Polymer started out as an experiment. It has evolved with web components as the web components specs themselves have evolved. So Polymer started out just kind of to test out what would be the different low-level features that we would need as a web developer to create this kind of reusable element to extend HTML. So Polymer 0.5 with the last release of Polymer that was still kind of in this experiment mode. And then after a few years of iteration after working on the specs, after working on the library, it turned out that these web components things were actually pretty powerful. And so last year, we released the 1.0 version of the Polymer library, which was the production-ready version of Polymer. It allowed us as developers to take advantage of web components today in production applications without necessarily the APIs having to yet be shipped broadly across the different browsers. So Polymer has kind of quietly been out for a little over a year. And I think because Polymer started out so much as an experiment with these very early web component specs, we often get the question, who is using Polymer? Is anyone actually using Polymer in the wild? So I want to just name a few of the companies that are using Polymer in production today. So Polymer is used by Comcast, which is the largest media company in the world. It's used by the USA Today, which is the flagship brand of the largest newspaper publisher in the US, GANET. It's used by ING, which is the largest online bank in Europe. It's used by Neta Porte, the largest luxury fashion e-commerce company. Polymer is used by BBVA, which is one of the largest banks in Spain and Latin America. By Coca-Cola, which is the largest beverage company in the world. It's used by Electronic Arts, which is one of the largest game publishers in the world. By Predix, which is the software platform for the industrial Internet of Things from General Electric, which is the largest digital industrial company in the world. And of course, Polymer is used here at Google, actually quite heavily here at Google, on some of our biggest user-facing products. So Polymer is used in Chrome, in the Chrome UI pages, which has over a billion users. It's used in plain music. It's used in YouTube gaming. And just recently, at the Polymer Summit a few weeks ago, we announced that Polymer is actually being used on YouTube. YouTube, which is one of Google's biggest products, also with over a billion users, is now building the next generation of their mobile and desktop applications all on top of Polymer. So there's an immense organizational power that we're seeing to relying on standards. To relying on standards-based web development, you get this seamless, frictionless sharing of code that we've never been able to really, truly achieve across all kinds of different teams on the web platform before. And we're seeing more and more large companies going all in with Polymer, with web components, with web standards-based development using the platform. So a big value prop for web components is that they're interoperable, that you can build a component with browser-based technology, and then share it to other members on your team, share it with other teams at your company, share it with the overall ecosystem, and anyone can take advantage of that component no matter what kind of stack they're using, no matter what the rest of their JavaScript stack looks like. But this is great, but clearly, we've got big projects working with web components, big teams, that want to not just build components, but want to build entire applications. So we get the question a lot, how can I take web components and then build an entire application, specifically an entire progressive web application out of web components? And our answer in the past has always been, well, that's the whole point of web components is there's no one way to build an application. You can choose any of the tools that you're familiar with, anything that you like already, and use that to put together web components into an application. But obviously, that is kind of unsatisfying. And what we realized is that if you take web components, which are one new set of web platform primitives, and you combine them with other new, really exciting web platform features like Service Worker, like HTTP2, you can actually end up with a whole that's much greater than the sum of these individual parts. And so we wanted to put together kind of an opinionated showcase of how all these different features are really designed to come together and make for a really great user experience. And so earlier this year, we released the Polymer App Toolbox. And again, the goal of the Polymer App Toolbox was to go beyond just components and show how components can be put together with these other technologies into complete progressive web apps. So the App Toolbox includes a set of web components, app level components for things like layout and routing and internationalization. It includes a command line tool, the Polymer command line tool that lets you build and deploy your application. And things built with applications built with the Polymer App Toolbox are designed to be served via what we call the purple pattern, a way of using HTTP2 in server push to being able to deliver just absolutely the minimum of what you need to be able to render each view of your application to your users with minimal overhead. And you'll hear more and more about this purple pattern across various talks at this summit. And then in addition to the components and the pattern and the CLI, we wanted to show what you could actually create when you put all these things together. And so we launched shop. Polymer project.org, which you've also already seen in many of the demos up here, a progressive web app that really is just a killer user experience that uses the app toolbox, it uses the purple pattern, it uses Polymer web components to deliver an e-commerce-like application. You can visit that at shop.polymerproject.org. And we're already seeing the kind of value of this Polymer App Toolbox being used by companies to build applications. So take Jumia Travel, which is the travel division of Africa's largest e-commerce site. Now 75% of mobile connections in Sub-Saharan Africa are on 2G. And that's forecasted to still be 45% in 2020. So there's an immense challenge to be able to deliver a rich full application over the narrowest network you possibly can. And so thanks to the Polymer App Toolbox and thanks to web components in the purple pattern, Jumia's Progressive Web App is able to achieve this. They built a Progressive Web App on the Polymer App Toolbox that has twice as fast a page load on 2G and uses six times less data than their native app to be able to deliver the same exact flow. And I think the quote from the Jumia team really speaks to the value and the power of web components, which is that they were able to build a complete kind of prototype of this website, the entire flow in just four weeks, so that they could show it to their management and sell the management that this is a very valuable, compelling experience and then go from there to build the actual production application. So this is exactly what we want web components to allow developers to achieve really rapid prototyping all the way through to production deployment. So we're really starting to feel the momentum of web components. Web components are now being truly broadly adopted cross browser. They're being used in real serious production applications by large companies and here at Google. And this means that it's time to kind of open the next door for the Polymer project. So we're working right now on the next major push of the Polymer Library, which is Polymer 2.0. So we just released the preview version of Polymer 2.0. It's up on GitHub. And there are a few key things that we're focused on when we're designing and working on Polymer 2.0. A few key features and distinctions that from the Polymer 1.0 release. So the first obviously is Web Component V1 support. Web Component V1 are the specs that are going to be broadly shipped across browser that we're already seeing out there and Polymer 2.0 is designed to take advantage of these new custom element and Shadow DOM V1 APIs baked into the browser. Polymer 2.0 also offers better interoperability with other JavaScript frameworks with other JavaScript tools by eliminating some of the Polymer specific abstractions that kind of leaked through in Polymer 1. Namely the Polymer DOM shady DOM APIs and some structured data manipulation that leaked through. So the takeaway is that an element, a custom element built in Polymer 2.0 is truly web native and it will be indistinguishable from any other vanilla Web Component that you might build with any other Web Components framework or just with raw vanilla Web Components. And finally, we don't want to leave Polymer 1.0 users in the dust. One thing that we took away from the Polymer 0.5 to 1.0 transition is that transitioning a major framework, transitioning a major dependency even if it's small is a huge pain point, especially for large companies, especially for large projects, especially for teams of Google that are relying really heavily on Polymer. So with Polymer 2.0 from the beginning, we've designed it with backwards compatibility in mind. So Polymer 2.0 comes with a near seamless backwards compatibility layer, making it as simple as possible to be able to transfer a Polymer 1.0 component to work in Polymer 2.0. And Polymer 2.0 also supports what we call hybrid mode. And hybrid mode means that you can, there's a way to write a component such that it can work on Polymer 1 or on Polymer 2.0. And so what this allows is if you've got lots of components in your application, if you've got lots of components shared across your company, you can incrementally upgrade one element at a time while your application is still live in production. And once all of these components are upgraded to this hybrid mode, you can switch over from using Polymer 1 to using Polymer 2.0 and then continue to take advantage of the Polymer 2.0 specific features. So it's a much, much easier, much smoother, more seamless upgrade process than having to stop all the presses and upgrade everything at once before you put your application back into production. So Polymer 0.5 was an experiment for web components. Polymer 1.0 was allowing you to use and achieve the promise of web components in production. And with 2.0, we can finally realize the full value of web components, which is going web native, which is using, actually truly using the platform, using standards-based cross-browser APIs to use the platform to write less code, to ship less code, to write more elegant, smaller applications and deliver them across the mobile web. And we're actually seeing this use the platform mantra bearing out in the numbers with Polymer 2.0 when you take a close look at how Polymer 2.0 actually works and is built. So Polymer 2.0, if you build a web component with Polymer 2 and you ship it on a browser that doesn't need any polyfill so that supports web components v1 out of the box, Polymer itself is only 12 kilobytes. It's small. And it's getting smaller and smaller. And that is our whole goal with Polymer. We're not trying to build a massive framework. We're trying to build a tool that gets smaller and smaller as the platform fills many of the gaps in our developer experience. So this is using the platform in actual service to the Polymer library. We are just at the beginning of the story for web components. And we're still actively figuring out all the kind of best practices and best ways that we as developers, as teams, as an ecosystem can take advantage of all the things that web components provide. So we've been building web components for a few years on the Polymer team, and we've certainly learned a lot in those few years. And so here to tell you more about how to take advantage of web components in the browser and how to build really killer applications using web components is Monica, an engineer, on the Polymer team. Coming up mid-talk means that I didn't get an awesome Paul Lewis introduction, so I'm super bummed about this now. Hi. So the thing about Polymer and the library is that it's not really about the library itself. It's about what you do with it. And that's building elements. And what I've been thinking about on how to, like, structure this talk, I've realized that when Taylor said that mobile web development is hard, the same thing can be said about element development. It takes a lot of expertise. It's really hard to make a good element that you can put on every page that you have. So I think it's really important to actually talk about it. And what we've been talking a lot about is how to make a good element, that how to make a fast element. And we've given talks about, oh, I'm not allowed to go back. And we've given talks about that. But then I thought about it and there's three kind of people that actually interact with elements. You've got the people who use their elements, who don't actually want to build a good element. They just want to use other people's elements when they're developing a web app. There's people who author the elements and we've been talking about them a lot. And there's people who maintain the elements. And these may be the authors, but may just be other people who've inherited these elements don't really know, like, the intimate details on how this element came to be the monster that it is. So we need to be able to address their concerns too. So I'm going to do two different things. I'm going to talk about the people who use the elements and give you some advice about how you can architect your apps using web components and how we've built some tools for the people who have to maintain those elements. And on the Polymer elements team, we have a lot of experience with this. We initially authored over 100 elements. I think it's over like 130 now, which is kind of a lot. We've spread them across three different orgs to make everything actually really complicated and hard to sync and test together. Why not have a little fun while you're at it? We've used them internally, like just in our team on over 20 apps. And this is important to us, like the shop app, because that's how we come up with advice for other developers. That's how we come up with patterns that you can use. And we're also on the maintaining side of this. It's Polymer elements are used in over 500 apps. These are internal to Google. They're external to, like, some of the companies that you heard about before. So we kind of cover all of those three different areas that I talked about. So let's talk about app developers. It's probably half of the audience. You maybe want to use a web component in your application. How can we make this better for you? What best practices do we have for you? And the best advice that I have is that you should not look at web components as something that they are new. You already know about components. If you've used any language, you've got objects, you've got the ideas of, like, compartmentalizing your code. That's not new. And web components themselves aren't actually new either. If you've ever used an input element or a button, they're kind of like a web component. They're a little nugget of functionality and code and styles that have been put together in a little box and given to you and it has an API. And you know how to use them. You've been doing it for a long time. What's new is that other people can now build these web components that are just as powerful as the input and button. They just have different names. And you should treat them basically in the same way that you've been treating input. So I built this really to demonstrate, like, the next example. I built this really dumb app for the Polymer Summit. It's basically an emoji social network where it's kind of like Twitter and Slack jammed into one. But instead of being useful, the only thing you can type is English and it gets translated to emoji. So the only thing that you see is, like, a stream of emoji. And I'm walking around with a beacon now. I've got my first physical web beacon. So if you're, like, around me, you can actually get a link to it. It's mojibrag.frybase.com. But when I was designing it, I was like, OK, cool. Let's say that I've never used a web component before and I want to design an app with them. What do I do? And it's basically the same way that you would use, like, a normal application. You just think about the features that you have in your application. Somehow I have to authenticate a user. Then I got to show them something like a giant screen of a blob of text. And this text can be, like, a list of other people's dumb emoji posts or the amazing ability to write your own dumb emoji post because how else are you going to get content in there? And once you figure out these features, you can, like, go ahead and dig deeper in each of them. Well, when you write a post, you have to somehow translate from English to emoji. And then if you've got a list of posts, you can, like, like them and see their location and all sorts of other stuff like that. But once you have this idea of, like, what the logical components in your application are, it translates immediately to web components. Your authentication part is done with Firebase Auth, which is an element that does authentication with Firebase. IronList is a thing that manages your list of elements. And then new posts in my app are little web components that I built internally to my app just to, like, logically structure code around. And it was really easy. And the awesome part about components, and this, again, is not new. It's happened if you've ever written a class before. If you've written a component, you can refactor it really easily because it doesn't affect the rest of the app. It just sort of sat there as a standalone thing and you just get to fix its code. So this shouldn't look scary. It's how you would write web components. You could call it a div class equals main screen, but now you can just say main screen as an element. And because web components aren't new and you've been using them in the browser, you just didn't know that an input was a web component, you should use these new web components that you're getting from users in the same way. And that's by using properties and events. If you look at an input, you set all these properties in it. You said it's type, you said it's value. You said whatever, the min length and max length. When an input does something, it fires an event. It fires an input event. It fires a change event. This isn't new. And this is exactly what people have been doing with their web components. Properties go down, events go up, and you get this like magical unidirectional data flow in your application. So if you go back to my application from before, you have this like giant screen at the top that knows about the state of the world and you've got like your post button where you like mash on your keyboard and emoji comes out. And the app is gonna know things that not every component knows about. For example, it knows what channel you're posting to. So it's going to inform anybody that it cares about by setting a property on those elements. Again, just like you've been doing with input. And when you're done mashing on the keyboard and you have like a new post ready, you fire this custom event and be like, hey, I got an emoji post. Does anybody care? And if anybody cares, they're gonna intercept that event. And the same can happen if you wanna like hide conditionally UI in like parts of your application. You just set different properties. What I didn't tell you here is that you should call like a public method on this element or something like that. Because again, that's not how we've been using DOM elements before. We don't call random functions on input. We just set properties, which leads me to my third device. Use properties and non-message. You might be tempted to use methods because JavaScript is really keen on having methods, but that's not how the DOM really likes to be used. The DOM has properties and attributes. And this is really great if you're using properties because then you can just use them imperatively and you can have data bindings and stuff like that. So imagine you have a dialogue. You could call dialogue.open on it, but you don't need to. If it's got a property, you can just say hey dialogue, dialogue.open equals true. And once you've done this, you can just do it as a binding somewhere in your code. And it depends on like some other state of the world. And without writing any JavaScript, like things will open and things will hide as they should because that's how properties work. So properties, properties on methods, properties go down, events go up. Those are your rules. So that's the advice that I have for app developers. But what do we do about element maintainers? You're like this poor sucker that has inherited like 17 elements that somebody else wrote left the company and you don't actually know why they're in that state. And this happens whether you're maintaining elements externally like we do for like the rest of the world or internally like a lot of companies do, they just have an internal set of elements, but they still have to maintain them. So we've been writing tools. And the biggest advice that I have is you keep hearing about like test driven development. That's great. But I think you should practice fear driven development. And that's not being afraid of the code or anything like that. It's really just being afraid of your users and that's a healthy approach to development. Because most importantly, you should be afraid of like breaking them and breaking their applications. That's like your one responsibility as a maintainer. Don't break other people's code. So in preventing breaking changes, we've been using this tool internally and we're working on like making it, it's a public repo on Polymer Labs and we've been working on fixing it so that you all can use it. And it's called TAD2, which stands for test all the things over and over because why not come up with a complicated acronym if you can. And the idea is really simple. When you, if you're a maintainer and you wanna like accept somebody's pull request, your biggest concern is that you don't actually know what this is gonna impact. Look at this dependency graph, which is not a real dependency graph. They're usually way worse than this. But if you modify a leaf at the bottom, unless you have the ability to like hold all the 130 elements in the Polymer Elements catalog in your head, you're probably not gonna know what that change is gonna affect. It could be a behavior, it's gonna be like the ability to be included in like a custom form or something like that. You don't actually know how many elements depend on that change, especially since they can go many levels up the tree. So what TAD2 does is it lets you specify a branch or a particular hash or something like that in a particular element and rerun based on that commit, a whole suite of elements, a whole suite of tests. So in this case, we make a change to one element and like make sure that all the other tests pass. This is great because then you have the confidence as a maintainer that like this PR isn't gonna, you know, destroy all of YouTube because we've definitely not done that before. The other thing that you should be afraid of is perf regressions. It's really great that now you've like have the confidence that you're not gonna break somebody's application, but making their application slower is kind of slightly worse because that's harder to fix. And we have two tools for that. The first one is Poly Dev, which is a Chrome extension and you can run it on any app that uses custom elements and basically ranks how expensive the elements that it sees on the page are. And it's great if you wanna like audit your page and like make sure that like as you're contributing to an app, so this is also good for the app developers as you're like fixing your app, the performance sort of stays as you expect. But it's also really good for maintainers. If you have like a giant catalog that has like different demos for different elements and one of these elements that used to be really cheap after a commit suddenly like spikes to the top, that probably means something bad has happened and you wanna like undo that change. So that's what Poly Dev does for you. It's in the Chrome app store. You can download it, it's awesome. My favorite tool is Poly Perf. And please note how these names have a Poly prefix at the end, but tattoo doesn't cause poly tattoo is weird. So Poly Perf lets you basically compare the performance between changes. So here, this is an example from Steve's talk from the Polymer Summit where as a baseline he has an input element and that's not, it doesn't cost you 20 milliseconds to make one input, it costs you 20 milliseconds to make 250 of them on a page. And then he had like this ratings element and he started with like a super shitty version and it just made it progressively faster. And these are just like three iterations of that ratings element. And the reason why this is good is because you can start doing it for like, again, different commits and different shaws and different features that you're adding to an element and be like, cool. This element used to cost like 129 milliseconds and now it's 500 milliseconds. Is this change really worth it? Which is great for you as a maintainer because then you can go back and be like, no, this changes shit, we're not merging it, it's fine. So that's fear driven development. The sort of parallel and kinder version of development to that is demo driven development. If you think about your users, they don't really, like I personally can't look at a snippet of code and be like, I totally know what that element looks like and how it's gonna fit on my page, that's great. I can only like look at demos and be like, I want it, I want the shiny button. So that's what demo snippet is for. Demo snippet lets you write basically how you would use that element, shows you what the code is and shows you what that element looks like. Here's a whole bunch of paper fab buttons. Fab stands for floating action button, not fabulous. And it took me about a year and a half on the team to find that out and I was super sad. I think fabulous button is a way better name but nobody listens to me. So that's a demo snippet, it's really great. And we've noticed, we've like heard that Comcast for example, uses this element very aggressively internally to just be like, these are all the elements we have, this is what they look like, do you care? And we've taken this demo approach very aggressively to the new beta site for the webcomponents.org. So beta.webcomponents.org is the new element catalog where we're moving all of our elements too and it basically supports collections and elements and they're curated collections. You can make a collection called fabulous elements and you can add all sorts of web components to it. So when people search for fabulous elements, they'll get to it. Oh, sorry. But most critically, it supports inline demos. So this is the documentation page for Faber-Fabulous and here at the bottom, you see a demo and it's a snippet but the best thing about the snippet is that it's not static like the demo snippet used to be. It's actually interactive. So here I can change the contents of one of these buttons or I can even add a style because this kind of element advertises a custom property to change its color. So you can go ahead and do that. So what now? We have web components. They're native in the browser. Polymer 2.0 is right around the corner. What does this mean for you as developers? Because this is called Polymer web components in you. Let's talk about the you part. There's never been a better time to actually start using web components. So go ahead, just go and use an element. Add, I have a really dumb element called emoji rain that makes it rain emoji in your page. Go ahead and drop it on your blog, why not? Use Polymer, don't use Polymer. Use vanilla custom elements that you stumble across. Make your own element and if you do share it, polish it up, submit it to beta.webcomponents.org so that everybody else can look at it and it's gonna be really awesome so that their applications can get better. But most importantly, just make things. Use the platform, use tools that make your life better and make you like write less code and build awesome things for the web because it's up to you to make the web better. We can just like help you along with it, but at the end, you're gonna make it awesome. Thank you.