 I'm Peter Burns. I'm an engineer on the Polymer team. I'm gonna be talking about upgrading. So Polymer 2, it's really exciting. For the very first time, you'll have native Shadow DOM and native CSS custom properties in every single shipping mobile browser. That's enormous. Rob also just showed you all of the new ways to declare an element and all of our new and improved APIs. How's our, this is a lot of changes. How's everyone feeling? Good. Anyone feeling nervous? Anyone feeling dread? If you are, it's okay. Trust me, I know exactly how you feel. Because at Google, I was the upgrade guy. I was the guy responsible for getting everyone at Google migrated off of Polymer 0.5 and onto 1.0. Hundreds of projects. And hundreds of thousands of lines of code. Coordinating tons of engineers and interacting with them a lot, taking their support, tickets, that sort of thing. And honestly, speaking on behalf of myself and especially on behalf of them, it was painful. But the Polymer team, we learned a lot. I can honestly say it was transformative as to the way that we think about breaking changes and backwards compatibility. So why are updates painful? I think a lot of it is around uncertainty. The way we think about risk. You start thinking questions like how long is this going to take? What do I need to change to get migrated? And those are sort of the top of mind things. But I think the back of your mind is thinking, especially if you have a very large code base and a lot of a large ecosystem, I think the back of your mind is thinking about something that I've been calling the cleansing wave of fire. You're in a cleansing wave of fire situation when from the moment that you begin your upgrade, your entire app is broken and nothing is going to work until you've migrated all of it. As Taylor was saying earlier, this is a really painful situation to be in. You've got one code base that's new and shiny and all the engineers are excited about working on it and they're learning new APIs and they're being very productive. And then you've got the one that's actually in production that all of your users are using, that are filing bugs against, you come up with cool new product ideas, you want to launch them. It's a bad situation to be in. Fortunately, with Polymer 2, we've taken a better route. We're calling it hybrid mode. Hybrid code is code that works either with Polymer 1.0 or 2.0 at runtime. Basically, that just means that it uses none of the deprecated features from 1.0 and it doesn't depend on any of the brand new features that are only in 2.0. The other thing to emphasize is that unlike the 0.5 to 1.0 migration, Polymer 2 is minimally breaking. We did not redesign everything just because we could. We didn't see this as a blank check to rename everything we could. We really tried to do a very targeted and deliberate upgrade. And furthermore, we're here to help. We're gonna help in a variety of ways, starting with compatibility shims. A compatibility shim is a bit of code that either makes an old API behave like a new one or makes a new API behave like an old one. Let's actually jump into some code. So this is a very minimal Polymer 1.0 element. It should be very straightforward. It declares a tag and when that tag is attached to a document, it logs. How would you write this if you started from scratch with a Polymer 2.0 element? It looks a little bit more like this. Rob just walked you through a lot of these changes. Should be fairly straightforward. We have a class expression. We declare the tag name using a static getter. And because not even spec authors can resist a little bit of bike shedding, attached has been renamed to connected. So back to 1.0. What does this code look like if we instead use the Polymer 2.0 backwards compatibility shims? Did you catch that? Not a single line of code changed, not a single byte out of place. This works out of the box in both environments. Let's take a look at another example. So in the Shadow DOM v0 specs, if you wanted to allow a user of your element to inject content inside of your local DOM, you would use the content tag. In Shadow DOM v1, that was changed to the slot tag. The slot tag is nice. It is designed to be faster than the content tag, but it also has a simpler API. And that means that we can't really explain how content works in terms of slot, but we can't explain how slot works in terms of content. So the hybrid mode is actually the new syntax. So starting with Polymer 1.7, you can start using slot in your code today in Polymer 1. And every element that you migrate to using slot is save time for your eventual Polymer 2.0 migration. So we're gonna do more than just compatibility shems. We're also going to ship an upgraded. This will be a Node.js binary that is, if you were familiar with the 0.5 poly up tool, very similar. What it will do is it will take your code and rewrite it in place to express the old concepts in terms of the new. So here I've got some code that uses three different deprecated syntaxes. The first is a style tag outside of a template tag in my DOM module. The second is this add apply with the parentheses syntax, which is not standard, and colon root, which is standard, but it doesn't have broad enough browser agreement. So we're recommending that people move off of it. Now keeping track of all of these different changes, it's kind of a pain. And all of the changes are very mechanical. So you can just run Polymer Upgrader against your code and it will automatically fix all three of these issues. There are a lot of issues that are like this that are very mechanical, very rote, and that you really won't need even need to think about very much. You'll just run Polymer Upgrader and it will take you to hybrid or depending on how you configure it directly to 2.0. We're also going to be shipping an updated Linter. You'll hear a lot more about that tomorrow morning at the Toolstalk. But just to give you a bit of a preview, take for example this code. In Polymer 1.0, we would encourage you to extend native elements using the is syntax. The is syntax basically lets you extend this attribute but you still, or extend this element, but you still get the parsing and a lot of the native behaviors of this anchor tag built in. Because we didn't get very broad browser agreement on is, well, okay, there was one holdout. We're recommending that that you instead use composition like so. But to upgrade to using composition requires some human time, some human attention. It's not something that you can do mechanically in a rote way. So instead, we will give you a Linter warning to let you know that this code is not compatible with hybrid. You'll be able to configure the Linter with the versions of Polymer that you're targeting to give you appropriate Lint warnings. Underpinning all of this, of course, is documentation. We will provide extensive documentation, just as before, with all the changes that will be needed along with some broader context as to why. And of course, none of this would be complete without testing. Today in Web Component Tester in a branch and soon on master, you'll be able to test your element or your app against both Polymer one and Polymer two with a single command. So, what now? What should you be doing or what should you be planning to do as part of your upgrade? I think that varies depending on your situation. If you have a small project, you really probably aren't empathizing with very much of this. It's not a very nervous, scary situation because once it's at the appropriate time, you can just migrate all of your code at once. It's not that big of a deal. A cleansing wave of fire isn't that bad if you don't have much fuel. If you have a library, such as we ship with the paper elements and the iron elements, we recommend that you ship hybrid versions of your elements for a while to support other users that are in Polymer one, hybrid mode, or Polymer two. But it's really for the huge projects and the very large organizations that hybrid mode is really going to pay off because you can start migrating any part of your app at any time and we would recommend that you migrate directly to hybrid mode and then let that roll across to your organization. And then on an app-by-app basis, migrate those individual apps from hybrid to 2.0 as it makes sense for your organization. So I hope that that reduces some of your nervousness, some of your dread from upgrading process. I've been Peter Burns. You can catch me on Slack and on GitHub as Rick Tick and I'll be around the conference. Thanks very much.