 All right. Thank you, Matt. So yes, like Matt said, welcome everybody to the Polymer Summit 2016 in London. My name is Taylor Savage. I'm the product manager of the Polymer project. We're at a very unique moment right now in the arc of Polymer and the arc of Web Components. And really, we're in a unique moment for the arc of the capabilities of the web platform overall. We're witnessing right now, like right at this event, right now the confluence of three factors all coming together. The first is the acceleration of the importance of the impact and of the usage of the mobile web. The second is the cross-browser launch of Web Components. And then the third is we're seeing a really major new milestone for the Polymer project, representing what I think is a really exciting new chapter. So I'll cover all of these three different moments and what each of these mean for all of us as web developers. So let's start with mobile. Now, the acceleration of mobile has been ongoing. We've been seeing it for a few years now. But suddenly, we've hit this moment where native apps seem to be starting to hit a saturation point. And with new capabilities of the mobile web platform, with things like Service Worker, with the ability to build progressive web apps, developers and companies are starting to turn back to the mobile web as a really capable, immersive platform. And so for web developers, this represents an exciting opportunity, but also a challenge. What we're seeing is the attack of the phones. So the mobile web is incredibly exciting. Nearly every device out there has a browser, everything from the phones in all of our pockets to our refrigerators. And we have the ability as developers for free without asking anyone's permission to build an application and put it up on the web and let any user anywhere in the world access it with just a URL. But mobile development also makes our lives as web developers really, really challenging. We're expected to build immersive applications that run at 60 frames per second, that load immediately, that are responsive to the touch, that work across a wide array of different screen sizes, from the watch face to a 60 inch TV screen. And chances are we've got to deliver that application across a mobile network, a slow, flaky network, or sometimes with no network at all. And on top of that, we've got to deliver this application over the slow, flaky network to devices that are oftentimes really slow, really underpowered, sometimes overheated, as you'll hear about more at this summit. And on top of that, the code bases that we're starting from, often just look something like this, like giant mounds of really, really gross spaghetti code, most likely they were built originally for desktop and you're inheriting this code base from someone and maybe it was created with a once popular framework that's now past its prime. And there's a chance that you now have to kind of rejigger this to make it somehow work on these tiny mobile devices with all these different constraints. Mobile web development is hard. It's time consuming, it's expensive, it's hard to know where to start. And for the longest time, the web platform itself didn't really help us in the process and it didn't really help us developers out. And so we've built layers upon layers of tooling, of abstractions to make our lives as developers easier. But now, with these especially challenging mobile constraints, slow devices, flaky networks, these tools that we've relied on for so long can start to sometimes get in our way. Or they can lead us down a path, naturally down a path that will ultimately lead to worse outcomes for our users on these mobile devices. So we have a thesis on the Polymer Project around how to build powerful mobile web applications with minimal overhead, which is to use the platform. The web platform is our ally now as web developers and as part of the Chrome web platform team at Google, our mission on the Polymer Project is to advance this underlying web platform to make it easier for developers to build better apps and to ultimately make all of our users' lives just a little bit better. And so also on the Polymer Project, our mission is not only to advance the platform but to provide developers with the tools that they need to smooth over some of the rough edges of the platform so you can still build powerful applications as close to the metal as possible. So I wanna be really, really clear what we mean by use the platform. Use the platform does not mean abandoning the tools and frameworks that you know and love. It does not mean ignoring the value that JavaScript frameworks provide. It doesn't mean don't write any JavaScript. JavaScript is part of the platform, that's part of using the platform. What use the platform means is to challenge the assumptions of what you need in order to build scalably on the web. It's a call to take advantage of what's already there sitting in our user's pockets in the form of browsers. It means let the browser do the hard work. It means be selective with abstraction. Every abstraction comes at a cost. Every abstraction means extra code that your users need to download and run in order to ultimately run and interact with your application. So when you're building on the web and we're using abstraction, go in with eyes wide open. Know where that abstraction is going to provide a ceiling, know where it's gonna help you, know where it's gonna be a cost for you and your users. And finally, use the platform means that rather than doing everything possible to work around the web platform to pretend like it doesn't even exist, be aware of where the modern web platform can help you do more with less. Which brings me to our second major factor that's coming together right now. As we speak, a set of new web platform features that really truly let you do so much more with so much less, which are web components. So web components are the primary feature that we've been focused on in the Polymer project for a number of years now. They're a set of new web platform standards to let you natively build reusable components on the web. Now web components as a spec started back in 2012. And frankly, back then we were a little bit overconfident. We were over-optimistic with how quickly web components would get broadly adopted and broadly supported across browser. We were over-optimistic. And so we went back to work along with all other major browser vendors through long life cycles of iterations, many, many false starts, many, many face-to-faces across all the different browser vendors. And finally, basically as of today, basically as of right now, we can say that we've made it that web components are here. With web components v1, our new hope. So custom elements and shadow DOM specifically are two of the critical specs that fall under the umbrella of web components. And born out of a multi-year cross-browser collaboration, we've ended up with the v1 versions of these specs. The previous version that had shipped in Chrome are v0, and now we've landed a slightly different updated version that is v1. And as of basically today, as of just a few weeks ago, we can say for the first time ever that web components are shipping in multiple different rendering engines with the launch of Safari 10 just a few weeks ago. So previously, web component support was buried and it was scattered. Template was supported across the board, but other critical features like shadow DOM, like custom elements, were either behind a flag or unsupported. But now we have v1. All major browser vendors have rallied around these new specs. As I said, Safari has already shipped shadow DOM v1 in Safari 10, and they are actively implementing custom elements. You can see them in Safari Tech Preview right now. And both custom elements in shadow DOM v1 are on the high priority roadmap for Edge. HTML imports are still on hold as we're working out how they're gonna interact with ES6 modules as those come together, but we're confident in the Polymer project that will end up in a really good place with a spectrum and way to load HTML with HTML. So at IO this year, I said that cross-browser web component support was not a matter of if, but a matter of when, and when is right now. Web components are here. Whoa. So we've got the acceleration of the mobile web leading to the need to use the platform to take more advantage of what the platform provides us as developers. We've got now a powerful new platform primitive in web components that allow us to ship less code. Now we're running cross-browser, which brings me to the third confluence, which is Polymer. So the Polymer library has existed in some form or another for well over three years now. In 2014, we released Polymer 0.5, which was the developer preview version of Polymer. In 2015, we released the production ready version of Polymer, Polymer 1.0, and now it's 2016. So Polymer 1.0 has been out for a little over a year, and I think because Polymer started out initially as an experiment, it was kind of in this experimental phase with web components since the very early days. We get the question a ton. Is Polymer ready for production? Is anyone actually using Polymer in production? Are any big companies using Polymer? And so I wanted to mention today, just a handful of the companies that are using Polymer in production right now. Polymer is used by Comcast, which is the largest media company in the world. It's used by USA Today, which is the flagship brand of the largest newspaper publisher in the U.S., GANET. It's used by ING, the largest online bank in Europe. It's used by Netaporte, the largest luxury fashion e-commerce company. By BVVA, which is one of the largest banks in Spain and Latin America. By Coca-Cola, the largest beverage company in the world. By Electronic Arts, one of the largest game publishers in the world. By Predix, which is the software platform for the industrial internet of things from General Electric, which is the largest digital industrial company in the world. And of course, Polymer's used here at Google on some of our biggest user-facing products. It's used in Chrome with over a billion users. It's used on Play Music. It's used in YouTube gaming. And I'm extremely excited to be able to announce, for the first time ever, that Polymer is used in YouTube. YouTube, one of Google's biggest products with over a billion users as well, is now building their next generation of mobile and desktop sites all on top of Polymer. So Polymer is becoming one of, if not, the most important front-end web development dependency here at Google. Used on well over 500 projects with over 6,000 individual components checked into the Google code repository. So these are just a handful of the companies who are going all in on standards-based web development. And many, many more massive companies and many, many more massive projects inside of Google are continuing to adopt Polymer every single day. So there's a pattern that's starting to emerge. Because Polymer is standards-based, it's enterprise-grade. It's impossible to get hundreds of different engineering teams to all standardize on the same technology. Heck, it is impossible to find two web developers anywhere in the world who use the exact same tool set. Except that there's one thing that every web developer has in common, which is we're web developers. We're building on the web. And so when you're building to web standard primitives, when you're building close to the platform, standardization becomes trivial. It becomes the default. And so this will be a common theme across this summit, which that the promise of web components by and large is here. And it can lead to great standardization across companies, across organizations, across ecosystems. So there's still plenty of more to do. And with web components shipping across browsers, we have an opportunity to make a big leap forward with the Polymer project. So I'm extremely excited today to announce the preview release of the next major version of Polymer, Polymer 2.0. So Polymer 2.0 will be closer to the platform than ever. And there are a few main features that we focused on to really make Polymer 2.0 great. The first and the most important feature of Polymer 2.0 is web component V1 support. So Polymer 2.0 is designed to take advantage of the new custom element and Shadow DOM V1 APIs that are shipping across browser. And on top of that, it embraces ES6 classes, allowing you to write a custom element using the standard ES6 class syntax. So I'll show you what that looks like. When you're using the standard ES6 class syntax in Polymer 2.0, you'll create an element something like this. You'll have that standard ES6 class MyElement extends this Polymer.ElementBase class. You'll provide a config, which will allow you to set up the properties and the observers that you know and love from Polymer. You'll use the standard platform provided ES6 and custom element callbacks with the constructor and the connected callback, which is V1 custom elements API. And then you'll register your element using that V1 custom elements.define call to actually register your element. So this truly realizes the Polymer vision, which is to be as close to the platform as possible with just a little bit of minimal sugaring on top. And because 2.0 is so close to the platform, it's actually fairly straightforward to take advantage of many other platform tools like TypeScript. So this is what a Polymer 2.0 element definition would look like using TypeScript decorators. So on top of just the really nice-looking syntax, you'll also get type checking within and then between elements. Polymer 2.0 also eliminates some of the Polymer-specific abstractions that leaked through in Polymer 1, namely the Polymer.dom and structured data manipulation APIs, so that a web component built on Polymer 2.0 will be indistinguishable from a vanilla custom element. So I'll give an example of what I mean. In Polymer 1.0, you might write some script that looks something like this. You'll have a custom element built with Polymer in your page. And if you wanted to add a child to that element, you need to make this Polymer.dom call. And this was so that the Polymer Shadydom system could know about the distribution of this component and make sure that the DOM tree is still correct and reflected as it would be in native Shadow DOM. This is a performance enhancement to be able to run Polymer on browsers that didn't yet support native Shadow DOM, especially mobile browsers. But with Polymer 2.0, because we can rely on native Shadow DOM in more places, particularly on all major mobile browsers, we can do a little extra work so you no longer have to use this Polymer.dom workaround. So to do the exact same thing to add a child, you just make the standard DOM API call that you would expect with any other element. So you don't have to know how this element was implemented under the hood. It's just any other HTML element. And of course, we don't wanna leave Polymer 1.0 users, these many big, large Polymer 1.0 users in the dust. So Polymer 2.0 comes with a near seamless backwards compatibility layer, making it dead simple to upgrade an element from Polymer 1.0 to 2.0. And critically, Polymer 2.0 also lets you build elements in what we call hybrid mode. And what hybrid mode means is that the very same element will work under Polymer 1.0 or Polymer 2.0 with a compatibility layer. And this allows you to incrementally upgrade your project one component at a time. So I'll show you what that would look like. In a typical 1.0 to 2.0 transition, you would look something like this. You'd have your entire application and all the components all built on 1.0 and stop the presses. Suddenly we have to go back to the drawing board, rebuild every single element so that it works in 2.0. And weeks or maybe months or maybe even years later, we finally finished this transition and we can start again 2.0 fresh. And this is terrible. This is a bummer, especially if you have hundreds or thousands of components to upgrade. So with hybrid mode, you can now incrementally upgrade your project in place. So again, hybrid mode means that the very same element definition can run using Polymer 1.0 or Polymer 2.0. So an upgrade with hybrid mode might look something like this. One element at a time, you incrementally upgrade into hybrid mode as this application is still running in production. You can keep adding features, you can keep adding new components in hybrid mode as you go. And once all of the components are in this hybrid mode, you can switch out Polymer under the hood, run it on top of 2.0, and then again incrementally upgrade component to take advantage of 2.0 specific features, again, as the application is still in production. So this rocks. This is much easier. It means your application can stay live in production as you upgrade it in place. Also, this hybrid mode is totally optional. If you want to start fresh using that great 2.0 class syntax, you absolutely can do that. Don't have to bring along any of the hybrid mode support. This is largely for very large companies, very large projects with lots of components to upgrade. So taking a step back and looking at the overall arc of the Polymer library, 0.5 is an experiment to see if the web component standards could create a compelling developer experience. 1.0 was to bring this developer experience to production. It was faster, it was lighter, it was more resilient, it was rebuilt from the ground up. It was something that you could use in a real-life application as many large companies and projects are, despite web components not being broadly supported yet. And with 2.0, we can fully realize the full value of web components. Elements built with 2.0 are web-native, with minimal overhead, no leaky abstractions based on cross-browser standards. A Polymer 2.0 is a truly encapsulated web component. Now we've always said that the goal of Polymer is to slowly melt away. That Polymer as a library should get smaller and smaller as the browser itself reaches up and supports a lot of these features. And with 2.0, we get even further along this path. So if you're using that Polymer.element syntax to build your ES6-style web components, it's just 12 kilobytes of overhead. So let's talk about elements. So in addition to the Polymer library, the Polymer team builds and maintains hundreds of different web components built with Polymer in multiple collections of elements. And as part of this 2.0 release, we'll be upgrading these Polymer elements to this 2.0 hybrid mode, meaning that they'll work under either 1.0 or 2.0. So if you use them in a large project, you can do that incremental upgrade that I described earlier. In addition to the elements in the library, the Polymer project also builds a large number of different tools for building and deploying elements and web applications and progressive web applications. And we have a huge amount of really exciting news for the tools, but I don't wanna spoil the surprise. So make sure that you catch tomorrow morning's keynote for the whole world of Polymer tools and what we've been working on there. So there's one more thing I'm also really excited about. As we're turning to this new chapter of web components and new version of Polymer, we're also seeing a large number of new web component libraries coming out. Things like SKJS, like XTAG, like Bosonic, and many more. And the great thing about web components is that they're standards based. So no matter how you build your web component, anyone should be able to use it. And now we build a lot of elements on the Polymer project and we show them off currently in the Polymer element catalog. But those should just be a tiny drop in the bucket in terms of the overall web component ecosystem. And we want all web component authors to have that same opportunity to share their work and get a large audience for their work regardless of who built the element regardless of what library it uses under the hood or whether it uses a library at all, whether it's just vanilla custom element. So the Polymer team in the Google office in Sydney has been working with the broader web component community on a new place to share web components with beta release of a new web components catalog on webcomponents.org. So this is full of some killer features to help you showcase elements that you build. It shows generated element documentation from comments that you have in your element code, along with live inline editable demos that you can get a sense of what an element does right away and start playing with it right there on the element page. It also supports curated collections of elements for sets of elements that go together. So anyone can publish a collection of elements. We've added, for example, all the paper elements and the iron elements as example collections to collect those elements. It's still a work in progress, but you can start publishing elements on this catalog today. And we would love to get your feedback on the project and we'd love to get your contributions to the catalog repository itself. So with the Polymer project, we plan to move all of our elements onto this catalog once it's ready to ship. And again, the Polymer team has built hundreds of components, but these should just be a tiny drop in the bucket as to the overall set of web components available. So I can't say this enough. We are at an incredibly exciting time. The importance of the mobile web is continuing to accelerate, but we as developers are increasingly armed with the tools that we need to tackle this challenge. Now this summit's gonna be packed. It's two full days of talks by Polymer team members, by Googlers, by engineers from major companies about how they're using Polymer and web components in production. It's going to be a whirlwind of information. But to help get the most out of the summit, I encourage you to look for a few dominant themes that will thread throughout all of these talks. The first is development efficiency. So we have a lot of tools at our disposal as engineers to improve our efficiency. But at this summit, I want you to look in particular at how standards can make you more efficient as an engineer. How standards can make an entire team more efficient. How they can make an entire company more efficient. How they can make the entire ecosystem more efficient. The second theme to look for is performance. New standards give us new dimensions along which we can look to achieve greater performance in our applications. And sometimes old techniques that we've, that are tried and true that we've been relying on for years can apply in this new world. But sometimes new technologies require totally new approaches, particularly in terms of performance. And so the key to building a blazing fast web application on the modern web today is to find that right balance between old techniques and new techniques that really take advantage of these new standards. And most of all, look for opportunity. Major shifts in technology at any level introduce huge new opportunities to make an impact. And web components are a major shift in how the web platform works. It introduces a new opportunity to make an impact at your company. It may introduce a new opportunity to make an impact at the overall web developer ecosystem. Because we are just at the very beginning of the web component revolution. And everyone here is out on the vanguard. This is a uniquely privileged position to be in, right as cross browser web components are starting to launch. The tools are here. Web components V1 is shipping cross browser. You can now build encapsulated components close to the metal with minimal overhead, letting you reach the next billion users, those on slow devices, those on slow networks. Polymer 2.0 is right around the corner. It's a big step forward based on these new web component standards. What gets built next is up to you. We're excited to see not only the next generation of web apps get built, but to see the next generation of components themselves. To see the next generation of tools and of services and of WYSIWYG editors and of CMS systems that get built to take advantage of web components and these new standards. And if all of us here are successful, the Polymer project will just be one tiny spec in a massive thriving ecosystem of web components. And for that, I can't wait. Enjoy the summit. Thank you.