 All right. Good afternoon, everybody. My name is Taylor Savage. I'm the product manager here at Google on the Polymer project. So before we get started, how many people here are familiar with or have used Polymer or web components before to build a web? Wow, OK, awesome. So I don't have to do the talk anymore. It's great. So I've got a lot of exciting new features, a lot of exciting new products to talk about. But before we get started, I really want to begin at the beginning. We have one overarching goal on the Polymer project, which is to build the tools and libraries using the latest web platform features so that you, the developers, can build the next generation of web apps. And if you've been following web development, or if you were at the talk that came right before mine, you know that the next generation of web apps are here, and they're called progressive web apps. So the Polymer project's mission is to provide tools and libraries to make it easy to use these latest web platform features to build progressive web apps. But that's a little bit wordy for a mission statement. So let's make it a lot more concise. The Polymer project's mission is to use the platform to deliver great user experiences. And the key part here is to use the platform. On the Polymer project, we're not trying to build massive abstractions. We're not trying to build meta platforms. We're not trying to build mega frameworks. We're trying to let you, the developer, use what's cutting edge in the web platform itself so that you can focus instead of building massive tool chains, you can focus on just delivering great experiences to your users on the web. Now, as I'm sure you know, traditionally, the web platform hasn't been a great developer platform for delivering these kinds of immersive app-like experiences. The lowest level visual primitive that you get as a web developer is an HTML tag. And these HTML tags that you're provided from the browser for things like headings and paragraphs and lists were great for document markup. But they're not so great for constructing immersive app-like experiences. And over the last 20-plus years that HTML has existed, the language itself hasn't really evolved much. And user expectations have evolved significantly. What has evolved and what has gotten significantly more powerful is JavaScript. And so to create these app-like experiences on the mobile web, we've used JavaScript as an escape patch. We've built meta platforms completely separate from the web platform. We built JavaScript runtimes, mega frameworks, tool chains, all in JavaScript to allow us the developers to be able to deliver app-like experiences. And this might have been fine on desktop where we have big beefy machines connected by cables or Wi-Fi. But there's been a major change in the web, which is the mobile web. And the mobile web is incredibly powerful. You don't have to ask permission from anyone to publish your application to the web. And then nearly every single device out there is going to have a browser, and that user can access your application. That's awesome. But the mobile web has incredible reach, and it reaches into places where data connections are limited, where device hardware is limited. And for the next billion users coming online today, they typically have the worst combinations of both of these, slow data connections and slow hardware. And so building these towering meta-platforms all in JavaScript to deliver an app-like experience just doesn't fly on the mobile web. When flaky 3G connections are the norm, when slow CPUs are the norm, you need minimal overhead. You need minimal redundancy. You need maximal efficiency to be able to deliver that great experience. So what do we do? What do we do as web developers? How do we solve this new challenge of the mobile web? Well, the answer so far has been more JavaScript. We keep piling on more and more JavaScript to get this to the work, to the point where now we're running JavaScript on our servers so that we can render our application. We can get it in a state where we can send it down to the device so at least it can paint, and then we download more JavaScript so that it can rehydrate and boot up, and then finally it's interactive. And this is frustrating for users, and as I'm sure you're aware, it's frustrating for developers as well. We think there is a better solution, which is less JavaScript. Use the platform to build modern mobile web apps, use what's already there on your user's device, the browser. They have the vast majority of what they need to run your application, sitting there right on their device. Use it. And thanks to powerful new features baked into the web platform, this is increasingly possible. It's increasingly possible to, as a developer, construct these engaging immersive app-like experiences using what's baked into the browser. So again, on the Polymer project, we want to make it easy by building tools and libraries to leverage these new powerful features to build less lower overhead, higher quality applications. And so, so far, we've focused on two things on the Polymer project, using web components and building web components. So let's start with using web components. We want the browser itself to be more capable by introducing the notion of a standardized encapsulated component into the platform itself. The hardest part of building a web application today is just knowing where to start. And for just about any large application of any meaningful size, chances are the place to start is to pick a JavaScript framework. And by my last count, there are approximately 1 million JavaScript frameworks out there to choose from. And this is a really critical decision. It's gonna be before you write a line of code, you're probably gonna have to pick a JavaScript framework. And then every single line of code that you write from that point forward is gonna likely be directly tied to that decision, to that JavaScript framework that you picked. Now, JavaScript frameworks can be really, really powerful. They can give you very useful features for structuring large-scale applications, features like internationalization, make routing easier. And they can also provide a really convenient mental model to think about how you're building this application, make it easier as a developer to create that large-scale app. But there are a couple of very high costs to using a JavaScript framework or a meta-platform to build your application on the web. The first cost is a cost that your users pay. When you use a meta-platform, when you use this big-towering abstraction JavaScript, not only do you have to send down the code to actually run your application, but you need to send down all this JavaScript code to provide this meta-platform. And then you need to execute that platform code on the device before your actual application code can execute and make your app interactive. And again, this might have been fine on desktop with big, beefy machines, with cable connections, with Wi-Fi connections. But on mobile, slow, flaky, 3G connections of the norm, slow devices are the norm. And using these abstractions, your users pay the cost both in time that it takes to download the meta-platform onto their device and boot it up. And also, very literally, they pay the cost in their data plan of the extra hundreds of kilobytes or megabytes of JavaScript that has to be downloaded just so you can run your application on the web. And the second cost of these abstractions is a cost that you, the developer, pay. When you build a component in your web app, it's directly tied to the framework you chose. So no work you do for those components are useful in alternate frameworks. So if your next project, you're gonna choose a different JavaScript framework because a new one's come out, you have to throw away all that old component code that you've written. And if you're at a company with multiple teams and they all have slightly different stacks, slightly different framework stacks, you can't share components across teams using different stacks. So though there are many benefits to using a large meta-platform mega-framework, your users pay the cost of that abstraction and you, the developer, also pay the cost of that abstraction in terms of framework lock-in. What if there was a better way? Every single framework has a notion of an encapsulated component. What if rather than a framework having to provide that encapsulated component, the browser itself let you define your own components? And those components could work with any JavaScript framework that you might wanna use. And you could pick components off a shelf that other developers have built and open sourced that solve a problem that you're faced with to use in your own application. And the components would be compatible no matter what JavaScript stack you're using. This is the promise of web components. Web components are a new set of W3C standards, web-platform standards, that extend a native component model in the web platform itself. Because the web already has a component model baked in, the DOM, the DOM has DOM nodes, which you can call methods on, which have properties and can send DOM events. And they have a declarative way to construct that DOM with the HTML language. But the problem is HTML is fixed. And with web components, you can extend the language of HTML itself by creating new elements that you can then use in your application encapsulated reusable components without the cost of this framework overhead. And what's great is with web components, HTML becomes your interoperability layer. Every single framework, if it has to have an application run on the web platform, at the end of the day, has to speak HTML. It's the lowest level of visual primitive of the web. And a web component essentially becomes another HTML tag, just like your divs, your P's, your LIs. And so now that we can extend HTML, now that we can create our own HTML tags, we can then reuse them, regardless of what JavaScript stack we're using. So one challenge is, as many of you know, if you've been following the web component standards, it's taken a long time. So the very first version of this web component spec came out in 2012, almost four years ago, to the day. And these specs have gone through many changes, and this is just the nature of standards work. It's the nature of spec work. But I'm extremely excited that today, thanks to broad cross-browser collaboration, we are in the home stretch for web component support. So web components is really an umbrella term for these four lower-level primitives, template, HTML imports, custom elements, and Shadow DOM. Template elements are broadly shipped cross-browser. HTML imports are shipped in Chrome, and others are pending ES6 module shipping. But custom elements and Shadow DOM, these are really the two most powerful primitives to let you extend HTML, let you create your own web components. And again, thanks to broad cross-browser collaboration from all the major browser vendors, custom elements and Shadow DOM specs just hit a major milestone with V1. So V1 is the latest iteration of these two specs. Why V1? We like to index by zero in spec land. I'm not really sure. But most importantly, all major browser vendors are on board with driving implementations of these V1 specs. Firefox, Edge, Safari, Chrome, were all the table all involved with the spec discussions to get to this point with these V1 versions. It's a high priority roadmap item for the Edge team to implement. Firefox and Chrome implementations of V1 are already well underway, and Safari already has working versions of V1, Shadow DOM and custom elements in their nightly builds. So with web components right around the corner and using the polyfills that already exist today to use these features, many major companies are already using web components in production. GitHub today uses custom elements for all of its timestamps and emoji across the site. And Twitter just announced that they'll be using Shadow DOM for all of their embedded tweets rather than the much heavier weight iFrames, because Shadow DOM provides a very nice encapsulation for these embedded tweets. And the ecosystem around building these web components is already starting to accelerate and take off. Custom elements.io, which is a major aggregator, a community-driven aggregator of web components built by developers all across the world, already has 2,000 components on it, written by over 800 authors and more are being added every single day. So browsers are actively building support for web components. Major sites are already using web components in production. The ecosystem is already beginning to flourish. Broad native web component browser support is no longer a matter of if, but a matter of when. And when could be as soon as later this year? So in the past, when we've talked about, yeah. In the past when we've talked about web components here at I.O., they certainly have been on the bleeding edge of web development. And now web components are just on the leading edge of web development. So as you saw, web components are actually four lower-level specs, and they're great and they're great to use, but they can be a little hard to figure out how to actually build and encapsulate a web component. So we built the Polymer Library to make it easier to use these four specs together to create your own web components. We first announced the developer preview of the Polymer Library two years ago at Google I.O., and this was very much an experiment. We were trying to see we were working off early versions of the web component specs. Would it be possible to tie these four low-level specs together to make it easy for developers to create reusable components? And the answer was yes, but it needs to be faster. So last year at Google I.O., we announced Polymer 1.0. And this was a huge step forward. It was a ground-up rewrite of the library focused on making it fast, making it lean, making it ready to use in production. And it was significantly faster, three to four times faster than the developer preview version for element construction. And with 1.0, we wanted to show the web component promise was not just theoretical, but you could actually use web components in production today. Since this 1.0 launch, the library has seen many, many new features and enhancements, and it's gotten even faster. So since this 1.0 release, which itself was three to four times faster than the original developer preview, the latest version of Polymer is now another 10% faster on Safari and another 25% faster on Chrome for element construction. So everything we do with Polymer, we build it open source first on GitHub out in the open, and then we pull the latest releases into Google's internal version control system so Google teams can use Polymer for their applications. And despite this hurdle, Google is, I mean, Polymer is one of the fastest growing front-end technologies within Google. Over 400 Google projects today are using Polymer with over 4,000 unique components built by Google teams to use in their products. And Polymer is already launched in production across major Google properties, including Chrome, Translate, Play Music, YouTube Gaming, Google Fi, and of course, the Google IOW web app, which I'm sure you're all familiar with. So you can see how serious a strategic initiative Polymer is for Google and that it's already being served in production to over a billion users on Google products. And not only that, Polymer's being used outside of Google by companies big and small. In fact, Polymer adoption in the wild has quietly skyrocketed. There are over four million web pages now using Polymer on the open web. And many large companies are investing heavily in Polymer and web components for the future of their front-end stacks. And I wanna talk about a couple of these companies today. The first is Netaporte. And Netaporte is a global leader in online luxury fashion. The Netaporte engineering team actually first discovered Polymer at Google IOW a year ago. And since then started replacing individual pieces of their products with Polymer elements. And now today, they have a complete life cycle, an end-to-end life cycle for all the components that they use across all their different sites and pages. They have their own custom Yeoman generator for generating Netaporte flavored Polymer components. They generate documentation for all of these components to make it really easy for engineers across the team to reuse components that other engineers have built. They run integration tests, end-to-end tests for every commit to every component across all the different browsers that they support. And then they use these components across all these different pages across the Netaporte site, which allows them both to have visual consistency because it's the very same components and functional consistency. And this has made it much easier for the Netaporte team to scale this very large multifaceted site by reusing the very same components. The second company I wanna talk about that's using Polymer is BBVA. And BBVA is a multinational banking group operates in 35 countries, 130,000 employees, 66 million customers. And you can imagine that with such a massive operation in so many different countries, they're gonna have many, many different types of applications to build. And so rather than building a native app, a unique one-off native app every single time, they switched to using all web technology based on Polymer, based on web components. And so they have this internal catalog of all the different components that all their different teams use and build so that they can, instead of building one-off applications, can take components from this catalog to assemble applications. And when I say assemble, I really mean assemble. Web components lend themselves extremely nicely to drag and drop whizzy-wig-type construction experiences. And so they've built these sorts of tools to visually create and construct and assemble applications out of the components that they've built. And this ease of application creation has had a very tangible benefit on their business. For the first project that they switched to Polymer web components, they saved 70% budget and 50% time, and their engineering efforts are significantly more scalable and easier to manage. So in short, since 1.0, Polymer has become faster, more feature-rich. It's seeing exponential growth here within Google, served to over a billion users, and major companies are investing in Polymer and web components. So the Polymer library is for building components. Major companies, major Google products are adopting these components in building components. But they're not just building components. They're building applications out of these components. And so we get this question asked a lot, okay, web components are great, but how do I take these web components and then construct an actual application? And our answer has always been, well, you know, components can be arbitrarily complex. You can build a component out of other components, out of other components, out of components, out of components in yada, yada, yada, and you've got an app. But of course, that's not a very satisfying answer. Developers wanted more guidance on how to put these components together in a platform idiomatic way. And so recently, as the team has been growing, as the project has been growing, we've expanded our focus a bit to think not just about how to build web components, but then also how to take these web components and build full-fledged, cutting-edge mobile web applications. And of course, not just any kind of web application, but progressive web applications, applications that took all the right vitamins. And of course, we don't just want to help build progressive web applications. We want to help build great progressive web applications, great user experiences. So how do you do this? How do you build a great progressive web app on the mobile web with all of the challenges that that entails? And of course, our answer is to use the platform. Use the platform to build great apps. Use what the browser gives you to achieve minimal payload, minimal overhead, design offline first. And this is a hard challenge. And so we wanted to make this easier to use the platform to build cutting-edge progressive web applications. So I'm really excited today to announce the Polymer App Toolbox. And the toolbox is just a set of components and tools based around web platform primitives that make it easy to build cutting-edge progressive web applications. So what's in the toolbox? Well, all the things you'd expect to build a large-scale progressive web app. Components for layout, for routing, for localization, for storage, and then a command-line tool to tie it all together. So let's go through each of these one at a time. The first is layout. All UI design begins with layout. It's the visual structure that makes up your application and a high-quality immersive mobile app requires high-quality app structure. It requires that app-like look and feel that users have come to expect on their mobile devices. And those high-quality layout components, things like toolbars that'll disappear when you scroll down and reappear when you scroll back up, or a drawer that'll open and then you can swipe it closed with momentum, these are components that don't exist in HTML. There are no HTML tags for a responsive drawer. So we built it using the Polymer Library, the app layout elements. An app layout has a number of UI components to make it easier to structure these mobile app-like experiences. And they're designed to be flexible, responsive, and fast. So app layout elements contain components for things like toolbars, and drawers, and headers. They're flexible, they're not visually opinionated, so you can use them regardless of what your application looks like. They're responsive by default, so they work across all different screen sizes. They make easy, they make hard things easy, things like these fancy scroll behaviors that users have come to expect on their mobile devices. And they also critically help ensure accessibility, which is a crucial feature for any application that you're gonna build. So let's take a look at a couple of these components. So here's a really simple example of using the app layout components. This is a basic app drawer layout. You have a drawer to the left and then you have this middle section content that scrolls. The drawer opens and closes with momentum, you can swipe it closed. And then you've got this header layout section, which is this main content section that the user can scroll through. And this is all done declaratively in markup, but you're just writing HTML using these web components. And I wanna draw your attention to these two properties, these two attributes, on the app header, fixed and effects. Fix says, I want this toolbar across the top to remain fixed as the user scrolls. And the waterfall effect says, I want a little shadow to appear underneath the toolbar when the user scrolls down and when they get back to the top, make that shadow disappear. So it looks like the content is water falling out from under the toolbar. Really nice, just little subtle user experiences that make it feel like a top quality application. But you can get more complicated with the app layout components. Here's a very similar example, a little more markup. And we have a few more attributes on the app header here. The first is condenses. So as you can see, when you get to the top, the header is expanded and large and it condenses as the user scrolls down. Reveal says, when the user scrolls down below the header, hide that header and then if they scroll up slightly, show that header again. And then the waterfall effect of the same one makes it feel like the content is water falling out. So really subtle polish that makes it just look and feel like a first class progressive mobile web app. And as you can imagine, there are lots of different combinations for these different attributes. And so we built a demo called Test Drive that lets you try out these combinations, literally tick off the boxes and then experience what that would feel like in an application right there. And of course, the app layout components are totally pluggable. So any animation that we provide, if you don't like it, you can easily build your own and plug it in to the app layout components and get a completely custom looking feel. Okay, great. We can layout our application. What if we want multiple views? How do we route between multiple views? This is a very common question that we've gotten. What router should I use? And we've always said, they're just web components. Use whatever router you want. There are tons of JavaScript routers out there. But we surveyed the router space and we realized that most JavaScript routers have this singular global view of the world, all the different routes that you're gonna have in your application and the corresponding views that those routes are gonna show. And we wanted to build a router that didn't just work with web components, but that worked like web components and that it was modular and composable, that it could route from an entire application all the way down to a single component. So we built the app route component. Let's say you wanted to build a typical application. You've got three routes, slash, slash item, slash cart, and you want a route between these different views. You could use the app route component to have a path that will match on the route. It will provide a property saying whether that path is active or not, and you can very easily toggle on and off different views in your application. But it can get a little more complicated than that. Let's say you wanted to extract data from that URL, from that route. So you have slash, slash detail, slash item, slash detail, slash item ID, and you want to extract that item ID value to then use in your application. App route lets you do that with this colon syntax, and it provides the value of that item ID just as a property on the DOM node. And what's cool about app route is you could have this at the top of your document, you could have it globally like a typical router, or you could compose this app route into the component that's responsible for showing this detail view. And so you can delegate the responsibility of deciding how to use this item ID value to the component that actually is gonna show that view. So the app route, it's flexible, it's modular, it's composable. It doesn't just work with web components, it works like web components. It can know about your entire app, or it can just be responsible for routing one small section of your application. Okay, that's great. We can lay out our application, we can route between different views. What if we want to localize our UI? What if we want to translate it into different languages? Again, very common question, and we've always said, they're just web components. There are a million ways to localize an app. Use whatever one is most appropriate for what you're building. But we wanted to build an idiomatic platform embracing way to localize applications. So we built the app localized behavior. And what's great about the app localized behavior is it uses the platform. It uses the Intel object, which is a standard JavaScript object to provide localization data, and it's broadly cross-browser supported. And where it isn't supported, there's a polyfill. And so to use the app localized behavior, you use it in any Polymer component that's gonna be responsible for translating strings. So if you are familiar with Polymer and building web components using Polymer, you'll, this will be very familiar syntax to you. To use app localized behavior, you add it as a behavior to your component, and then you give it two properties. The first is a language property, which will be the language that you want this component to be translated to. And of course we have it statically defined here, but you could very easily bind to it to dynamically switch it. And then we're gonna give it this resources property, which is gonna be all the different keys and translation strings that we're gonna need for this particular component. And of course here again, it's statically defined, but we could easily fetch this off the network, we could have it globally on our window object, however we wanna provide this resources to the component. And then to use these resources to localize the component, anywhere we have a string, instead of that static string, we're gonna bind to this localize function, we're gonna pass it a key, and any variables, any content that's actually gonna need to be in that string. And so what you can achieve with this, is you can translate simple strings with string replacement, but you can also localize currencies, and numbers, and dates, and it even supports plurals and genders. So a very simple tool that uses the platform to elegantly solve very complex use cases. Okay, we can, yeah. So we're doing great. We can layout our application, we can route between views, we can localize each of those views. Now let's say we wanna store data, and we wanna store data in the cloud or locally on the device to then use in our application. Again, very similar conundrum. How do I connect data to my app? There are a million ways. Well, they're just web components. And again, we wanted to provide a platform idiomatic way to take data from the cloud, from locally on the device, provide it to an application in a platform idiomatic way. So we built app storage. And what app storage is, is it's essentially an interface that allows you, the developer, to create your own web component to connect data from any service, whether it's in the cloud, whether it's on the device, and service that data in a way that your app can use. And the way app storage services the data is in a very platform idiomatic way. That data is serviced just as a property on the DOM node. And any changes to that data are expressed as DOM events. And conveniently, that's exactly how Polymer's own data binding system works. Very much uses the platform. It's what's available there in the platform. And so app storage provides turnkey integration with Polymer's own data binding system. So let's give it an example of how you might use this. Say you're building a note-taking progressive web app. You're gonna wanna launch it from your home screen because of course it's a progressive web app. You can add titles to your notes. You can add information and details to your notes. And all of this data you're gonna store in a REST API that you've built in the cloud. But of course it's a progressive web app. So it needs to be able to work offline. So if we go offline, launch it from our home screen, if we're just relying on getting the data from our REST API, we're not gonna be able to launch the data, launch the application at all. We're not gonna have access to the internet to launch that application. But app storage makes it very easy to architect your app so that you can support this use case very simply. So here's how we're gonna build it. You're gonna build your own component that implements this app storage interface, your cloud API component, and that's gonna manage communicating with your REST API in the cloud. And then you're gonna use a component app index DB mirror that we've provided as part of the app storage components. And what that does is take any data that's passed through it and it mirrors it into a local index DB instance. And then that's gonna pass data into your application. So here's how it looks when all the data is wired up. When you're online, your cloud API component has no problem interfacing with your API, with your REST API, it's gonna pipe that data through this index DB mirror component, which is then gonna pipe the data to your app. So you're online, all's well and good. When you go offline, your cloud API component can no longer communicate with its REST endpoint. But since we've been piping all of that data through the app index DB mirror component, we have all of that locally stored in an index DB instance on our device. And so we can boot up our application, even when we're offline. But what if you don't wanna build your own component? What if you don't wanna build your own REST API to manage the data? What if you wanted to use, say, a database as a service in the cloud? Well, fortunately, there's an element for that. The app storage element with PolymerFire. So PolymerFire is actually a set of Polymer-based web components that the Firebase team has built that makes it trivial to communicate with a Firebase database instance and to use that data in your application. Okay, we're doing great. We can layout our application. We can route between different views. We can localize those views. We can communicate with a backend and stored data. But we still need to deliver this application to our users. And remember, this is the mobile web. Flakey 3G connections of the norm, slow devices of the norm. We need minimal payload. We need minimal JavaScript. We need maximum among efficiency to be able to minimize the time to first meaningful interaction for our users. And this is the great challenge. How do you minimize that time to first meaningful interaction? So there's the hard way. We can use the same old JavaScript escape hatches. We can build a massive tool chain with heaps of JavaScript. We can server-side render. We can get a fast first paint with our server-side rendered app and then download the meta platform and then boot it up and then make it interactive. But it's frustrating for a user to sit there watching a splash screen. And it's even more frustrating as a developer to jump through all these hoops to server-side render so at the end of the day, only really have generated a splash screen or a spinner. And time to first splash screen, time to first spinner is not the same thing as time to first meaningful interaction. So server-side rendering like this to deliver an application, whether you get an app viewer or a spinner is really a Potemkin village. Your user still has to wait for your abstraction to load before your application is useful. We think there is a better way, which is to use the platform to deliver apps. The tighter the platform, you can build your application the faster it's going to be, especially on slow networks and on slow devices. Let the browser be your application. And thanks to brand new web platform primitives, we can throw out a lot of the old knowledge about how to make an application fast on mobile and embrace new primitives and technologies that the browser provides. So there are really three important primitives for delivering a modern mobile application. Web components, which allow you to construct your application out of these granular dependencies, out of these granular components. HTTP 2 and server push, which allows you to serve these granular dependencies in a granular way to your users without incurring massive round trips and to most efficiently utilize the bandwidth. And then service worker, which lets you reliably cache these granular components on your user's device. So let's take a look at how these three primitives work together really nicely. So let's say we're building an app, we've built this app before. We have three routes slash slash items and slash cart. Each has a view, they share some similar UI between the views. If we built this the old way as an old school single page app, for each of these views, no matter what route the user hit, we'd have this monolithic index HTML, this monolithic app.js, this monolithic framework and a CSS file. We'd send all of them down to the client. And then on the client, the framework would have to boot up, then the application would have to boot up, then it would have to match the route to the view and then it would have to render that view. Obviously very slow, obviously very inefficient. But let's take a step back. We have three views here. Some are independent, some overlap in terms of what they actually show on the screen. Let's use the platform to serve this application as efficiently as possible. So let's split the view down. Let's break it down into individual web components. Some of these components are gonna be shared between views. Some are gonna be unique to a particular view. Let's say the user requests this slash route. The server can know exactly what components are needed in order to render that view and to make it usable on the device. And so the server can use HTTP2 and server push to push down exactly the minimal dependencies, the minimal components that are needed to make that route, to make that view interactive without multiple round trips. And then we have that there on our device that the user can start interacting with with minimal overhead. And not only that, we can take those granular components and we can stick them in the service worker cache. And then in the background, as the user is interacting with that first view, the service worker can start fetching additional granular components from the network and pre-cache those. It can get those from the network and stick those two in its service worker cache so that if the user then navigates to the next view, slash items, there's a good chance that you'll already have every single component that you need to render that view and make it interactive already right there sitting in your cache. You don't have to go to the network at all. But of course, it's not practical to necessarily cache every single dependency for your entire application. So for future views, you can lazily load and lazily instantiate additional components that you need to render those views. And of course, some of those might already be sitting there right in your cache. And for those that aren't, you can use the server to push down only the minimal set of dependencies that the user doesn't already have in their cache. So there's a pattern starting to emerge here. You push components that are needed for your initial route. You render that initial route and make it interactive as soon as possible. You pre-cache in the background using service worker additional components needed for remaining routes. And then you lazy load and create future routes on demand as the user navigates to them. And we really like acronyms on the Polymer project. So we've been calling this the purple pattern. And the purple pattern is not Polymer specific. It's just a pattern for progressively loading and rendering a modern progressive web app using these new technologies and primitives in the web platform. So with the purple pattern, you get minimal payload, minimal overhead, minimal time to first interaction and an optimal user experience. And the crux of this purple pattern is the ability to break up your application into individual granular components that require minimal overhead themselves to boot up. And that's exactly what web components provides. So now that we're armed with the purple pattern and we've built our app, how do we apply it to our own progressive web app that we're building with the app toolbox? Now there are a lot of different tools for building and optimizing component-based applications. And we wanted a maximally simple tool to make it easy to get started building an application using this pattern to develop and then ultimately to build and deploy it. And so we built the Polymer CLI, the Polymer command line tool. And the goal of the Polymer CLI is to stay focused and simple. It provides just a few set of commands that can help support you throughout the entire development experience, whether you're building a Polymer component or whether you're building an entire application out of web components. So this includes Polymer and NIT, which makes it really easy to scaffold out an initial web component or an entire application built out of these web components. And it'll set up the folder structure that you need for each of these two. And we've also built a set of starter templates to get you started with different types of applications that you might wanna build. Polymer Serve will locally serve your application or your component so that you can play with it as you develop. And what's cool about Polymer Serve is that not only will it serve your component, your application, it will also serve all of the documentation automatically generated from all the components that you're using to build your application. So you can develop, and on a second browser tab, you can have all the documentation for the components you're using to develop. So it's a really great experience. Polymer Lint will lint your code and check for common errors that occur when you're building with web components in Polymer. And then Polymer Build will let us specify a main entry point and then an application shell. And it will generate a bundled and unbundled version of your application that you can then serve. The unbundled version is perfect for serving with the purple pattern. It keeps those dependencies granular so that you can use the purple pattern to send them down efficiently. But we also generate a bundled version for a fallback for browsers that don't yet support HTTP2. And Polymer Build also uses a tool called Service Worker Precache to generate these service workers that do this precaching, prefetching, and sticking these components in the cache for you so that if you don't want to, you don't have to write a line of service worker code. All of this is generated for you based on your application. So that's the toolbox. Layout, routing, localization, storage, and a command line tool to tie it all together. And you might be thinking, didn't we just build another stack? Didn't we just build another monolithic stack? But this stack is different. In fact, it's not a stack at all. It is just a set of loosely-coupled, interoperable web components that can be used piecemeal, individually, or altogether, and it's not a monolith. And each of these components is just a lightweight layer on top of platform primitives that already exist right there in the browser. So with the Polymer app toolbox, we're showing that you don't need a massive meta-platform. You don't need a massive mega-framework. You don't need an alternate platform to build a high-quality mobile web allocation. You don't need tons of JavaScript. You don't need a crazy complex tool chain to serve it. You just need to use the platform and use all the modern primitives that the web platform provides. Now, of course, we didn't want this to just be a theoretical exercise. So we built an app using all of these techniques. We call it shop. It's an e-commerce-type application. It doesn't actually sell Google Gear, so you can't check out and buy anything, so don't expect anything to show up at your door. But it's got all the views for a typical e-commerce app. It's got a main splash page homepage. It's got a product listing view. It's got individual product pages, and it's got a cart and a checkout flow. And it's built and served using all of these components, using all of these patterns. Web Components, Service Worker, HTTP2, and the purple pattern. And it uses Polymer and the app elements and the Polymer CLI to develop and build. So you can check out this demo as well as everything that's in the toolbox and documentation about all the things that are in the toolbox at the brand-new Polymer documentation site, www.polymerproject.org. So in summary, the Polymer project's approach to modern web development is different. It's different than that of a typical JavaScript framework because it uses the platform. It uses what's already there in users' browsers rather than creating massive abstractions on top. And why is it important to use the platform for performance on mobile? And thanks to these new powerful web platform primitives, this is finally possible. This is finally possible as web developers to create these kinds of engaging, immersive app-like experiences on the mobile web. And so the result of using the platform is a first-class progressive web app built out of interoperable web components. So if you'd like to learn more about Polymer or web components or the purple pattern, there are tons more talks here at Google I.O. about exactly this. Progressive Performance Polymer is right after this one and there's another two more tomorrow. And if you have a time machine or a YouTube, you can check out the talks that have already happened earlier. So I'm really excited by this. I hope you are too. And if you'd like to learn more about Polymer, about progressive web apps, about the purple pattern, there's a conference for that. The next Polymer Summit, which will be later this year in London. So you can sign up at this link to be notified when registration opens. If it's anything like last year's Polymer Summit that we held in Amsterdam, it's gonna be awesome. There were 800 developers in a beautiful venue. It was a full day of talks and night of code labs and I'm really excited to do it all again. So that's all for today. I hope to see you at the Polymer Summit and remember, use the platform. Thank you.