 All right. Good afternoon, everybody. Thanks for coming to I.O. 2017. Yes, we've got a great one to start. I'm so excited to kick this off. My name is Taylor Savage. I'm a product manager here at Google on the Chrome web platform team. Now, we work on a number of different web developer facing products on this Chrome web platform team. And here today, I am here to talk about one of our biggest, which is the Polymer project. So the Polymer library is a small JavaScript library that makes it easier to build web components. Now, building big complex things out of smaller, less complex things is a pretty fundamental part of any engineering discipline. And it's certainly fundamental to web development. It's hard to imagine building any kind of large, complex website or web app of any meaningful skill without some way of encapsulating and reusing logical and interface components. In the past, though, the web platform itself has never really provided us developers with a clear way to build components. We've had HTML elements baked into the platform, but we haven't had a platform-provided way to actually design and build our own components. That method has been nowhere to really be found. So as developers, we've always had to kind of drag along our own component model in JavaScript. So along with our application code that actually ran our applications, we've had to ship an invented abstraction in order to build any sort of meaningfully large application or to be able to reuse components in any sort of meaningful way. Now we have web components. Web components provide us with a very flexible, a very low level, but a fundamentally standardized way for building components on the web. It gives us encapsulation and reusability and interoperability, all things that a good component model needs, but baked directly into the web platform itself. Now we've been excited about the prospects of web components for a few years now, and we've been working hard on the Polymer project to make it easier to take advantage of the promise of web components today. But this year, this I.O. is, by far, the most exciting moment that we've ever had throughout the entire history of web components. Because as of this year, Safari now natively supports web components. Yeah, this is incredibly exciting. With Safari 10, the Safari browser shipped native platform support for custom elements and Shadow DOM, the two most critical web component APIs. Chrome supports these APIs. Opera supports these APIs. We've been on stage at I.O. promising web components for a few years now, but now they're here. They're actually here. So with these browsers, there are over a billion active mobile devices in the world, in our pockets right now, in all of your pockets right now, that natively support web components with their browsers. Web components are no longer some distant future. Web components aren't really even that cutting edge anymore. Web components are just a reality of today's web, a massively powerful new tool in our toolbox as web developers, and really a deeply fundamental change to the way the web platform itself works that makes it a much more capable development platform to build the types of experiences that all of our users expect today. So our mission on the Polymer project, on the Polymer team, is not just to build useful tools for web development, but to work to fundamentally move the web platform itself forward, and to make this future of web development more possible today. So the Polymer project, as a whole, started a few years back with a directive from some engineers on the Chrome team. And they said, we need to put together a team of web developers that can live in the future, that can build on the web platform not as it is today, but as it will be, and then kind of report back to the present to help us, the web platform team on Chrome, know what direction to go. So the Polymer project in this way was kind of designed as a laboratory for future web platform features that we wanted to bake directly into browsers, to find out what worked, to find out what didn't work, to provide feedback back to browser implementers and spec writers, and to do whatever we could to then bridge the gap between the web platform as it existed today and the new platform features that developers were going to be able to take advantage of in the near future. So fortunately, we are not alone on the Polymer project in this mission. We have friends also looking towards a web development future. In fact, we have a lot of friends looking forward to a web development future. The open source web ecosystem is a dazzling place. There is a ton of innovation, as everybody here knows, happening all the time when it comes to web development. React has brought functional reactive programming for UIs into the mainstream. Preact has made this possible at a fraction of the size. View takes a very bottom up and modular approach to framework design. Svelte looks to start with this framework and then compile it all away. There's so much exciting stuff happening all the time in the web development open source ecosystem. It's an awesome place to work. There are luminaries charting new paths, trying new things, guiding the way all the time. So on the Polymer project, we look at our mission. We look at our contribution to this open source ecosystem through the lens of being part of the web platform team here at Google. So the Polymer team itself is really half web developers and half web platform implementers. And what we quickly realized was that web platform users, web developers, framework authors, have ways that they like building web apps. And web platform implementers, so browser engineers who spend their days optimizing platform features, building consensus around new platform features and APIs across different browser vendors, web platform implementers have ways that they think web apps should be built in order to be fast. In order to take advantage of all the things that this web platform does well and avoid the things that it doesn't do well. And these two worlds, how web developers like to build and how browser implementers like to build, sometimes don't agree. And sometimes they loudly disagree. So before web components, in order to build an application of any meaningful scale or size on the web, you needed to use a large JavaScript framework. It was an absolute requirement. And JavaScript frameworks can be really amazing. They allow for all sorts of different mental models to think about how you're going to build your app. They help developers avoid foot guns that are in the platform. They grow large communities and ecosystems in and of themselves in their own rights. But fundamentally, as browser implementers, we see the fact that you can't really build apps with just the platform as a flaw of the platform itself. So with the Polymer project, we are pushing to make it possible to build and deploy apps that are closer to the web platform and use that platform the way implementers intend it to be used rather than substituting a separate platform on top. And we think, of course, that there can be some very real benefits to using the platform directly to build an app. Less abstraction, shallower learning curves, better performance, better reusability and interoperability, faster load times, and ultimately a better user experience. So we sum up this mission in our slogan and rallying cry, which is to use the platform. There are two properties of the web platform that make it great. One is it's standards-based, and two is that it's open and distributed. Anyone can look at the specs and build a browser that supports the web platform. In fact, most browser rendering engines are open source. And no single entity can decide what makes up the web. So what we end up with is a number of different browser vendors in this collaborative competition with each other, this cooperation, each looking to provide a great user experience to its users in its own right, and each building off the same kind of general set of specs, but inevitably providing its own slight interpretation of what this web platform is. And so the end result is a web platform that moves very slowly and very methodically. Now, there are benefits to a slow-moving methodical platform. But today, more than ever, we need that platform to change and to adapt. The original web platform was designed for documents. And then it allowed you to style those documents, and then maybe it allowed you to script some things in those documents. But the platform itself wasn't fundamentally constructed around the idea of building applications. It's lacked very basic things you need to build an application. It lacked proper encapsulation. It lacked a component model. It lacked an efficient way to load resources. And frameworks do an amazing job of making it possible to build apps that can survive on this web platform. They bring along the things you might need to build an app. They provide encapsulation. They provide a component model. They create a layer of abstraction that lets developers do things that the low-level web platform hasn't let them do. On the Polymer project, though, we have our web platform hats on. We have our browser implementer hats on. We want the platform itself to be rich and lush and powerful. We want the code you write to be eminently reusable. We want it to be more maintainable. We want it to be lighter weight and faster. We want it to be possible to build higher quality applications closer to this platform itself. And for your applications, built close to this platform to directly benefit from all the hard work that's going on all the time to make the platform better and faster. So on the Polymer project, again, with our web platform hats on, we don't want to find a way to work around the web. We want to terraform the web itself. We want to make it easier for developers to take advantage of what the platform does well and actually change what the web doesn't do well. And that is what we mean by use the platform. Now, of course, use the platform doesn't necessarily mean use only the platform and nothing else. That's not reasonable. There's this wonderful symbiosis that exists between the platform and the JavaScript community. And there's plenty that other frameworks can do that the platform can't provide, that Polymer can't provide. There's plenty that libraries and tools can do that wouldn't necessarily make sense in the platform or that you couldn't reasonably build cross-browser consensus around in order to get baked directly into the platform. So with use the platform, we're just trying to go from the bottom up. We're trying to help raise the tide that can float all boats, to help developers ship code that's absolutely just the code that's absolutely unique to their application and let the platform itself handle more and more of the glue. So the ultimate success for us on the Polymer project would not to be to have everyone in the world using Polymer. The ultimate success for us would be for the platform itself to be powerful and extensible enough that Polymer and our tools would no longer have to exist at all. So with web component shipping broadly, along with other new powerful platform features like HTTP2, like Service Worker, use the platform is not some hypothetical vision. It's a very real strategy that major companies and major projects are using today. So we get asked a lot, who is using Polymer? And the answer is a lot of people. So Comcast, the largest media company in the world, uses Polymer to share components across multiple different Xfinity properties that they own. USA Today uses Polymer to build rich interactive experiences like they had for the Olympics and the election. ING, the largest online bank in Europe, uses Polymer to share components across the dozens of different applications they have built for dozens of different markets. Net-A-Porter, the largest luxury fashion e-commerce company, uses Polymer to share rich components to keep a consistent design across multiple properties and pages. BBVA, one of the largest banks in Spain and Latin America, uses Polymer to share components to be able to quickly build new applications. Coca-Cola, the largest beverage company in the world, uses Polymer components to ensure consistent branding across all of their different digital signage. Electronic Arts, one of the largest game companies in the world, uses Polymer components to quickly spin up beautiful new sites for all the new games they're coming out with. And General Electric uses Polymer for Predix, which is their industrial Internet of Things platform, to make it easy to build all kinds of great data visualization applications on top of the Predix platform. So companies around the world are using Polymer to build applications. And companies around the world are also using Polymer and the Polymer App Toolbox to build lightning-fast progressive web applications that use less data that load fast. Sites like Jumea Travel and Conga, the two largest e-commerce platforms in Nigeria have production progressive web apps built using Polymer. We go one of the largest travel booking sites in the Middle East in Asia, has a blazing fast progressive web app built with Polymer. And Ola Cab, the largest ride-hailing company in India, just launched a progressive web app using Polymer. And of course, at Google, we like to use the platform as well. So there are over 700 Google projects that use Polymer. In fact, Polymer is one of the largest front-end dependencies used here at Google. We use it in production on products like Chrome and YouTube gaming and play music. The new Google Earth just launched using Polymer. And the new YouTube redesign is built using Polymer, one of the biggest web properties in the world making a bet on web components. So we're seeing huge momentum in Polymer web components, but this is only the beginning. We've been working on a ton of new stuff as well, which we're extremely excited to share with you today. So here to talk about some of the latest projects that we're working on on the Polymer team is our host, Katie Gitsberg, the Product Manager of the Polymer project. Thanks, Taylor. The first version of the Polymer library was released about three years ago, and it was one of those, hey you, go live in the future, report back and tell us what you found, proof of concept projects that Taylor was talking about before. It was a proof of concept that you could take these nascent web APIs and wire them together in such a way that you could build encapsulated reusable platform-based components. And we hacked through that for a while, explicitly as a non-production grade developer preview, but that didn't really seem to stop anyone. We saw that developers were still picking it up and trying it and using it, and they really liked it. And even some large companies like Comcast immediately took to this idea of having platform-based components. So we took the next logical step, and we decided to move out of a proof of concept and take Polymer into the big leagues to graduate a little bit as a production quality web components library with Polymer 1.0. And since we launched 1.0, we've seen a great deal of advancement and traction as Taylor was talking about before, and Polymer 1.0 came a really long way on its own. We've seen a flourishing production in web apps all the way from Southeast Asia to North America. And with these web components APIs supported widely across browsers, we have the perfect opportunity to realize this initial vision even further. So we've taken the best of the Polymer Library and the best the platform has to offer and fuse them together to form the next major version of the Polymer Library. I'm proud to announce Polymer 2.0. Polymer 2.0 is based on web platform standards that are natively supported on over one billion mobile devices. Because of advancements in the platform, Polymer 2.0 is one quarter the size of 1.0. And all of this makes web components built with Polymer 2.0 interoperable by default, meaning you can use them more easily in popular JavaScript frameworks. Here to talk more about Polymer 2.0's main goals and how we achieve them is one of the tech leads on our core Polymer team, Kevin Schaaf. Okay, thank you, Wendy. So on behalf of the entire Polymer engineering team, we are really excited to get this new release out to all of you. So I'm going to give a brief introduction to Polymer 2.0 by talking about three key goals that we organize ourselves around for this release. So first is aligning to the latest platform features that are shipping across browsers today. Delivering on the promise of web components interoperability and then providing a smooth migration path for our existing customers to Polymer 2.0. So in the last couple of years since Polymer 1.0 shipped, all of the web browser vendors got together and agreed on a new set of web standards for defining web components. And in the modern browser, defining a new web component is as simple as writing an ES6 class that extends from HTML element. Now, you may not be familiar with HTML element is actually the built-in base class that all elements in the browser extend from. And now using ES6 classes, we can do that very idiomatically. This is as simple as it is to define a new element that extends the browser. And then by registering that element with the new Custom Elements API, we can associate that class with an HTML tag name. And then any time the browser sees an instance of that element, either in static markup or created dynamically, say via a framework, it's going to create an instance of our class. It's going to run the constructor, and it's here in a few other lifecycle callbacks provided by Custom Elements and we can implement the unique behavior of our element. And that's where Shadow DOM comes in. So Shadow DOM allows us to create a scoped subtree of DOM that's completely hidden from the outside. All of the styling in DOM are completely encapsulated and self-contained. And this is the real key to ensuring that web components are interoperable and can run in any environment. And what's awesome is that the code that I had up there on that previous slide requires no library code at all. So that three or four lines of JavaScript, we can actually just paste into an inspector, plugged into any one of your phones right now, hit Enter, and the browser knows how to construct and render that element, that component. Web components are native, right? So you may be wondering if the browser is becoming so capable, if we have this built-in component model, why do we need Polymer at all? So Polymer's goal in life is to fill in a few key features that we find useful when building Custom Elements. Things like being able to render the contents of the Shadow DOM from a template, keeping the elements in that template in sync with the element state via data binding, providing a little bit of declarative sugar for things like Custom Event Handlers. And then Polymer Elements also keep their property and attribute APIs in sync so that you can send initial configuration down and markup and then interact with your element after that via properties in JavaScript. So this is a sampling of the features that we provide in Polymer. And in Polymer 1.0, we provided these kind of an opaque function call that kind of hid a lot of the beauty, the elegance of Web Components. So now that ES6 classes are native in the browser, we're actually, in Polymer 2.0, moving to a new syntax where we're layering the Polymer features onto that native, elegant syntax in the browser. So if you're just getting started with Web Components, I actually really recommend you take this little snippet of code and play with it in the Inspector in the browser. You can just get a feel for the Web APIs right there. And then as soon as you're ready to start layering in some of the functionality that Polymer provides, it's as simple as changing the base class that you're extending from. So in Polymer 2.0, to use the features of Polymer, all you have to do is extend from Polymer Element instead of HTML Element and then provide a little bit of metadata on your class to start taking advantage of those features. And because we're aligning to the ES6 class syntax, you get things like native inheritance for free. So you can extend an element that you've created or found on the Internet, change some of its implementation details. I might return a different template that I want to render and define a new element that has some extra different functionality. So to recap, Polymer 2.0 is aligning ourselves to these new platform features that are shipping across all of the web browsers. So ES6 classes, custom elements, Shadow DOM, and CSS custom properties. So I didn't really show custom properties in action, but this is very analogous to how custom elements allows us to extend HTML. CSS custom properties are a new native browser feature that are actually shipping across all browsers now. As of Edge 15 that shipped a couple of weeks ago, we can now use CSS custom properties to define a custom styling API for our custom elements and for that Shadow DOM. And of course, for the remaining browsers, which are mostly users on desktop, right? So most of our mobile browsers with Chrome and Safari all have all of these features natively. For the remaining desktop browsers, we can continue to provide a set of high-quality production polyfills that you can use to target all of these features. And the result of all of this is a dramatic reduction in code payload. On top of using these platform features, we're also shipping Polymer 2.0 with an improved polyfill loader that detects the capabilities of the client and only loads the polyfills necessary for that individual browser. And the result is this really nice reduction in payload. So as the capabilities of the browser go up, the amount of code that you need to load and run on the client to use all of Polymer's features goes down. And if we compare this to Polymer 1.0, you can see this is a huge improvement, especially for the most capable browsers. We're able to use Polymer's features in a fraction of size. And this slide right here is really the promise of web components in action, right? Aligning to the latest platform features. So I'll move to the next goal. This is around interoperability. Interoperability is a feature of web components that we've promised from the beginning, that building your components around a set of standard APIs that the browser understands means that you can use them in any environment. So we've always known that Polymer elements could be used here in static markups, say, sent from the server, or inside of other Polymer elements. But the promise has really been that you could use Polymer elements here in an Angular component, for example, or even in some of the hottest devices in the world. So we've always known that Polymer elements could be used in any environment. But unfortunately, in Polymer 1.0, the realities of polyfilling these browser features kind of got in the way. When we set out to ship Polymer 1.0, we found that the mobile browsers of the day, kind of back in 2014, weren't capable enough for us to robustly polyfill the entire Shadow DOM spec. And so we made a conscious decision to use the Shadow DOM features so that you could use those features today on those underpowered devices. But unfortunately, this obviously broke that promise of interoperability. So I'm really excited to say that things are different now. With all of the mobile browsers that we're all using now shipping Shadow DOM and now being able to leverage Shadow DOM, the importance of the polyfills is slowly fading away. And so in Polymer 2.0, we've taken the opportunity to rewrite what is actually using Shadow DOM. And the result of this is that elements built with Polymer 2.0 will now be able to be rendered by all of the JavaScript libraries out there today. And as you know, in the JavaScript community, all the frameworks that everyone's going to be using tomorrow are probably going to be totally different. But the key point to take away is that elements built with Polymer 2.0 and web components will still be compatible with them, the promise of web components. All right, so last I want to touch on the migration path that we've charted for Polymer 2.0. So as Taylor mentioned, there's a ton of really awesome companies making huge strategic bets on Polymer and web components. And we're really excited to get this release out to all of you. But we also know how scary a big breaking change can be to the foundation of your tech stack, something like the component model that you're building everything from. And so we spend a ton of time and effort on the Polymer team to get it on to Polymer 2. So on the left here, I've got an example of the Polymer 1.0 syntax. And if you're not familiar with it, that's fine. All I want you to do is pay attention to the right and get a feel for the amount of work that will be required to port from Polymer 1.0 to Polymer 2.0. All right, does everybody spot the difference? That's right, there's not any. Because Polymer 2.0 is shipping with a backward compatibility layer that allows elements written with the Polymer 1.0 API to still target Polymer 2.0 and all of the native browser features that we're taking advantage of. And so for the vast majority of Polymer 1.0 code out there, the only changes that will be needed to migrate are some minor changes to the template to align to the new Shadow DOM spec. But that's really mechanical. So for the users getting started with Polymer 2.0, we'll have a really nice set of options for getting started. A lot of users will be able to just start right with the ES6 class syntax and the benefits of using native classes in the browser like inheritance and native supercalls. On the other hand, a lot of users that have existing Polymer 1.0 code will be excited to be able to port that to 2.0 as quickly as possible. And for those users, they can just simply load the compatibility layer, make those minor changes to the template and be off and running. And then migrate ES6 classes in over time as they see fit. And then last, we're also shipping this to a common subset of features in Polymer 1.0 and 2.0. And then those elements can actually run in applications targeting either version of the library. And this will be really useful for organizations shipping a lot of components to a lot of production applications at the same time because it means they won't have to freeze their application development while reporting their whole element set. So I'll also mention that we've dog-fooded this migration path with all of the elements that the Polymer team maintains, something like 75 or something, of our demo applications. We're also hearing really good things from the community that the migration from Polymer 1.0 to 2.0 has been incredibly smooth. So that's Polymer 2.0 in a nutshell. We're aligning to the latest platform features. We're delivering on the promise of Web Capone Center operability, and we're providing that smooth migration path for people to get up and started with it today. So with that, I'll hand it back to Wendy to talk about all the other awesome stuff that's happening on the project. Thank you. All right. Thanks, Kevin. So the Polymer project isn't just about the Polymer library. It's made up of a bunch of things because building Web apps can get complicated, and as we all know, Web development nowadays can be unnecessarily challenging. So we bring a whole suite of tools, libraries, and patterns to support you. We have our elements, a collection of about 100 Web components made by our team. This includes material design UI components, Firebase integration pieces, data storage elements, and much more. To make development with Web components as streamlined and accessible as possible, we have a full suite of Web component tooling projects, so you can use those with Polymer or any other sort of Web components you're using. To learn best practices for rendering Web components both reliably and at scale, we've created a few helpful patterns. Most recently, we've developed the purple pattern, which focuses on fast-first load, emphasizing time to interactive and reliability in all network conditions, including usability offline. And with the Polymer library as the foundation for building components and tools and patterns to help along the way, we've also gone that next step and built the Polymer app toolbox. The Polymer app toolbox is a set of tools, templates, and off-the-shelf components to help you build Web component-based progressive Web apps more easily. So that's quite a lot under the Polymer project umbrella. And over the past year, we've advanced each portion of the library and the other projects to pack in more power and help you build for the future faster. So the Polymer library exists to help you build encapsulated reusable components. We know this. So, of course, the Polymer team uses it ourselves to power all of the elements that we've made. And as Kevin mentioned, we've taken all of our elements, about 100 of them, and ported them over to hybrid mode built with Polymer 1.0 or 2.0. And so, sure, there are a bunch of elements that we've made, but there are hundreds more open-source, off-the-shelf, high-quality Web components that you can use today. And if you want to find any elements to use, they're all conveniently located in the same place on webcomponents.org. Webcomponents.org launched just a few months ago, and it's a consolidated home for high-quality, open-source Web components of all types made with plain JavaScript or library-based. And since it's released just a few months ago, we've seen an overwhelming wave of organic growth to the site and the community around it. As of now, there are almost 1,000 elements up there to choose from. And besides that large selection, there's a rich feature set on the site that makes it an awesome place to search for, try, and vet components before downloading. So there's automatically generated documentation across the entire site that gives a consistent look and feel no matter which component you're looking at. There's also in-line editable demos. So if you watch here, if you're looking at this game card component, you can click, see that CSS animation in line. You can even edit the attributes down there, change the rank to an ace of five. It updates real-time, pop in another one, unrevealed, and the card flips over. It's pretty awesome. You don't have to download a thing. We also have collections. If you want to make it even easier to find different elements that are related, this is the Google Cast collection. So if you want to add Cast integration to any of your projects, it's as easy as finding this collection and popping one of those elements in. There's also a couple from IBM Research and other developers in the community who have collected really great components together. And lastly, if you really want to vet and see how popular a component is before you download, here's a super helpful one if you want to add emoji reign to any of your projects, because of course we all want to do that made by our very own Monica. You can see that it's got 120 stars on GitHub. You can check out Forks, Active Maintainers, and see the health of an element in the open-source community before downloading. And lastly, I just wanted to show some super cool elements that I really like that you can install, import, and insert directly into your code. On the top left, you can check out that game card. It's got those beautiful CSS animations and resizable SVG graphics. The queens and the jacks look awesome. There's that sign here element which has this really cool ink texture for the signature. And there are way, way more. And if any of these look cool to you, just remember that this is a tiny sampling of what's on webcomponents.org. And there are many more useful interoperable components. Anybody can get up there and publish an element. So anybody here, if you want to go home tonight and do that, it's open to you. And a big reason I really love webcomponents.org is because of that community-driven variety that only continues to grow and flourish, rich with web components of all types, because Polymer is just one way to build web components. It's that same philosophy which inspires our tooling team's commitment to building tools for all web components, not just those built with Polymer. Because it's 2017, and where would a web developer be without her trusty tools? I know that a lot of developers, including myself, have a love-hate relationship with tooling, so we make sure to make our tools as straightforward as possible so they really empower you while you're developing to be better. Two of our most popular tooling projects are IDE plugins and our CLI. And yes, they work for Polymer and vanilla web components. I'm not going to go into too much detail on these because we have a whole talk about this tomorrow. But real quick, our IDE plugins are awesome for Polymer and web component development. We have them for Adam and VS Code, and they include features like type-ahead completion, real-time linting, real-time error checking, and even inline documentation, so you can check out docs as you're typing to get reminded of different properties. We also have the Polymer CLI, which you can think of as your web component multi-tool or your Swiss Army knife. And it's simple, it's smart, it's got just a handful of really powerful commands that make building with web components smooth and efficient. So by using the Polymer CLI and all of the commands, you can get a web app template with a responsive design, client-side routing, and an automatically generated service worker with little to no effort on your part. Just a few command line scripts. So our CLI is built around the concept of taking all of the best practices of progressive web apps with web components and making them as simple and straightforward and accessible to achieve as possible. So I wanted to dive into one of our newest best practices that the CLI enables. How many of you are familiar with the purple pattern? Oh, awesome, awesome. So the purple pattern was designed by the Polymer team to promote efficient, scalable loading on client-side web apps. We introduced it last year, actually Kevin did, on the stage at IO, and we've seen it really take off since then. You'll hear a bunch of folks talking about it at IO, including Adi Asmani and Alex Russell, and it's pretty apt that Alex Russell talks about it. So some of you might be familiar with Alex Russell or slightly late on Twitter, but if not, know that he won, cares a lot about web performance, and two, is very active about that on Twitter. He's also an engineer on the Chrome team who sits just a few feet away from us, and us being on the same team does not make us immune to that. It actually makes us a really conveniently located audience. So in fact, it was one of our many performance discussions with Alex that led to the creation of the purple pattern. So you all have to him to thank for that. And even though we read it as purple, it has nothing to do with the color. It's just a really convenient acronym highlighting key loading techniques, and you can think of it a lot like Ajax, and that it doesn't specify one specific API that you must use, or a kind of a roadmap for how you should be building and loading. The first P stands for push, proactively delivering all of the resources necessary to satisfy our user's initial request, and you can do that using HTTP2 server push or preload. R is for render, render only the requested route, because the most important thing when loading is getting that initial critical view rendered and interactive. The next P stands for pre-cache. Pre-cache the resources necessary that a user might want to access later, and you can do this using a service worker, and that will keep you one step ahead of a user as they interact with your app. And L is for lazy load, which is how you'll be loading your code or your resources, whether that's from the cache or by making an additional network request. So this might seem like a lot to do, but with the power of the Polymer CLI, and mostly just the inherently granular, declarative and low-over nature of web components, we've done much of this grunt work and automated it away. So now getting started with purple is as simple as choosing a purple-ready app template, running a CLI command or two to let us analyze your dependency graph and generate a manifest, and then follow instructions to deploy to a serving environment, like Firebase or App Engine. That's it. And if you want to learn more about purple, you can go to the website. And that's the end of today's demo's end production today. Purple is actually being used in the most high-profile PWA on the web, Twitter Lite, Twitter's new progressive web experience. And Twitter Lite isn't even built with Polymer. It's just using these purple principles in action. But if you want to build purple experiences faster, we've got you covered with the Polymer App Toolbox and our Polymer App Toolbox sample apps. Polymer News is a full-featured, web app built using the Polymer App Toolbox. Along with a demo and all of the code, full documentation, outlining our design decisions, architecture choices, and even advanced features, like integration with AMP or how to include ads. All of that is outlined for you online. But that's not all our apps team has been working on. We tasked a few of the engineers to build something awesome out of the newest APIs. We challenged them to deliver a mobile web experience that you would only expect from native and, of course, do it in a fraction of the size. And they did. And they called it cheese. So let's take a look at the demo. When cheese opens up, it looks like a native app, but I can assure you it is a full web experience. It's got that jumping up and down button that says, say cheese at the bottom, encouraging you to either upload a photo or take a photo. So we're going to upload a photo. And the photo pops right onto the screen and you can see these beautiful CSS animations scanning the image for facial expressions and for a face. And then it jazzes up the photo with emoji, popping on eyes and silly hats, even gets your expression and replaces it with an emoji. It's pretty cool, yeah? And then you can even swipe through and find all of the other great things we've added. And when you find one you like, let's go all the way back. I think I like that first one a little bit. You can even move the emoji. So maybe we want to take the cheese off of Volgren's head and put it on a Frankie's because he looks pretty good with it. And then you can download the photo and share it with friends, share it with us on Twitter, share it later. And as you can see, our team, our family, our friends had a blast using cheese and Google's Vision APIs to jazz up our photos with emoji. You can check out Kevin's kids looking really great there, my dad blending in with some sheep in the top left. And it was really fun to use cheese, but Frankie, Volgren and Keanu who built it had such a great time building it because they got to use all the latest web technologies. They built a Polymer 2 ES6 class-based syntax progressive web app using purple pattern with H2 push on Firebase. All of that earned them 100 out of 100 on Lighthouse, which means it has offline support. And it uses Google's machine learning technology through the Vision API to power all of that, finding your expression, finding your eyes, your nose, and even cooler, it's got some great accessibility features. So it uses Google AI to read your image, figure out what's in it, and add an alt tag right on there so you can use voiceover and listen to what you took a photo of. It's pretty crazy. Here's the URL for cheese, cheese.polymer-project.org. We'd love to see your selfies, whether you're here at I.O. or watching somewhere around the world. And then you can share them with us on Twitter. See if you can come up with any crazy combinations. So that's everything. That's the Polymer 2.0 library built for platform-based interoperable web component development, webcomponents.org and our house-made Polymer elements all ported to hybrid mode, a suite of web component tooling with our CLI and our IDE plug-ins, the purple pattern for scalable, efficient loading, and the app toolbox and app toolbox reference implementation, Polymer News. This is our mission in action, bringing the future of web development into the present by enabling web developers to more easily lean on everything new and powerful the web platform has to offer. We are committed, as a team, to researching and developing better ways to leverage all of these new platform features. We're going to continue to advance our library and support developers and companies large and small that depend on us and will focus on spreading news and best practices to make sure that developers can build with the platform symbiotically for the long term. The future is here, and with all of the recent and revolutionary platform advancements, right now is a really awesome time to be a web developer. So we hope you enjoyed hearing all about the latest releases from Chrome's Polymer projects. There will be many, many more ways to learn about us all throughout I.O. In fact, this is our largest presence at I.O. yet. If you want to learn more, yeah. If you want to learn more about 2.0 and Alucard, you can check out Monica's talk Brighton Early 8.30 tomorrow on stage one. If you want to learn more about tools, you can check out Justin's talk tomorrow right here on this stage at 3.30. We've got refreshed brand new code labs. We've got onboarding material on our site. We're going to be in the web sandbox, and at office hours you can come talk to members of the team. Most excitingly, you'll have to make it to the after hours event tonight at 3.30. If you're at the Polymer Summit, you'll know about this, but it's a progressive web app where you can battle people head to head. And if you want to see even more about Polymer after I.O. is said and done, there's a full event dedicated to it, the Polymer Summit. And we're extremely excited to bring it back for a third time in Copenhagen. Woo! The summit will be in Copenhagen on August 22nd and 23rd. And this time we want to hear from you, so if you want to talk on stage at a Google Developer event, now is your chance. Go to this URL, g.co slash Polymer Summit 2017 to hear more about tickets, which are free as always, and updates. Hope to see you all there. That's all for us. If you have questions or just want to say hi, feel free to stop by. Thanks.