 My name's Taylor Savage. I'm the product manager of the Polymer team here at Google. And I'm going to talk a little bit about Polymer. So it's become a bit of a tradition now at Chrome Dev Summit to give a Polymer state of the union. So this is that talk. So Polymer is, for those who don't know, the web developer library that we build on the Chrome open web platform team here at Google. It's a lightweight wrapper on top of the web components APIs the library is. And we also build a whole bunch of components on top of that library. So I'll talk a little bit about where Polymer has come since one year ago at Chrome Dev Summit last year. Kind of the general state of web components, which are these really fundamental APIs that Polymer leverages heavily. And then where we're headed, where the Polymer library, where the broader Polymer project overall is headed in the near future. So let's roll back the clock a little bit. One year ago, this very conference, Chrome Dev Summit, Matt McNulty, who's the Polymer engineering lead, got up and announced a kind of a major new evolution in the Polymer library. So up until that point, Polymer was very much kind of an experimental library. It was all about experimenting with these new web components APIs, seeing what worked, seeing what didn't work, trying to build a developer wrapper around web components to make sure that it was something that both worked in the browser and also was something that developers could use and that were actually useful for building applications. And so what Matt announced a year ago at Chrome Dev Summit was Polymer 0.8. And Polymer 0.8 was a shift away from this experimental mode because we had realized that we were actually onto something here. Web components were pretty stable and solid and great. And this library was something that could actually be useful. So we shifted away from experimenting and towards building something that you could actually use in production. So the goal was to kind of balance and make trade-offs in keeping some of the great ergonomics and the great productivity gains that we had achieved with the experimental 0.5 version of Polymer. But also make it fast enough and radically less complex to be something that you could actually ship in production. So 0.8 we released around this time a year ago. Major step forward. Still needed some time to bake. And at Google I.O. this past May, we announced Polymer 1.0. And this was the big production-ready release of the Polymer library. So Polymer 1.0 was essentially a ground-up rewrite of Polymer, again trying to maintain the same great ergonomics that Polymer had evolved over time, but under the hood, kind of radically redesigning and simplifying everything to make it fast. So we redesigned the data-binding system, rebuilt it from the ground up to be much more direct. Introduced a whole new styling system to be able to pierce through shutter routes when you're building these components based on web components that was much more idiomatic and kind of the right trade-off in terms of developer handles, but also encapsulation. And we also included a lightweight Shatterdom shim called Shadydom, rather than relying on the full heavyweight, but a little over-heavyweight Shatterdom polyfill. So all of these things together made for a much faster production-ready library. And at that time, a number of products that Google launched with using Polymer, using this library in production. So how much faster was Polymer 1.0 from 0.5? Quite a bit. It was three times faster on Chrome, four times faster on Safari. It was also smaller. So it was also 36% smaller, the 0.5. So this is a major step forward for the Polymer library. It was also a major step forward for everything that we build on top of the Polymer library. So the Polymer team, in addition to working on this library, built sets of components. And traditionally, we had just had two kind of component sets. With Polymer 1.0, we dramatically expanded the scope of that to include five element product lines, as we call them. The iron elements, and these are elements that are built on top of the Polymer library easier for developers to build applications on the web, leveraging web components. So iron elements were kind of the basic building blocks for what you might need to build an application. The paper elements were the reference implementation for material design. So these are all the components, the buttons, and the ripples, and the dropdowns, and the menus that you use to implement Google's material design language on a web application. And I want to take the opportunity to make totally clear Polymer is a web components library. But building with Polymer, we've created these paper elements, which these represent material design. So Polymer is not material design. Polymer is a web developer library. But we do ship these paper elements to help developers as one of many of our element product lines for material design. We also ship the gold elements. So these were a small set of elements for building good e-commerce checkout flows on the web. So things like auto-completing credit card fields with the right markup under the hood, auto-validating zip codes, and locations, and phone number fields to make it really easy to build a great checkout form or a great e-commerce type form. We also ship the Google web components. So these are wrappers around some of the APIs that various Google projects provide, things like Google Maps and Google Drive and YouTube. And instead of, we take the imperative JavaScript APIs that these products provide and wrap them in a component so that you can use these declaratively on your page, just like any other element. So this includes the Google Maps element, for example, which you can just put on your page and it renders a Google Map. And finally, we announced the Platinum Elements. So these were wrappers around Service Worker. And you've heard a lot about Service Worker today and all the amazing things that it can do. So the Platinum Elements are wrappers around a lot of these Service Worker features to make it easier to leverage those in your application, again declaratively, using the typical element syntax you're used to. And these let you develop a progressive web app using declarative components. So really exciting stuff with the Polymer 1.0 announcement, huge step forward for the library, huge step forward for the element product lines. But what about web components? So Polymer 1.0 was production ready. A number of Google products and products that other companies were building are using it in production. But it could be even awesomer. It could be faster. And with that true encapsulation, to really get true encapsulation and true reusability of these components, you need web components shipped broadly across browsers to really realize the potential that web components have. So where are we with web components? And I'm very happy to say, if you take nothing away from this talk, please take this away, web components are happening. Incredibly exciting. They've been in the works for a long time. But in just the last six months, we've seen incredible movement across all the different browser vendors towards shipping web components. So a little bit of a highlight reel here of what we've seen. This was a blog post from the Edge team. We are happy to announce that we are starting development to add HTML template element support to Microsoft Edge 2D. Today, this is just the beginning of our web components journey. Following template support, and after completing the DOM reread, the next goal is to implement Shadow DOM. And I'm very happy to say that Edge actually shipped template just a week ago. So they are already shipping web components. Super exciting. Great progress being made on the Edge team. They're doing some great work. Firefox Mozilla had this blog post not that long ago. Web components have been in planning for over three years, but we're optimistic the end is near. All major browser vendors are on board, enthusiastic, and investing significant time to help resolve the remaining issues. Let's get ready to componentize the web. And then finally, WebKit. So WebKit just recently announced they are shipping the new Shadow DOM slot-based V1 API in WebKit Nightly. So you can actually play with this today in Safari. It's out there in the Nightly build of this. Incredibly exciting work that the WebKit team has done with the Shadow DOM V1 API. On the Polymer team, we will soon be shipping an experimental version of this V1 slot-based API in our Shady DOM polyfill so you can start playing with it and getting to feel the ergonomics before it actually, the Shadow DOM V1 slot-based rolls out broadly. So we want to give lots of time to prepare. But incredibly exciting work being done across all these different browser vendors. Web components are actually here. It's going to be not too long, and we'll be able to have polyfills be the exception and not the norm. So incredibly excited by all this progress. So web components have come a long way. Polymers come a long way. We've seen a really great adoption of the Polymer library just since the 1.0 release three or four months ago. So Polymer in the wild, over a million web pages are now using Polymer on the current web. We had polytechnics all around the world run by our incredible Polytechnic organizers. These are events to learn all about Polymer and build with Polymer literally every single continent except Antarctica that we had a Polytechnic event on. So incredibly exciting. And we've also seen some major companies really adopting and leveraging Polymer web components in super interesting ways. So I want to talk a little about a few specific limitations that I think reflect the diversity of application that you can have with Polymer web components. So the first I want to talk about is GE. So GE's Predix platform. It's a cloud platform that you can kind of think of as the operating system for the industrial internet of things. So imagine that you have a wind farm of wind turbines, and they're all generating data, and all that data is getting piped back in to the Predix engine on the cloud, and you need a way to visualize all of this data that's coming in. And so what GE has built is a set of components using Polymer to be able to easily put together dashboards to be able to understand and visualize the data that's coming in. So awesome application. So a whole bunch of different components that can be pieced together to create a variety of different interfaces on these dashboards. And you get all this information about your industrial internet of things just at a glance. So really perfect use case for these components and a great application of it. An industrial level scale that's deploying Polymer. The second company that I want to talk about is Netaporte. So they are a major e-commerce company. And they've done some awesome work using Polymer on their product pages. So a company like Netaporte, where you have a whole bunch of different products and a whole bunch of different product pages, and all the product pages are going to be slightly different. Some are going to have color swatches, some are going to have to have size drop downs, some are going to have additional information, some are going to have also goes with sections. And they built each of these as a component, as a Polymer component. And so they can just put together these product pages out of these components. And all of these components are also naturally responsive. So this same site works great on desktop. It works great on mobile. And it's a really great deployment of Polymer at scale and to really leverage building and sharing and using these components across all their different product pages on the site. And then finally, Sumo. So Sumo, we've talked about a little bit at Japanese real estate company that's really on the cutting edge in terms of the web platform. They built some awesome stuff. They are just releasing today a mortgage interest simulator that's built in Polymer. So this is just a great example of a really immersive app that feels great, that works on the web. You can put in all the different variables around your mortgage and get what your payments would look like. So it's just a great material design app that uses all the Polymer components and has a great interface and works great on mobile. So really awesome work there. So the broad spectrum from shared components to build dashboards to actually deployments on an e-commerce site to just building a really great end to end app with Polymer. We're excited to see all of this uptake externally in the ecosystem. We're also really excited to see uptake internally here at Google. So here at Google, over 320 projects are using Polymer internally. And that number is just growing every single day. We've seen some major Google products launch with Polymer 1.0 just in the last four months that it's been out that are leveraging it at scale in production. These include products like YouTube Gaming. So this was a major launch not that long ago. This has built Polymer end to end. Every single component that you can see on that screen is a Polymer component just about. And they use this to structure their application and get these really nice effects and really nice transitions. Similarly, Google Play Music. So this uses a lot of the paper elements to get that nice material design application feel. You can see the ripples and the drawer panels. And this uses Polymer to structure the application as well. Google Patents, a really snappy application of Polymer just to be able to search patents and read information about each patent. Of course, the Google I.O. website, which was kind of a progressive web app before that term came about, it was at the Google I.O. conference this last year, built in Polymer. And this Chrome Dev Summit website for the conference you got right now, also built in Polymer. And there are so many major Google products that are also using Polymer that haven't launched just quite yet that I can't talk about today, but we're incredibly excited for those to launch as well. They also had the first ever Polymer Developer Summit in Amsterdam. That video of the building with the big Polymer logo on the front was not Photoshop. That was real. It's a major building on the river in Amsterdam. Just an incredible venue, an awesome event. We had 800 engineers there from all over the world who were interested in Polymer and learning about Polymer. Day to day, a whole full day of talks, a night of code labs, all of those talks we recorded, and they're all up on YouTube. It's a great resource. We kind of go end to end from start to finish, how you might build a component, how you might assemble components into an application. If you're interested to learn more about Polymer and how you can use Polymer and build applications with Polymer, the videos from the Polymer Summit are a really great resource. So of course, the core Polymer team did not just give up and declare victory at 1.0 and leave and quit. No, very far from that. So we've been working really, really hard to continually improve the library and all the elements that we're building. And kind of the two pillars are two core values that we think about. When we're building Polymer and we're building components, everything that we're building on the team are ergonomics and performance. So ergonomics, how easy is it to build a component using Polymer? How easy is it to build a good component that you can compose with other components that you can compose into an application using Polymer? And then performance, how fast can you build something with Polymer? How fast is your end-resulting app when you've built it in an idiomatic way with Polymer? And so these things seem like they're a little bit of a trade-off, and they certainly are. We're always balancing. We want to improve both ergonomics and performance while we're thinking about new things we want to build and ways to improve the library and components. On the ergonomic side, since Polymer 1.0, we've shipped a number of new features with the library, some of these very major features, things like compound binding, things like distributed children changes for an element, ways to share style sheets between components, a whole set of features to make it easier to build components using Polymer. But we have this mantra on the team, which is that every feature has a cost. Whenever you add a feature, you're adding some level of abstraction away from the platform, just naturally. And so there's always going to be a cost to adding that feature. So whenever we're thinking about implementing a new feature, adding it to the library, we're thinking what cost are we transferring on to our developers when we add this feature? So this is the constant trade-off. So I'm really proud to say, even with all those features that we added since 1.0, 1.2, the most recent release, is actually 20% faster than 1.0 was. So this is great. And this is actually a conservative estimate. Depending on your use case, it can be even faster. We've also worked hard to improve all the elements that we build with Polymer. We've made all of our elements faster and slimmer and more robust. We also worked hard to improve the accessibility across all the elements. That's really, really important to us. So we want to be leading from the front in terms of both web component performance and web component accessibility. And so the entire engineering team is skilled up in terms of making accessible web components. So we've kind of achieved, at least in this release, a nice having our cake and eating it, too. We've improved performance by adding features to the library. We've improved ergonomics. And we've also improved performance. And I think that the way we've been able to achieve that is because we're building the Polymer library up from the platform. We're relying on native platform features with web components and building up from there just as sugaring. So we're able to make really informed trade-offs in terms of just small kind of sugaring layers away from the platform and very targeted improve and add features while maintaining really good performance. I think that's a powerful direction. So I want to take a little time to think about that, about the web platform. Polymers come really far. Web components have come really far. The web platforms come really far. I think that's the theme that you're hearing again and again today. And the platform has come so far, we now have this concept of progressive web apps. With ServiceWorker, you're able to build applications that are resilient to flaky networks, that can send you push notifications, that can launch from the home screen without a chrome around it. It's just an immersive application that you've built. It's the amazing platform that we have. And features like ServiceWorker and WebApp Manifest really truly make the web, finally, a first class application platform. Really truly, for 99% of use cases out there, you can get everything you need building on the web with ServiceWorker and WebApp Manifest and similar new features in the web platform. And these are largely developer-facing features. These are largely consumer-facing features. Features your users will see. Your user will see an app working offline. That's new. Your user will see a web application sending you a push notification. These are very truly user-facing features, and that makes it this first class application platform. And it's changing the way that we can think about building applications on the web. Things we've never been able to do before as web developers could only dream of. We're now finally able to actually do in our web applications. That's really powerful. But the web has not only become, in just recent years and months even, a first class application platform. I think with web components, with web components being a developer-facing feature, a feature that makes our lives easier as developers in terms of structuring our apps, giving us fundamentally new primitives in the web platform for building components that are isolated and reusable, the web is really become a first class developer platform. And this is huge. For so long, the history of web development kind of follows this arc of doing lots of crazy things to try to avoid the web platform, to try to smooth over its rough cases. But I think we're at a really significant turning point now. I think the web can be a really elegant platform. And with features like web components and features like Service Worker, we're now able to build applications on the web platform in ways that the platform intended us to build them. And that's really powerful. And by sticking to the platform now, we can build applications, and the platform can help us out. The platform can improve these features and improve performance, and we can gain from those features and performance improvements in the platform as long as we're building to the way that the platform intended. And so I think web components are just the seed that's going to really spread across kind of all of our norms that we've taken for granted as web developers in terms of how we structure applications, how we build applications on the web platform, just in the same way that Service Worker is going to change the way we think about what our applications can do for our users. So what's next? Polymers come a really long way, but it's constantly growing. There are over 20 people working directly on the Polymer project currently, and that number seems to be growing every week. So where do we kind of see this library going? Right now, the Polymer library very much is a scalpel. So it's a very powerful tool when used in the right hands, but it's certainly still easy to make mistakes. Now, we want it to be easy just to build applications generally. So Polymer is great for building web components, but we think it should be easy to use components. It should be easy to build components. It should be easy to share components. It should be easy to optimize components. And it should be easy to assemble entire applications out of these components. So there are a few kind of products that we're working on right now to make this all easier, to make this a reality. The Polymer library is just kind of the first seed to be able to make it easier to build and share these components. So I'll talk about a few of the things that we have in progress right now. The first is it can be easy to make a mistake when you're building a Polymer element. So very purposefully, we want to keep Polymer lean and light. And so we don't include a bunch of error checking code, just to make sure you're not slipping up as a developer. We keep that out of the library. So make sure that you're shipping only what you need down to your users. And so we still want to make it easy to catch these mistakes before you have to refresh your page and come across your bug yourself. And so we're really happy to announce Polylint, which is a project we've been working on for a little while now, to be able to lint your Polymer code in line in your text editor. So it is a node module that you can also, it has plugins to common text editors like Adam and Sublime. It will find common mistakes that you might make when developing a Polymer component, things like missing an HTML import. It'll notify you when you're missing this and it will show you what component you're using that you haven't imported. Things like if you're binding to a property that you haven't declared, it'll notify you that as well. Even more subtle things when you're building Polymer, things like binding the incorrect way to a native attribute like class. So a whole slew of different linting errors it will find as you develop. So we think it'll be a really powerful tool. We're really curious to see what developers like and what more things we could find with this linter. So please do check it out. It's in our Polymer Labs organization. Everything we keep in the Polymer Labs, we like to develop everything out in the open. So this has been out in the open for a while now inside of Polymer Labs. That's our kind of breeding ground for new products that we want to get feedback on and learn more about before we graduate them into the Polymer organization. The second new thing I want to talk about is PolyDev. So web components are a really, really powerful primitive, but you have to be cautious about where you apply that really powerful feature. With great power comes great responsibility. And so PolyDev, we want to give you better insight into how you're using web components effectively in your application to build a performant application. So PolyDev is a Chrome plugin that goes into your DevTools pane. And it shows you the amount of time spent in various custom elements that you're using in your page. So in this example, this is the Polymer Summit site. And it spends a lot of time if you're reloading between schedule and speakers in the schedule grid and the speakers grid, as you would expect. But it's really great for picking out particular examples where you might be spending more time than you think creating certain types of elements. And so it gives you a nice visibility into what you might spend time optimizing in your application. So this is in kind of a vein of products that we want to help better measure the performance of individual components and better see how those performance of those components contributes to the overall performance of your application. And so this is also available up on the Polymer Labs organization, slash PolyDev. So and finally, a lot of the questions that we get about building applications with Polymer revolve around these kind of ideas. You know, how do I structure my application? How do I lazy load sections on my app? How do I handle routing? How do I handle internationalization? And for so long in web development, the answer to all of these questions has been use a framework. This is what frameworks were built for to make to provide this entire suite of solutions for this kind of class of problems around application structure. And you really needed to use a web framework to be able to easily get these things spelled out for you in terms of building an application. So for so long, we've been building these very towering constructs in JavaScript above the platform really to give us any sense of coherent organization of an application. But this can be kind of brittle. It can be like building a Jenga tower on top of Legos. It requires you to buy into an overarching framework with all of the things that cost that might come with that. You're adding layers of abstraction between you and the platform. In fact, you're not really building a web application anymore. You're building an application on the platform that is this other framework. And then that framework has to communicate with the web platform. So there's this huge layer of interaction, source of bugs, source of performance overhead. And also, if a new platform comes along as they tend to do, or a new framework comes along as they tend to do, you tend to have to throw out all the components you've built for this framework. The framework components don't interoperate the way web components do. And so web components as a new kind of fundamental primitive that is in the web platform give us an opportunity to rethink a lot of the best practices that we've taken for granted for so long in terms of building applications, in terms of structuring applications. So on the Polymer project, we've been thinking about this a lot. We've been thinking about how do web components change the way we can think about how to structure an application top to bottom. They give us these really powerful new primitives. How can we apply them to problems that you usually solve with a framework? So how might you solve a lot of these problems? How might you solve routing? How might you solve internationalization? How might you solve application structure using components that you can swap in and swap out when a new one comes along? That you can only pay as you go, only pay for the features that you're actually using in your application. So we talked about the Carbon Elements Project a little bit at the Polymer Summit. It's still a work in progress. But this is our solution. It's what we're naming our solution for structuring top to bottom applications using components and leveraging components. And we want these to be our goal with the Polymer with the Carbon Elements is they should be as close to the platform as possible. They should be, again, a thin sugaring layer to be able to give you this coherent structure without making you buy-in to entire framework, without making you buy-in to all this overhead in JavaScript. And we want them to leverage the best of the platform. We want them to be kind of the best, most elegant pieces that the web platform has. We want them to really use those to their fullest so that it's easy to build things with Carbon Elements. But we also want you to be able to swap out a different element to solve a different problem. If you want to use a different router, we want that to be easy. And we don't want to lock you in. We want these components to really be a plug-and-play. And so these are still very much a work in progress. Obviously, building a whole set of components, these are a big, wide swath of problems to solve, which are very challenging problems to solve. But I'm really happy to announce our first piece of this that we're opening up today, which are the app layout elements. So the app layout elements try to solve the problem of, how do I structure the layout of my application? How do I get this responsive layout? And so we've had a few of these types of components in previous element sets that we've had, paper elements had, paper header panel, drawer panel. Those were very much targeted toward material design type layouts. The app layout elements are meant to be much more general solutions for structuring application. So these are things like our responsive drawer panel, scrolling header panel, that you can compose together. But we want them to be way more flexible. We want you to be able to not just use them for material design language, but to be able to extend them and compose them together to create just about any kind of app layout design that you could possibly want. And so one example of a pattern that the app layout elements allow, if you wanted a responsive layout, but you wanted tabs across the top on desktop, and you wanted those same menu items to go into a side nav on mobile. And this is something that you couldn't do with the paper layout elements. With the app layout elements, you can do this. It's specifically meant for flexible types of adaptive UI in this sense. So really, really would love to get feedback from everybody on the app layout elements. They're also under Polymer Labs. There's a nice splash page with some documentation about how you can get started using them. And Rob, who's talking next, will give a little bit more about these app layout elements. So the other features I talked about are very much a work in progress. We will open these up as soon as there's something to play with in terms of routing, internationalization, and lazy loading. And last but finally, not least, I definitely want to give a big thank you to our incredible community. These were some of the most active contributors to the Polymer Library and the Polymer Project overall in terms of pull requests, in terms of great issues with great repros, in terms of just support in our community on our mailing lists on our Slack channel. So thank you so much. The project would not be anywhere near where it is without this group of people. And this is by no means a comprehensive list. There are many more that have dedicated a huge amount of time and really, really helped the project grow. We also hope that this list continues to grow as more people get involved. But thank you, again, so much, everyone. And yeah, thank you. Yeah, so I'm excited to see where the Polymer Project goes. Please keep up with us on the Polymer blog and follow us on Twitter at Polymer. And thank you so much.