 How's everyone feeling? Exciting, right? Woo! All right, well, thank you, Wendy. Thank you, everyone, for being here. On behalf of the entire Polymer team, I'm thrilled to be here to help answer the question, what's next for Polymer? We have this motto on the team. We're pretty subtle about it, so maybe you haven't seen it. Maybe you have on a poster or a podium. But in case you haven't, our motto has been to use the platform. And four years ago, Polymer launched with this simple mission, to invest in the web platform and to make web components fast, accessible, and easy to use. In 2015, we launched our first official version of Polymer, Polymer 1.0, a production-ready library for building with web components. And then at last year's summit, we previewed an early look of Polymer 2.0, which had evolved to match the final web component specs that browsers were shipping with. And so today, native web components are becoming a reality on all major browsers. So that's it. We did it. Nothing left to do, right? Thank you all for coming. Get home safe. No. No, of course not. Even as native support continues to grow, there's still plenty to do, plenty of opportunities to make web components easier to use than ever before. And so that's why I'm excited to share three big changes that are coming to Polymer. The first is that Polymer will finally be moving off of Bower and joining the NPM ecosystem. NPM includes millions of developers in over half a million packages. And soon, Polymer developers will have access to all of them. But that's not all. Polymer will also be fully embracing JavaScript and ES modules to give us a fully native loading experience across the browser and a much better tooling support for developers. And finally, to help you with all this and make your upgrade in your move as easy as possible, we'll be releasing an auto-upgrade tool to make this super, super easy to use. And so I'm excited to announce today that together, these three changes will become the next major version of Polymer, Polymer 3.0. And even though this is just a very early preview, we wanted to share our first look of what you can expect from our next release. So we're really excited, but before we get into it, I want to take a quick look back at how we got here. When the project kicked off in 2013, there was plenty of challenges and problems we had to solve. And there were two problems in particular that I want to talk about today. Component loading and package management. For web components to work, we needed a fast native loader in the browser. It had to support deep dependencies that could load other people's code and build off of each other. And while inlining and bundling have always been options on the web, we really didn't want to force an extra build step just for development. And so these were our requirements. And there wasn't much to choose from that could do all this natively. The browser had always been able to load different scripts, but those scripts can never then load their own dependencies. And there were whispers of a JavaScript module system that was in development, but the project was still years away from any consensus about what it might look like or how it might behave. And so instead of waiting, we proposed a new, simple, native HTML loading system called HTML Imports. And this would give the browser the ability to load HTML on demand. And HTML can load scripts and styles, so essentially with one loader, you could load JavaScript, CSS, HTML, all of it. We liked this because it was incredibly simple and straightforward, which allowed us to move quickly from prototyping to spec writing and onto implementation in the browser. So loading was handled thanks to HTML Imports. But we also needed a way to package web components and to make them easy to share across projects and teams. And remember, this is 2013, so a package manager for the web that was kind of a crazy idea at the time. Handling JavaScript dependencies and version updates was still a pretty manual process for most teams. But we wanted to build an ecosystem, which meant that we needed a way to manage dependencies. And because two versions of the same web component can't exist on the page at the same time, we knew that we needed a way to resolve version conflicts and install a flat dependency tree. And then lastly, we wanted web components to work anywhere with any framework. So it was really important to us that we chose an active community that was available to the entire web. And so we chose Bower. Bower was new on the scene, but it was already growing really fast. It was able to manage dependencies, resolve version conflicts, install flat dependency trees. And best of all, its goal was to be a package manager for the web. So this aligned really nicely with our mission and our goal to be accessible to any web developer and any framework. So we had our native loader, we had our package manager. With these two pieces settled, we launched Polymer, our first version of Polymer, and we continued to rely on them to this day. But a lot can change in four years. And a lot of those core ideas that we had in 2013 have finally gone mainstream, thinking with components and encapsulating styles, native Shadow DOM, native custom elements. And so the last year has been a really good opportunity to look back and reflect. And look back at HTML and boards and Bower specifically and ask, are these still right for Polymer? Do they still meet our needs? And are these still the best choices for web components going forward? And so I already gave away the ending. I'm sorry, spoiler alert. But in addition to exploring these two things and what they'll look like, I also want to show you how they do an even better job at solving those same requirements we've had since the beginning for this year's web development. So let's start with packaging. Because front-end development has come a long way since 2013. And probably the biggest change has been the huge growth of JavaScript. Node has exploded onto the scene and NPM, its package manager, came with it to build this one community for everything JavaScript. So that includes Node, that includes the web, that's included tooling. I mean even space. I mean, NASA is using NPM to develop spacesuits. I mean, that's the final frontier of JavaScript. And so NPM has brought everyone together using JavaScript into a single shared ecosystem. Bower hasn't been doing as well. Most of you are probably aware when you go to install Bower today, you'll see this message along with a note explaining that Bower is deprecated and that you should move to NPM instead. So while the Bower community was growing fast back in the day, today almost everyone has moved over to NPM and the Bower project is winding itself down. But you know what? Bower is still a good package manager. Its version conflict resolution is still best in class. Its flat dependency trees are guaranteed to be as small as possible. So I don't know, maybe this makes me some sort of JavaScript hipster to say, but Bower is still a really great technical choice for web components, which is why we've stayed with him for so long. But the world has moved to NPM. And NPM has become the world's largest community of packages and developers. I mean, look at those numbers, that's absurd. Those are some crazy numbers. And so by moving to NPM, each of these packages becomes available for your project with no extra hassle or setup. But the package manager itself has never really supported version conflict resolution or flat dependency trees. And so with NPM, you can end up with multiple nested versions of the exact same package. And while this can be fine for Node, on the front end it bloats and slows your application. And with web components, it can completely break them because web components expect to be unique on the page and can't just be overwritten by conflicting versions. So luckily, Yarn came onto the scene last year as an alternative client for NPM. And our team actually worked with them early on to add the support we needed for web components. So with Yarn, you get that same great NPM ecosystem, but now with a package manager that supports everything we need out of web components, just like Bower. Getting started is super easy. All you need to do is install Yarn and run a NIT. And if you end up running our automated tool, which I'll get to in a little bit, you get to skip all this because it'll basically do all this for you. But it's still good to understand what this will look like, so I'm gonna go through it anyway. So Yarn and NIT will generate a manifest for your project that should look a lot like the Bower.json you're used to. And some dependencies have the exact same name on Bower and NPM, which is great because that means your code actually doesn't need to change very much. So with Moment, for example, one path works on Bower, same path works on NPM, no need to change the code. But some packages do change their name. So all Polymer packages, for example, are nested under the Polymer namespace. And that wasn't the case for Bower. So when that happens, you need to remember to update any import paths as well. So Polymer on Bower becomes at Polymer slash Polymer on NPM. Another thing to keep in mind is that if you're building an application and you reference Bower components directly, that's no longer gonna exist. Yarn installs everything into node modules. So just be conscious of that and make sure you update any paths. And that's it. Then you can run NPM, sorry, not NPM, Yarn install to install your dependencies from NPM. But remember that Yarn doesn't use that flat dependency tree by default. So you actually need to tell it that you needed to install flat. So just add this option to your package.json. And then when you run Yarn, it'll install all your dependencies for you. If anything comes up, any version conflicts, it'll help you resolve it just like Bower did. But Yarn also has a ton more features on top of Bower. So for example, really smart caching, really fast installs, lock files to freeze, your dependencies, workspaces for cross package development. So there's a ton of cool stuff here that I know I'm really looking forward to using. And I'm looking forward to the move to NPM in general because it really helps us complete that original promise of web components to create elements that work on any framework in any browser on any project. And asking developers on NPM to set up Bower just for a single Polymer element or package, that's been a hard sell. So this is what I'm most excited about, honestly. As a developer, the platform should be able to meet you where you are. If you're an NPM, then Polymer should be able to make it really easy to work on NPM. And with Polymer 3, that's exactly what we're gonna do. So that's packaging thanks to NPM and Yarn. Now let's talk about module loading because with all the excitement around JavaScript, the plan for a native module system has continued to move forward. Different ideas were considered, different features debated and finally the spec was finalized last year for ES modules. And meanwhile, HTML imports, they haven't progressed as much. Chrome and Opera, they added support really early on but other browsers haven't moved forward and the reality is most of the other developers aren't really asking for them. So we'd really hope that they'd catch on but that just hasn't happened. And that means that polyfills are still required in most browsers and will probably continue to be required for a long time. And so we revisited ES modules. Now that they're finalized for the browser to see if maybe they could meet our needs. Essentially, ES modules unlock two new features for JavaScript, import and export. Export lets you tag things as module exports like this element variable in Polymer element and then import, the import keyword lets you import it from anywhere else in your application. So really straightforward and really explicit about what you're using. And so we revisited this and it turns out that they actually meet every one of those original requirements. And not to mention the JavaScript community is really enthusiastic about them. And not only that, browsers are excited about it too. So Safari has already shipped native support, Chrome and Opera are in beta and Firefox and Edge aren't far behind in active development. And so back to this chart, ES modules have finally become a viable alternative to HTML imports. And because we decided to go with them, well, you guys see this, right? Look at that chart, it's completely green. Do you guys know what that means? That means that absolutely no polyfills are required on those browsers for the first time ever. How awesome is that? Yeah, so cool, so exciting. So pumped for that. This is the result of years of work from developers across all these different browsers and we're just so happy to see it all coming together. Okay, so what does this actually look like for Polymer? Well, let me show you with an example. Let's convert this basic Polymer 2.0 element I have called PrettyButton and let's move it to Polymer 3.0 on NPM and JavaScript modules. So there's actually only three things you really need to do. Update your exports, update your imports and move your template into the class definition. Really straightforward, pretty simple. Let me show you what I mean. So for exports, instead of attaching things to the global shared window, you get to be really explicit and tag it as an export for that file. So now we can change this to export PrettyButton directly from the file. And that's it, that's all you really have to do to change it. It's really easy, right? Like super easy, like this baby even knows how easy that is and how excited he is. I mean, I'm not sure if this baby knows what JavaScript is but I'm like 90% sure that this baby is excited about HTML, sorry, JavaScript exports. Okay, let's keep going. Imports, we're gonna switch to JavaScript imports and again, super easy and straightforward to do. It's gonna look a lot like what we're already used to. So you can call it, you can call imports with the exact same path or exact same type of path and you're gonna import the element from it. And this is important because if you've already worked with MPM, then you might be used to importing packages by name. But modules on the browser expect to import a file by path. And so we're gonna keep the same path style imports we've always used in Polymer so they can work natively on the browser, no bundling required. You can still bundle if you'd like to, totally up to you, but it's not a requirement. You can't really see that path, but it's almost exactly the same. And finally, you're gonna need to move your template. So traditionally, Polymer templates have always lived alongside the class definition and then behind the scenes, Polymer would connect the two for you. But now that we're moving entirely to JavaScript, this needs to change. The template is gonna have to move. And so we can move it ourselves directly into the class definition. The class is already where we describe properties and observers and mix-ins. And so it makes a lot of sense that this is where we would describe the look and feel of the element as well. And so all we need to do is move the template in and we are now officially completely off of HTML. And don't worry, I'm just using a simple string here for an example, because I kind of know what you're thinking, that's a little gross, right? I totally get it, you're not wrong, I actually agree. Writing HTML in its own file format is much nicer than this. Editors understand it better, syntax highlighting is easier. So we definitely understand we're losing something here. But bringing our templates into JavaScript also gives us a lot of new options, including the option to go beyond just simple template strings. So I won't say much more now, but if you're interested in learning more, I'd highly recommend you check out Justin's talk tomorrow on expressive templates. That's all I'm gonna say. Okay, so exports, imports, templates, all really simple straightforward changes. And now we can bring it all together. So there's the example we were just looking at. All we now need to do is add our import and make sure we reference it properly. Add our export, and that's it. There's your new Polymer 3.0 element. JavaScript module, it's got everything. It looks exactly the same just with a few small changes. And if you're using hybrid mode, don't worry, Polymer 3.0 is gonna work with that too. And so by moving to JavaScript modules, we finally get a true native loader for the web. And Polymer does a lot in JavaScript already. So just a few small changes are all you need to get there. And just as importantly, this unlocks the entire world of JavaScript tooling for Polymer 3.0. So you can now use Webpack to bundle. You can set up Babble to compile to older versions of browsers. And tools like ESLint and Predir and all those JavaScript tools will work just out of the box without any extra plugins or configuration needed. So just like with Bower, HTML imports we're also limiting how well we could work with other projects. And asking JavaScript developers to use HTML imports and to download special polyfills just for a single Polymer element that's also always been a really hard sell. So JavaScript modules are just another way we're growing to meet developers where they are. And this is great for everyone. Polymer developers, you can now easily access all that JavaScript tooling on NPM. Non-Polymer developers, you can now use that really cool Polymer element you just found. And Polymer package authors specifically, you now have this chance to reach millions of new people, millions of new users on NPM. So that's just a brief summary of the changes that are coming to Polymer 3.0. And the last thing I wanted to share is something new, something we've created to handle all this for you. Because no one likes painful upgrades. And if we decided to change a lot of things at once, it'd be impossible to make this move safely. So NPM, modules, and then a bunch of changes to Polymer, now that wouldn't work. So intentionally the core Polymer library actually isn't changing much at all for this 3.0 move. How we use Polymer is changing, definitely. As we move to NPM and JavaScript modules, but the Polymer library interface, its behavior, hybrid mode, how it all works, that's all been changed as little as possible. And that's all allowed us to focus on just the things we need to change and create a new automated upgrade tool for Polymer 3 called Polymer Modulizer. This is really exciting. Polymer Modulizer is still under active development, but as you can see, it does a lot of things already. It can generate your package.json, it can map from Bower to NPM. And I don't have time for a demo, but the most important thing to take away is it's awesome. It's available to try out today. And the reason we know it's awesome is because for the last few minutes, we've been eating our own dog food. Does that phrase translate in Danish? I just wanna be clear, I don't actually eat dog food, but the point is, just the same, the point is we use our own stuff on the Polymer team. We're already using Modulizer to run on our own suite of Polymer elements. And at this point, it's starting to look pretty good. And so I have one last exciting announcement to share. As of hopefully about five minutes ago, all of the official Polymer elements have been automatically modulized and published to NPM available today as a part of our early preview of Polymer 3. Super exciting, so please go check them out, play around with them. I'm sure you can tell we're all really excited about this change, this has been years of work and we're just really excited about where it's going. NPM is the package manager for the web and so we're really excited to join that community. ES Modules provide finally a native loading experience that's gonna work on across all browsers. And we have an automated tool so you don't even have to worry this is gonna be a really easy change. So I'll end on the most important part, right? How can you trial this out? Well, the first thing you need to do is install Yarn. Yarn's how you're gonna work with Polymer on NPM but it's also just a really good client as well. And then here's what's available today. So we have an early preview of Polymer available on NPM, an early preview of all those elements, automatically converted. And package authors, if you have any packages out there that you've published, please check out our Modulizer on GitHub. It's also available on NPM, but just please check it out. Give us some feedback, we're really excited to see how that works. And just remember, this is an early preview so we're doing this because we really want your feedback but work is still in progress. So some bugs or maybe some missing features that's still expected at this moment. And don't worry about, you know, should I use Polymer 2 or Polymer 3 early preview? Keep using Polymer 2 for anything in production. Remember, there's gonna be this automated tool so whenever you do make the change it's gonna be super easy, so no rush. And this is just a rough timeline so, you know, don't hold us to it, but this is a pretty rough look at where we're gonna be going. So browsers, they're gonna continue to move forward. We're gonna be really focusing on documentation and tutorials going forward, improving the Modulizer and improving just our overall general tooling support. So a ton of exciting stuff coming down the pipe. So check out the Polymer blog for any news and updates on Polymer 3. We're gonna have some great blog posts coming out during the summit and going forward this year. And if you have any questions, I'm sure you do. Totally great, we have a lunchtime brown bag Q&A. So grab your lunch, you can come to the main stage and we'll have a few people up here answering questions, any questions you might have. And so that's it for me. I'm so excited to get these things out there to get people playing with it and to join MPM and the JavaScript community. Thank you all. Thank you.