Hello, everybody. We have a packed house here. We had no idea what to expect. Welcome to the third annual Polymer Summit. I am Matthew McNulty, I'm the engineering director for Polymer and Chrome DevTools and Lighthouse and a bunch of stuff like that. So welcome to the third summit. This is going to be our biggest summit ever. As you can tell, it's our biggest venue ever. So we have sort of more of everything. We have more code lab space. We have more space to talk to you, Polymer team members. We have more space to get food. We're actually really, really responsive to all the comments that people leave every single year. So the biggest number one comment from last year, I don't know if anyone recalls, is wider chairs. So unfortunately, fire code says we have to strap them together. So we tried to skirt that and didn't really weren't really successful about that. But it should be a little bit more room for everyone else. So we have two full days, 24 talks, so just a few quick notes to get out of the way and then we'll get started. So bathrooms are on the wall behind you. There are additional unisex bathrooms by the front entrance where you came in. And then just in case, we actually brought more bathrooms in out in the courtyard as well. That was the second most commented thing last year. So meals and breaks will take place directly across the hall. There's a mother's room and prayer room in the back corner next to the restrooms. But most important of all is our code of conduct. So it's incredibly important for us that this is an inclusive community and event. And in order to really get that across, we decided to make a neat video about it this year. So check it out. We want everyone to have the best experience possible at this year's Polymer Summit. This is an inclusive community. No matter your experience or background, you're welcome here. We encourage you to be excellent to each other by saying hi to new faces, building on one another's ideas, and reporting any uncomfortable experiences. We have a zero tolerance policy for harassment of any kind. This policy is posted on large signs around the venue, and our full community guidelines are on the event website. Please share your positive and constructive feedback with staff and speakers. Staff and speakers can be identified by their staff or speaker badges or shirts. Let's make this the best developer event ever by creating an excellent experience at this year's Polymer Summit. Thanks. All right, so let's get this party started. I'd like to welcome onto the stage Wendy Ginsburg, Product Manager for Polymer. Good morning. Hey, everyone, I'm Wendy. I'm a Product Manager on the Polymer Project at Google. I'd like to welcome all of you to the third annual Polymer Summit. We're absolutely stoked to be here in Copenhagen for a couple of days celebrating the web platform. It's always awesome to see so many different people at these events, from all over the world, representing all kinds of different companies with all different roles, skills, and passions. And this year is no different. Folks have come from far and wide representing almost 100 different countries. There are people from industry, open source contributors, weekend warriors, and even people who are brand new to web components and Polymer, many of whom we met this morning at the Code Lab. But no matter who you are, where you're from, if you're here in the audience at one of the numerous GDG watch events, or at your own computer on the live stream, we are so glad to have you here. I think I speak for everyone on the Polymer team and on Chrome when I say how much we love these Polymer summits. It's a huge opportunity to get a group of smart, bold, future thinkers in one room to talk about awesome stuff happening in the web platform. We also love being able to meet real developers using our products face-to-face to learn more about them and get feedback. Sometimes we don't even find out a company is using Polymer until they reach out at an event like this. If you were at those previous summits or watched the videos on YouTube, you'll look around and notice that they've evolved a bunch over the years. So let's get a show of hands and see where we are. How many of you were with us last year in London? Wow, that's a lot. And what about the first year in Amsterdam? Anyone? Awesome. Great. So to all those who have been to past events, welcome back. And to all the new faces, thank you so much for coming out. The first summit was just one day. And frankly, we didn't even really know if people would show up. But luckily, they did over 700 of them. And at that time, Polymer 1.0 had just recently been released, and all of the summit talks were from Polymer team members themselves. It was the first big long-form opportunity to tell the Polymer story directly to you, what we were doing there, what we were trying to accomplish. And we had such a great time that day that we knew we had to do it again. So last year in London, we doubled everything, two full days, more talks, more space, more code labs, more rain, more everything. Polymer 1.0 was in the rearview mirror at that point. And now lots of real companies were using Polymer. We wanted to showcase how much our community had grown. So for the first time, we invited some of those companies on stage to tell you how they used Polymer and how important web components and Polymer were to their companies and their workflows. And that brings us to today, to 2017. And things feel a lot different now, even more than they did just last year. You can tangibly feel the web components community coming into its own. So for the first time, we opened up talks to the wider community. And we were blown away by all of the suggestions. It took us much longer than anticipated. It took us weeks to go through them all. And that, as you know, even delayed registration a little bit. And just from that call for topics, we found out about amazing community projects and several big companies that were using Polymer. And a lot of them are here today. We, of course, couldn't fit everyone, but we did everything we could to give a voice to as many different parts of the community as possible. These are the community speakers you'll see over the next two days. They're from companies large and small, universities and the research world, and the open source community. Some will be talking about Polymer, but many will be talking about different web components libraries or different web components tools. We're hitting that fun part of the J-curve in the web components ecosystem, thanks to both those longtime web components champions who have done such amazing cutting edge work for so long and the newcomers looking to give a new technology a shot adding your voice to the community. Our first summit was just two years ago next month, and it blows my mind when I think about how much things have changed since then. So Polymer project itself has gone through a long journey through many distinct phases to get to where it is today. The Polymer project was conceived a few years ago by some engineers on the Chrome team. They wanted a team of web developers who lives in the future, who can look at web development not as it is today, but as it will be and report back to the present to help inform the platform. The first official phase or the infancy of the project was an experiment to help prove out the idea of web components itself. It was to work side by side with spec authors and browser implementers to find the most natural way to extend the platform, to hand greater power and flexibility over to developers by giving them access to the browser's component model. And they wanted to do this without introducing concepts that would be foreign to the way the web platform itself worked. So we build Polymer primarily as our means to tinker with these new specs, to wrap them together in various ways, to invent new patterns, to anticipate how these specs might be used in the future. And at that point, the only people using Polymer were us, a handful of Google teams, and a little sprinkling of some crazy, brave souls. Oh, also Comcast. Is the Comcast team here? Well, we'll just clap it up for them for taking an early risk. So the real promise of web components though, the real value of baking these new capabilities directly into the platform, it couldn't be realized until the majority of users were on browsers that natively supported web components. So this meant trying to help convince other browser vendors of their value and working with them to ship compatible implementations. We couldn't make this case on our own, though. This required developers to broadly make the case through real-world web component usage and actual, tangible business results. So that was our cue, and we decided to transition the Polymer project from a small experiment to a full-blown production grade library. And this was to unlock the power of web components in the wild for everyone. So Polymer 1.0 attracted a lot of new friends in a much larger community. Blue-chip companies like General Electric, startups like Simpla, and platforms and web component libraries like Vaudin, developers in communities all around the world, from Nigeria to Spain to India and Indonesia, developers everywhere were diving into web components. Unfortunately, our friends over at Safari, Firefox, and Edge and across web standard bodies worked hard to hash out a new take on the web components APIs, ones that we could all agree upon, and more importantly, ones that we could all ship. So let's take a look at where we were at around this time last year before V1 of the web component specs. Native web component support was varied and scattered. Template was supported across the board, but other critical features like Shadow DOM and custom elements, they were either behind a flag or entirely unsupported. But now, the web component specs have finally gelled with custom elements and Shadow DOM V1. The journey wasn't always smooth and it wasn't always as fast as we hoped, but we've arrived at our destination. I mean, look at that, it's all green. Yeah, web components are here. They're native on over one billion mobile devices and everywhere else with polyfills. The web reaches farther to more extremes of geography and network conditions than any other technology. And now web components do too. So, we were able to transition the Polymer project yet again to its next phase. Polymer 2.0. And Polymer 2.0 paid down some technical debt from the specs upgrading and unlocked that really awesome future forward technology today. A lot of what you're going to hear about at the summit, a lot of that is just capabilities be unlocked with the advancements of 2.0. Major companies from all around the world have continued to adopt web components. Nigeria's e-commerce giants, Kanga and Jumia Travel, General Electrics, Industrial Internet of Things platform Predix, over 700 projects at Google, India's Olakab, as well as a few you'll hear from today, like Netflix, YouTube, Electronic Arts, USA Today, and Simpla. As a community, we've grown webcomponents.org to have over 1,000 high-quality, open-source components in just over six months. I know many of the people who helped us get there are here in the audience, so thank you so much. Because webcomponents.org is huge. It sees over 60,000 monthly active users. It has well over one million page views a month. And over the last six months, we've also seen work on supporting web components happen across the web developer ecosystem, from libraries to frameworks. Major frameworks like Angular and Ember have made public commitments to webcomponents, whether by giving talks on interop or by releasing Glimmer.js with support for webcomponents. Preact has done some amazing work on making it super easy to support webcomponents. And tomorrow, on this stage, Ionic will be here to share how they've been embracing webcomponents as well. So the first goal of the Polymer project was to get webcomponents up the mountain. And well, here we are at the summit. So what's next? Well, we have this concept of a weirdness budget on the team. It's a very scientific measurement system, but basically it states that we can only be a certain amount of weird. Well, as people, we can be as weird as we want. Like, I could bring my pet lizard Julie into the office and teach him how to use the Polymer CLI and no one bats an eye at that, but as a project, we have a budget. And every project has a weirdness budget because you can only stretch things so far outside the mainstream while still being relatable. And with webcomponents support growing in leaps and bounds, we're finally less weird when it comes to the library itself, you know, super native ES6 classes. But now we have the opportunity to be less weird on another big front. In this next phase of the project, we can both embrace a lot of the amazing work that's being done in the broader web development ecosystem as the platform grows in capability. We can also expand beyond just a singular view of web components to a much more practical place of building apps that users will love. And all of this is thanks to Polymer 2.0, web components V1, the growing support for other new platform features, and the expansion of our community. With this solid foundation to grow upon, we can more easily take advantage of some major pieces of the web platform and web community. So I'm extremely excited to announce that as of today, we will be joining the massive, sprawling JavaScript ecosystem of NPM. And we will be embracing the power of ES modules. This is a critical step in bringing web components to the mainstream. There is so, so much to say on this topic, as you can imagine, and I want all of you to hear it directly from one of the folks working on the projects himself. So in just a few minutes, Fred Shot from our awesome tools team will share more information on how we're approaching this, why we decided to do it now, and how you can check out a super early sneak preview yourself. And that'll be the first of many awesome talks. Over the next few days, you'll hear about using Polymer with other frameworks, about building Polymer projects with Webpack, using Polymer with Redux, about not using Polymer at all and using other approaches for building web components. You'll hear about how companies, universities, and teams are using web components. You'll learn about how specs even come to be in the first place, not just how to use the platform, but what the platform is. You'll hear from Polymer tech leads on what they've been researching since launching 2.0, about all the collaboration that's happening in the broader web components ecosystem. We'll cover VR, SEO, and server-side rendering for web components.  So I'll say it again, we have a packed schedule. We're covering a lot of bases and venturing into territory we've never had the luxury of exploring before. And this summit represents a major transformation for the Polymer project. But as the Polymer project grows, we're always going to be sure to maintain our core values. Of course, to use the platform to take advantage of powerful new features being shipped in the web platform. To minimize abstraction, to keep overhead down while maintaining those developer ergonomics that we all care so much about. And lastly, to inform the platform, to work hand-in-hand with browser vendors to drive changes that push the web platform fundamentally forward. I'm extremely proud of the work we've been doing with Polymer. I'm ecstatic to see how far we've all come together as part of the web components community. And I couldn't be more excited for what's to come next. Thank you. So on that note, to kick things off with the first window into our future, welcome one of our amazing tools team engineers, Fred Schott. All right. How's everyone feeling? Exciting, right? 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's been to use the platform. And four years ago, Polymer launched with a 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 MPM ecosystem. MPM 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 wanna 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 wanna 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 wanna 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 imports 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's 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's still a really great technical choice for web components, which is why we've stayed with them 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 with 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 blots 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 Power. Getting started is super easy. All you need to do is install Yarn and run a knit. 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 knit will generate a manifest for your project that you 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? Super easy. 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 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 imports with the exact same path, the 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 NPM, 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 mixins, 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 Predere 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 were 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 MPM. 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 MPM. 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 MPM 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 MPM 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 MPM. 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 want to 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 MPM, 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. MPM 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 going to work on across all browsers. And we have an automated tool so you don't even have to worry this is going to 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 going to work with Polymer on MPM 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 MPM, 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 MPM, 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 should I use Polymer 2 or Polymer 3 early preview? Keep using Polymer 2 for anything in production. Remember there's going to be this automated tool so whenever you do make the change it's going to be super easy, so no rush. And this is just a rough timeline so don't hold us to it, but this is a pretty rough look at where we're going to be going. So browsers, they're going to continue to move forward. We're going to 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 going to 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. So just a quick correction, the brown bag's actually going to be in the code lab room. So you'll have spots to put your lunch and everything like that. So at lunchtime, about 15 minutes after lunchtime starts, we're going to have it in the code lab room. You can ask all your questions there. Additionally, there'll be Polymer members in the Ask Polymer lounge the entire time as well. But if you really want to get so in deep with modules, you can go over there at lunchtime. So one of the interesting things about Polymer is a lot of times we have no idea who's using it until they reach out. The call for topics that we put out a few months ago actually led us to not only a bunch of speakers that we have today, but finding out companies that were using us that we didn't even know about. Sometimes we have a, Eric Bidelman wrote a Chrome extension that lights up if a site uses Polymer, so we use that sometimes. And using that about a year ago, we found out that Electronic Arts had started using Polymer, the big game publishing company. And so about five months ago, some of us went up there. Actually, a lot of us went up there. We rented a really big van to go from the airport and Taylor rented it and it got us a very terrible hotel with a casino. But we met the Electronic Arts guys and saw just how much they were using Polymer and it was really, really awesome. So even though they promised us that we would be able to play video games and didn't, we still invited them to speak today. So I'd like to welcome to the stage Alex Zagheb from Electronic Arts. Hey, how's it going, folks? My name's Alex Zagheb and for the last eight years, I've been working with EA as a technical director. And I'm here today to share a story of how web components and Polymer has really facilitated a monumental transformation of web at EA. From the dark ages of building one-off pages and transient sites to the blissful world of reusable components and rich engaging player experiences. So before we dig in, I'd like to set the stage briefly about EA's place in the world. We are a gaming company that is driven by our core purpose and values to inspire the world to play and to be the world's greatest games company. We deliver on this purpose by being organized into this concept of studios such as Bioware, DICE, and EA Sports to name a few. These 22 studios are comprised of approximately 10,000 people in 30 locations worldwide. Each studio has one or more franchises and a franchise is kind of like a movie series. Each game in a franchise is usually a bit of a different story, characters, et cetera, but generally follows some consistent thematic elements or overall base fiction. Many of you have heard of franchises such as Dragon Age, Mass Effect, Battlefield, and FIFA. EA's player facing web is managed and delivered for the most part in a centralized model by about the 100 person team that I work with, Pulse. Through this centralization model, we can achieve efficiency through economy of scale and our efforts and overall just ensure an engaging and consistent experience across that diverse EA ecosystem. This means that our group must meet the needs of those 22 studios totaling over 50 franchises that release 20 plus games to our players every year. So today I'd like to go over three topics. First, our journey and decision-making process of kind of how we ended up with web components and Polymer. Second, an overview of the design system and component library we've created over the last two years. And last, some highlights of how we've been applying this design system and how it's been a huge win for EA and our players. So let's start with the story of how we landed with web components. So we need to go back about two and a half years, so basically a decade in front-end world, to February 2015, when we really started our journey with web components and Polymer. EA's approach to web was very different back then. We embodied Conway's law to the fullest in how we delivered our disjointed web ecosystem. And for the most part, we designed and developed EA's web more like an internal agency, one project, one site at a time. This siloed and disjointed web was really a sad place for our players.  We were spending 80% of our time on commodity web, such as navigation, footers, news articles, media galleries, video player, pre-order and by-page, leaving only a fraction of our time to innovate, excite, and engage our players with custom game-specific experiences. So naturally, in the world, we wanted to live in, we would flip this allocation of time and focus around and spend the majority of our time on the fun-engaging stuff instead. So we started really thinking and talking about, okay, how do we get from this 80-20 bad to this 80-20 good? And voila, the network design system project was born. Project name aside, this was really about applying well-known concepts of a design system, a pattern library or a UI framework to how we did web. The idea was that by having all of our team members from product managers, to designers, to developers, to QA, embracing the complexity of the web with a component-based approach, we could drive efficiency and make our commodity core web features turn key. But before we started to hit the keyboard, we took an introspective look at ourselves. What other requirements, needs, wants did we have beyond those of a standard component-based design system? What special challenges did our contacts bring to the table? In the end, our special needs and wants for the NDS distilled down to these four items. Number one, to facilitate deep theming capabilities, to work with any language and any framework, to support our micro-site architecture and to deliver user interface as a service. So let's look at these each in more detail, starting with facilitating deep theming capabilities. Now, ideally we would have a solution that worked with our entire spectrum of branding and theming needs, from one extreme being the broad, out-of-the-box kind of EA corporate brand, to the opposing extreme, being one that is heavily themed in a very focused and specific manner for a single game. And in some cases, meeting the very stringent style guide requirements and approvals from a licensor, such as the cases with Lucasfilm for the Star Wars franchise. Okay, number two, let's talk about our desire for this solution to be language and framework agnostic. Recall, this is early 2015 still. And our group at that time was the result of several internal team mergers and reshuffles. And as an outcome, we had a plethora of technologies, languages, and paradigms in play, from frameworks and libraries, such as Drupal, Symphony, Grail, Spring, Angular, DropWizard, and even JQuery, to languages including PHP, Java, and Groovy. And content management systems, such as Adobe Experience Manager, Even Yet, and El Fresco. We had technology divergence. So unsure where we would end up with our stack in the future, we didn't want to get locked in with any one particular back end or front end framework and language. This must work for the unknown future us, as well as the rest of EA. So all right, number three, our micro site architecture. We had, and to some extent still have, many discreet web applications that have their own lifecycle, teams, budgets, et cetera, but are assembled together to be perceived as kind of one single cohesive player experience. What this means is that some design elements, such as global navigation, responsive UI breakpoints, and grid, login flow, pre-order page, need to be centrally controlled and consistent across all of our sites, whilst other design elements can be more customized for each site. Okay, last up, number four, user interface as a service. So given this micro site architecture, how do we avoid projects that aren't being actively developed from falling behind and getting out of sync with the rest of the EA ecosystem? How do we keep all the projects pointing to the latest version of this design system with minimal effort? By delivering our UI conceptually as a live service, we hope to address these issues and really embody the mindset of leave no site behind. Okay, so given our goals to build this component-based network design system, coupled with our four special needs, where do we start? I mean, what's the approach? The architecture, the systems, the tech, the tools, I mean, there's a lot of questions. So just like the purple pattern states, unlike any developer should be, I am lazy. And knowing that our general problem space of building a component-based design system was not a novel concept, it made no sense to start from scratch. There's so much out there and there's so many people to learn and leverage from. So we begun reading, listening, experimenting with and consuming anything and everything we could possibly get our eyeballs, ears and hands on in regards to the topic of style guides, design systems and UI frameworks. Serendipitously, a new podcast from styleguides.io was out and posting fresh episodes on this topic right around the time of really 2015. What a bonus. So I'd like to talk about three particular paradigms and systems that were quite inspirational and key to our path to web components. Bootstrap and sort of friends, Lonely Planet and the government of the UK. Starting with the ever-popular Bootstrap and more generally UI frameworks that follow the same approach. So here's a simplified example of what integration of a Bootstrap-like component library might look like.  Seems easy, seems awesome, seems good, right? So let's use this pagination component as an example. It's a good one because it has some reasonably complex UI, different states, some brains inside and it really needs to interact with other components and code to actually do something that's meaningful. So let's see how we integrate this component. We start by going to the documentation for the paginator, find the sample HTML snippet, then we copy and paste this large chunk of code into our application, okay? You know, it's obviously not good from a reusability and upgradeability standpoint as we have essentially forked this chunk of code and will now need to manually merge those updates as they come along. Additionally, there's little to no encapsulation. All of the internal structure and all the style are exposed to me as an integrator. I mean, what really is the public API? Is it all of it? So we're not done. We still need to hook up some behavior now to this pager by means of JavaScript. And this is generally completed by grabbing a reference to the root element of the component and passing it to some factory or constructor as shown here. Okay, so the Bootstrap model shows us one way to do it. Let's move on to Lonely Planet and see their approach. Much like us, Lonely Planet had a microsite architecture comprised of many sites, each with their own stack and team around them that need to work together to provide a single cohesive user experience. Their initial approach was to create a shared UI layer following the Bootstrap-like model we just explored. And in this diagram, taken out of a talk by Ian Feather of Lonely Planet, you can see the two core problems around risk and reuse depicted. The shared layer has the most reuse, but as changes here can affect all the applications that use it, risk is high when making modifications, especially without a clear API boundary. Due to this lack of API, you really don't know what people are doing with your component. So over time, engineers naturally will shy away from making changes and doing things in the shared layer because they're afraid of breaking stuff. So the shared layer shrinks and atrophies while the site-specific layers grow, basically the anti-vision of any shared component UI system. So what Lonely Planet did with their design system, dubbed RISO, was move away from the copy-paste approach by encapsulating each component into a Ruby and Rails helper that took two parameters. One being the name of the component, and the second parameter being the clean and minimal set of data that that component needed to render. This is much, much better. So by implementing this component layer and API between the shared layer and the specific sites, they're able to reduce or remove the risk of making changes to those components as well as really ease overall integration effort significantly. So the Lonely Planets folks really plus one the Bootstrap model with their RISO system. Naturally, this is my face after coming across RISO, so excited and essentially ready to lock in and go with this approach. But not so fast. Sometime after RISO had been humming along in production, Ian Feather put up a blog post titled, What We Would Change About RISO? First, the solution was tied very tightly to Ruby on Rails and ERB templates. And hence was not portable or usable by applications that employed different languages or frameworks. He hypothesized about using Mustache templates or similar to sort of mitigate that issue. Second, all of that CSS, HTML, JavaScript and Ruby that made up RISO was bundled and integrated into each site via a Ruby gem. So each update to RISO meant you had to go through a dependency update, build, test and release cycle to each of their 10 plus integrating sites. Okay, so Lonely Planets RISO was an excellent overall approach, clean API data-driven components. But before we move on, being Canadian all, we figured it would be a good idea to check in with the Queen over at the government of the UK. Inspired by the Lonely Planet approach, Ed Sodin, working with the government of the UK, really wanted to resolve that issue of the effort and cost of propagating those changes from the component UI layer into those integrating sites. So building on the core approach of RISO, they added the concept of a template resolver, whereas all those ERB templates were moved out of the gem and into some shared network location and then they're lazy loaded from this location and cashed locally for a short period of time. This combined with pre-bundling the CSS and JavaScript onto that CDN location allowed for changes to be propagated with minimal effort to all of their apps. As you can see, the WK folks really took the already awesome Lonely Planet approach and plus one did big time with the addition of that template resolver. Now, we got quite excited about this approach. It really felt like a viable option for us to start heading down. But before we dove in too deep, we went back to our four special needs just to make sure and see how things measure up. So number one, deep theming capabilities. Now, reminder, this is still early 2015. So CSS custom properties were only available in about 10% of users' browsers. Okay, so I'm not sure how we can do this exactly. I guess we can figure something out. Perhaps each site can build their own CSS override file that just has the CSS rule sets that need to be modified to theme those components. Hmm, okay, but what happens when we refactor some CSS or we introduce a new component? I guess we'll need to rebuild those override files. Okay, well, I mean, we've got some tools to build. I've got a process of documents and people to train. All right, number two, let's see. Working with any language, any framework. Well, I mean, we could just use mustache templates coupled with the same WK template resolver approach. That would do the trick. We just need to build client libraries now for every language that we need to support. Okay, so that's like PHP, Java, JavaScript, I mean, at minimum. And then ideally, we'd have first-class integration into the front and back of frameworks that we might use. So let's see, that's at least four frameworks. Oh boy, now there's already a lot of open questions, plumbing and miscellaneous pieces to worry about here already. Now remember, I'm a lazy developer. I don't want to write and maintain code if I don't have to. I really wish that there was just an off-the-shelf solution that I could just grab, read some docs, give me everything I need, and one nice cohesive package. Okay, so back to the drawing board. What else? What else? What else? I mean, we have designs for all our components now. Like we need to start getting on some code really soon. So I remember this hipster tech that was brewing for what feels like years now. Sounds cool on paper, web components, and Google Polymer, I think it was. Oh yeah, that's right. I remember there was a talk at Google I.O. in 2013. Oh yes, now I remember. A fun-looking toy, terrible performance due to some nasty invasive DOM polyfills. Basically, Chrome only. I mean, way too hipster for this job. I mean, this is all of EA's web, hinging on the decision. I need a solution that is ready for production at EA's scale, like today. But wait, what is this? Polymer 1.0, just released, like now. Production ready web components. Really, all right. Sounds good on first glance, back by Google. Focused around components and not full-blown applications. All right, chill out, Alex. Back to our special needs first and let's see how things measure up. So number one, deep theming capabilities. Well, we get theming right out of the box using CSS custom properties and mixins with a shim that works everywhere. Cool. We can theme these components at runtime too. No build step necessary. That's pretty awesome. All right, number two, working with any language, any framework. Well, I mean, it's really just an HTML element at the end of the day and almost standard DOM interface. So hypothetically, anybody or anything that can put an HTML tag into a document could technically use our components built with Polymer. Oh, and all the CSS, HTML and JavaScript is bundled up together into an HTML import for client-side inclusion, so no tie-in to any specific back-end or front-end language or framework. Needed, awesome. This is like sounding really good. All right, number three, support our micro-site architecture. Well, it seems that we can control the API, however we want on a per-component basis, so that should work well. And last up, user interface as a service. Well, it's just client-side integration. HTML import seems like it has some of the basic working pieces to make this happen. So yeah, this is looking really good. So my mind is blown at this point. An off-the-shelf solution that meets all of our special needs and lots more, tooling, docs, et cetera. Less code from my team to write makes me very happy. And bonus is that most of the gnarly parts of Polymer are promised to be native web platform primitives sometimes soon too. I mean, a framework's roadmap that states that it wants to get smaller, do less over time, and eventually may not even need to exist. I mean, that's amazing. So with Polymer, this hipster web components thing just became our top contender. So compared with the already awesome approaches of Lonely Planet and the government of the UK, web components in Polymer 1.0 was like a plus 100. So in September of 2015, we decided to officially lock in with web components and Polymer as the core technology for the network design system. Now, let's fast forward two years later, down our journey with web components, Polymer and the NDS. You know, what did we end up building? How did our four special needs sort of hold up in real life? Did web components in Polymer meet my mind blown expectations? I'm pleased to say that we have approximately 75 components that are arranged into one of six component families, which are just logical groupings of components based on their purpose. Let's look at a few examples. Starting with our most commonly used component, our call to action or button component. You know, it's quite polymorphic and it supports different types for text, text with icons, images, and so on. And this component also comes with Google Analytics tracking out of the box, ensuring that every button on every site sends consistent and meaningful data. Next up is our pagination component, something with quite a bit more logic and state than a button. To me, this paginator really showcases the power of web components. All that complex structure, style and behavior are nicely encapsulated away behind this minimal, clean, declarative, and imperative API. In this example, we just simply listen to that page change event and do what we need to do with the data. We also have some very high level components that are almost like encapsulated in many applications all on their own. This newsletter signup has various states for anonymous users, authenticated user, already signed up, as well as it provides a multi-step flow complete with error handling, localization, and integration with a few external service APIs. All right, so now with that sample of components in mind, let's review our special needs again and see how we've applied web components in Polymer to bring these two fruition. Starting with facilitating that broad spectrum of brand specificity and fidelity that we needed. Now we have about 300 CSS custom properties that are set at the system-wide level that are there to mostly control color and typography. We love that even back in 2015, when CSS custom properties were not widely available, the shim that came with Polymer 1.0 allowed us to use this powerful tool to theme dynamically at runtime with no build necessary. In fact, we now control these primarily through our content management system. So a designer and a product manager can spin up a site and theme it without any developers involved. We also have many CSS custom properties that are used as internal design tokens and are really there just to keep things dry from a development standpoint, but they should not really ever be exposed or altered by our integrators in any way. And so these are rules such as our responsive grid, gutter and column widths. So what we do is at a build time using post-CSS, we substitute and compile in these static values for these design tokens, making them essentially immutable and leaving only the themeable CSS custom properties exposed. So this is our tile or our card component. And it's used in most places where we have a list of items to display, such as a news article, videos, characters or weapons. And although CSS custom properties are great for granular CSS level control, using HTML attributes as another way to theme and control a component has doomed to be very powerful. The example that illustrates as well is the type attribute on this tile that has two possible values, horizontal and vertical. Using the host pseudo selector, we can have that single HTML attribute impact the entire presentation of the component from placement and size of the media asset, to margins and padding, to different layouts completely, that mobile versus desktop. All by letting CSS and the browser do all the hard work, no imperative JavaScript needed. So just by using those system-wide theme, themeable CSS custom properties and the per component HTML attributes, we can deliver all four of these tiles using the exact same component, all themed at runtime to boot. Okay, number two, let's talk about how the need to be language and framework agnostic has gone. Here's a very simplified view of our overall stack today. We have Adobe experienced manager as our CMS in the back end, Lightben's play framework as our middleware, and of course, Polymer in the front end. Now, we have taken the approach that when we think about a component, we think about how it manifests across this entire stack, not just in the front end, ensuring that we can drag and drop a component onto a page in the CMS, pull that component into the middleware, and serve out the custom element for Polymer to then render. So for our stack, each component has first-class integration, top to bottom, as an example of a button. But this does not mean that integrators must use our full stack to get the benefit of the network design system. As each layer of the stack is loosely coupled and has clear API boundaries, it's really easy to just use that front end Polymer component all on its own. No gem, no template service, client library, just a simple HTML import. Okay, so number three, our micro site architecture. So recall that some components need to be centrally controlled and consistent, whilst others can be more customizable. Web Components of Polymer makes this really easy, as we get to control how narrow or how broad the API is on a per-component basis. Components that we really need to be nearly 100% consistent across all sites, we just simply severely restrict the API into that component. And others that are meant to be super flexible have all sorts of knobs and switches in the form of CSS custom properties, HTML attributes, and view sub slot-based composition. So our pre-order by-widget, newsletter sign-up, footer, network navigation are all examples of where we really keep that API minimal. Okay, last up, number four, user interface as a service. Now, we apply Semver very, very diligently, being super careful to keep the NDS backwards and forwards compatible, with a strong focus on not bumping our major version number for as long as possible, sticking to backwards compatible changes resulting in minor version bumps only. So this mindset has worked really well as we are currently at version 1.31.0. And in practice, we could update a site from 1.2.0 to 1.31.0 without any code changes or issues. Currently, we deploy a pre-built version of the NDS to a CDN location using a naming convention as shown here. So this gives the URL meaning as to the version, the artifact type, and the artifact that's being referenced. By supporting FuzzyVersionMask on the major release version, means that the site can ask for a 1.star, a 1.x, and get back a 302 that actually redirects them to the latest 1.x release, which as it is a tagged and unchanging artifact, is sent back with a very aggressive caching policy. So as you can see, our special needs have come to fruition thanks to web components and Polymer. Now, I'd like to briefly cover a few more wins and show off some of our sites. So as mentioned, we have 75 components in production. They're now powering about 30 sites in total, and that number is growing rapidly every day. On the left is EA.com, corporate site, using the out-of-the-box default theme. And on the right is the more heavily styled Titanfall 2 site, but both using the same NDS version and the same HTML import. And here are a couple more with Mass Effect on the left and on the right, an upcoming new franchise from Bioware, Anthem. And we have gone from a previous tedious and lengthy process to bring up a site to now only taking about one and a half weeks of content only. That means no development effort. So component type thinking is really just how we operate across all functions now. We don't design and build pages anymore. We are always looking to decompose and then compose with component-based building blocks. And as a bonus to the delight of our digital intelligence team, we have been very consistent and complete analytics tracking across all of our components, allowing us to compare apples to apples between different sites. And of course, efficiency and economy of scale. We've reduced duplication. We have better engineering mobility between projects and teams. And with a predictable proven and streamlined system, we have much, much lower project risk and a far more dependable schedule. So going back to this original goal of living in a world of making our commodity web turnkey low effort and maintainable, how have we done? I would say a resounding success thanks to web components and Polymer. Thank you very much. All right, it is time for our first break. We're running a little bit late, which is Polymer Summit tradition. So there is coffee and tea and light snacks available over in the catering area and we'll start up again at 11.35. I got some music to play beyond this time. All right, so our next two talks before lunch are actually the two core engineers of Polymer that's Steve Orvell and Kevin Schaaf. They do everything together, so they're even sharing the same talk block. Monica likes to call them Stevan. So up first, we've got Steven Orvell. He's the one who always complains that our elements are not fast enough, not good enough, so we put him in charge of it and now he's here to talk about it. Hey, everyone, my name's Steve Orvell. I'm an engineer on the Polymer team. And we're here to talk about the next generation of Polymer elements, like Matt said. We're still pretty early in this process, but we're iterating pretty quickly as I hope you'll see. So it's this kind of reusable elements that we're talking about. They're used in almost every app. And we have a pretty large catalog of them that we've published on the Polymer project. They've been out for a while, a couple of years, since Polymer won. So we've been asking ourselves what needs improvement. Matt gave you a preview of that. And luckily, we've gotten a ton of feedback from our users both inside and outside of Google. And YouTube's built a whole application with Polymer. They've asked us to make elements faster. People come to YouTube to watch videos. So we make Polymer faster. That will make YouTube better. The Chrome Settings UI is built with Polymer. And they've actually asked us to make Polymer elements smaller, which is kind of crazy, since you don't actually have to download them to load the Settings page in Chrome. But they do have to download with the Chrome app. So they told us, if you make Polymer elements smaller, it'll make Chrome download faster, and users like that. And our own team has asked us to make elements easier to maintain. They've specifically voiced concerns about our behavior system that we had in Polymer 1. It was a little bit cumbersome to use and a little bit hard to make maintainable code with. So they asked us to work on that. And of course, all of our users always want a lot more features. We've gotten a ton of GitHub issues on that. And we actually know that all of our users actually want all of these things. We want elements to be faster, smaller, easier to maintain, and have more features too. Size is especially critical if you're making PWAs that need to load on slow 3G networks. Of course, you need things to be as small as possible. So we thought about all of this feedback when we were designing Polymer 2. And we realized that the needs of these reusable elements, like inputs and checkboxes and buttons, are really not the same as the kinds of elements you're making when you're making big applications. When you're making these application views, you're concerned really with getting data from a server and transforming it to the UI, managing those complex interactions. And you really want the ergonomics of that experience to be good. When you're making reusable elements, you're concerned more with size, and speed, and look, and feel. So we realized that one size does not fit all in Polymer 2. We decided to throw out our behavior system in Polymer 1 and in Polymer 2, you really embrace the new features in JavaScript, classes, and mixins. And this would allow us to make Polymer 2 modular, pay for play, so that features are there only if you need them. And that would allow us to hit more of these use cases more optimally. So we did this for Polymer. But the existing set of elements, we've made what we call hybrid elements. And these are really a bridge to the future. We really haven't addressed the feedback we've gotten in these elements. They're there really to let you transition from Polymer 1 to Polymer 2 seamlessly. So with that in mind, we're now starting to think about what it means to make that next generation of elements where we can start addressing that feedback. So we're just going to take a look at some of the topics that we're thinking about. And you're going to get an early peek at that. So first, we're going to look at addressing that feedback that we've gotten to make things smaller and faster really directly. Then we're going to look at using extension, which is a new feature in Polymer 2, and what that means for elements. And finally, we're going to dive into some improvements that are coming in the platform around styling. All right, so let's start. And we'll look at making elements smaller and faster. And to do so, we're going to go ahead and remake an old friend of ours, PaperInput. Inputs are used in almost every web application. So if we can make a small, fast one, that'll be great. This one has this material design look and feel, has that animation, that validation effect with a customizable message. And of course, we know we need all of the native features from the input element, accessibility, all of the types and all of that. So as we want to remake this to make it smaller and faster, we need to ask ourselves, what's the minimum that we need? And we'll start by making a base class. And we can use this for this input element, and then maybe for some other elements too. So let's go back to the modular design of Polymer 2. We build on top of HTML element, and we have a number of mix-ins here. Property accessors, exposes, helps us manage getters and setters and react to properties changes. Template stamp helps you stamp a template. Property effects gives you data binding, and we wrap it all together in Polymer element, which we think is actually pretty good for building these application view elements. It's just about 12k minified in GZIPT. And that's actually a pretty good trade-off here. But when we're making a really small and fast element, it's a lot more than we need. So we're going to actually go down to property accessors and use that. And that's actually just 2k out of the box. So it's going to really help us with making the element really small. To make it fast, we'll go ahead and just use this mantra, do less and be lazy. We want to do as little as work as possible to render the element and then do work lazily only as the user needs it. So the last two slides were actually from previous talks that have been given. At Google I.O. this year, Monica gave a talk, Polymer Billions Serve Lessons Learn, all about the modular design of Polymer 2. And I gave a talk last year, you can see my standard uniform, which has all about practical performance patterns I can use with Polymer. All right, so let's dive in a little bit to property accessors and see what it gives us out of the box. So it helps us make accessors, which are getters and setters, where we can react to changes when properties are set. It also helps synchronize with attributes, which is important when we are using HTML. It has a explicit API for turning on the system called enable properties. And that's there to better integrate with the boot up process as a custom element comes in. We take those attributes and reflect them to properties and we're able to process that as one set of changes, which is more efficient. It also triggers the ready method, which is lifecycle method that we add to allow us to do one time initialization work. And finally, we have an entry point called properties change, which allows us to react to this batched set of properties changing. And in Polymer Element, this is implemented for us. And this is where we get data binding and property observers and things like that. But in this element, we'll go ahead and implement this and do the work that we need when properties change to update our rendering. All right, so now that we understand property accessors, let's go ahead and build a little base class on top of it that we can use to make our paper input replacement. We'll just call it simple element. We're just kind of experimenting, so that sounds good. And the code is just going to take HTML element, apply the property accessors mix in. It's going to call enable properties. At the connected callback is a good time to do it to get that proper turn the system on. And then it'll define a template getter. And we'll use a string, which is going to work well for modules. This is something that is actually currently optional in Polymer Element. And it's all that we'll support here. And then we'll implement the ready method and stamp the template into the shadow root, which is great for custom elements. We'll steal a feature from Polymer Element, the this.$ node map for IDs in our template. And we'll do this because we're going to be working with those elements directly in this. And this is just so we don't have to find them. We'll call super ready. This is actually the easiest way to have a broken element is to forget to call super. So I definitely remember to do that. OK, so that's basically all we need to do to put into our base class property accessors. And then we made simple element. And then we'll make a thing called simple input. And this is just going to replace our paper input. So let's take a look at a few things about this. We'll look at what we call a decorator pattern that I'll explain in a second. Then we'll look at the template. And finally, we'll look at some of the code, specifically the ready method and the properties change method. So first, we're going to use an approach we call the decorator pattern. We're going to ask our user actually to put the input and the label in the light DOM of the element. And this is actually a change. We didn't do this in paper input. And it was a big pain. And the reason is because if we put the input in the shadow DOM and we want to customize or expose all the power of the input element, we have to forward all that information. It's a lot of complexity to manage, and it's not a good trade off. So if we use what we call the decorator pattern here, it makes the element a lot simpler. And we get all of that native accessibility and the type capability of the input out of the box. All right, so let's define the template. And we have some styling. This is kind of the minimum that we could do to get that material design look and feel. I won't bother you with that since you're all CSS gurus. We have a slot for the input, which allows us to project from the light DOM into our shadow root, a slot for the label, and then some non-semantic nodes that we get out of the way. And here we have an underline node that helps us manage that animation. And that's really all there is to it. All right, so let's look at the ready method. Again, this is sort of our boot up work. And since we're using a simple element, we call super ready, which is where we stamped the template. This is going to happen before the element gets rendered. So that's fine, but we have to be aware of that work since we want to make our element fast. And so anything else we're going to do, we're going to do after the first render of the element. We set up that CSS so the initial render is free. We don't have to do anything to get it to show right. And then after the render, we're going to immediately find the input in the light DOM, just using some shadow DOM API to do that. And then just add a couple of event listeners and use a private property here to track the focus state. And I do a little bit more for the label too. And that's really all we need to do in ready for that setup work. And then we're going to go ahead and implement properties change, where we'll react to those properties being set, like focused, and a couple others. And basically, we'll be manipulating the DOM directly. Here, I'm just going to add a class to that underlined element just to tell whether or not the element is focused, and that'll manage the animation. We do a little bit more of this for the label in the error message. And we get this, which is hopefully looks almost exactly the same as the paper input. Material design look and feel has a little validation guy. And it's looking pretty good. So how do we do on size and speed? Well, pretty good. It's just a little over 3K using property accessors, the little base class that we used, and then the code that we had for the simple input. And now compared to paper input, which is a hybrid element, which means it really is not leveraging Polymer2's modular design. It has all of the legacy API from Polymer1. It's actually 10 times smaller, so it's a huge improvement. And by using the decorator pattern and cutting out some of the features, we made it five times faster to render, which is, again, a pretty humongous improvement. But of course, we know from our feedback that the features that we eliminated, users are going to want. So what are we going to do about that? Well, let's move to our next topic, which is extension, and see if this will help us at all. So extending elements, as I mentioned, is sort of a new feature for Polymer2. And we just get to rely on JavaScript for doing this. And here's some things to kind of keep in mind as you're using extension and making elements. And the first is to keep our base classes simple. We kind of did that with simple element and simple input, so that's good. Using extension to add features is kind of an answer to how we're going to deal with those missing features that we didn't support in paper input yet. And then, importantly, if we can design our base classes with extensibility in mind, at least in the sort of obvious ways that we can anticipate, this is going to make it much easier for us as we extend them. So as I said, JavaScript classes really give us a lot of help with extending elements, because it's native now, and that's great. But when we were kind of designing this, we were thinking about, what about the templates? Especially when we're defining those templates in HTML, we were kind of concerned that we might need a system to help us do the kinds of things you want to do when you're extending elements. But if we're using modules, specifically if we're using those JavaScript string template literal to define a template, then that might actually change things. So we want to investigate that. And specifically, we want to look at two use cases. The first is you're making a subclass of an element, and you want to wrap some content around the superclass template. That's a common use case. And then the other common use case is we're making a subclass of an element, and it wants to insert some content somewhere in the middle of the superclass template. And hopefully, we want to do this in such a way that we don't have to copy and paste the entire superclass template. So let's take a look at both of those use cases really quickly. This is just a contrived example, so we can kind of see what's going on. Just a simple element that asks, how do you feel? And then has a little input to respond. Now, if we make a subclass of this, we'll define the template here and just use a string template literal and the native syntax here to refer to the super template. We get that kind of for free. And then if we want to do the wrapping, we can just go ahead and insert the content like that, adding a header there and then adding another question. Kind of get that for free, so that seems pretty good. But now let's go ahead and say, what if we wanted to subclass this? We realized that the way that we've organized this here, well, there's a header and there's some sort of list of questions. Can we design this element to make it better to subclass, easier to subclass? So if instead we have a template for the header and we expose that, then now we've created an override point that a subclass can customize. If we do see the same thing for the questions, then you can see that we've added very little to our base class here, and the rendering is exactly the same. But if we want to subclass the element and make it look like this with a different header and maybe a couple other questions, then all we need to do is override the header template like that and the questions template like that. It's just that easy. So we can kind of see that extending templates when we're using those string template literals is possible to do a lot without a system, especially, as I said, using those string template literals and using classes and mixins for polymorphism, just like we saw. So how can we apply any of this to the simple input element? Let's go back to the template. And we know from our experience with paper input that people want to do a lot of customization with how the input looks in the material design look and feel there. They want to add icons to the beginning of it, maybe icons to the end of it. And we could add a lot of complexity to our base class to support all of those needs. Or we could just expose an override point for the input template. And that adds a very minimal footprint to our base class, but it's going to expose a lot of power as we subclass the element. For example, if we make something like this a credit card input to make sort of show a credit card after the input, we could customize that input template, add some styling, call super, add a little icon for the credit card, and then it would look like that. Obviously, we'd want to do a little bit more to make a full credit card input, maybe restrict it to numbers and validate the credit card. But our subclass gave us a nice helping hand, and it was really useful. So we're really excited about leveraging extension to build new elements. And we know this because it's going to help us factor our code better. If we factor our code better, it's going to be easier to maintain. It's easier to maintain. We're going to have more time to add features. And we're going to have a good helping hand there to address some of that core feedback that we've gotten. All right, so we'll move on to our last topic, which is some changes that are coming to styling. So you might ask why we're talking about styling. Isn't this a solve problem with web components? We have Shadow DOM, which helps us encapsulate styling, preventing styles leaking into or out of our elements. And we know that that encapsulation is intentioned with theming, which is a more global concern. But we have an answer for that, which is CSS custom properties natively available on all major browsers now. They naturally flow down through the Shadow DOM boundary, where we can use them in our custom elements if we want to. And let's sketch this out a little bit so we understand it. So I didn't show this, but here's a little custom property that we can set here in a content view that might have one of those simple input elements in it. And then that CSS that I didn't show in the simple input, we might use a custom property like this, where we say, OK, we're going to default that underlying color to navy, but we'll make it setable. In this case, that's going to be orange. And that's all we need to do to expose that color to be themeable to the outside world of our element. And that works great. And we also had in the styling here in the simple input a little bit of opacity, and that was just the designer said that was there to make it look good. But then we might have a user that says, oh, that opacity, I want to be able to set that too. So now we actually have a little bit of a problem. And that is because we could expose a property for the opacity, but then the user might want to make the padding different or any of the other hundreds of properties in CSS. We have a scaling problem with custom properties like this. So there's something missing here. And on the Polymer team, we helped propose AdApply, which a lot of you may be familiar with, as an extension to custom properties. And we worked with Tab Atkins, who is a CSS spec guru that works at Google. And he told us he actually put whatever information he want as a custom property. And here we're putting the opacity for the underline. But we need a way to make that go at the spot in the custom element. And that's where AdApply came in. If we changed our variable name to match here, then all of those properties could be applied at this spot in the custom element. And this would totally solve our scaling problem. So we see we have a pretty good story with styling, with Shadow DOM for encapsulation and custom properties for theming. But AdApply is a really important piece of that puzzle to solve that scaling problem. So I have some good news and a little bit of bad news, and then some more good news. So first the good news. Although AdApply is not standard in any browsers today, we have a shim in Polymer that's been around since Polymer 1 and carried forward to Polymer 2 and is used out of the box in all of those hybrid elements, along with the sort of spirit of the modular design of Polymer 2. It's an opt-in feature that you can load with the apply shim. But now the bad news, it's looking like AdApply is probably not going to make it into native implementation in browsers. And the reasons are complicated. There's some issues with nesting. There's some issues with how it integrates with what are called pseudo classes, like colon focus, colon hover. Didn't really play nicely together. And this is a link to Tab Atkins blog where he has all the great details and a lot more information about that if you're interested. But back to some good news. Tab and crew in the CSS Working Group have a better alternative, and that's part and theme. So why is it better? It's actually kind of how the platform itself accomplishes this type of theming, as we'll see in a second. And it's also a revival of a previous proposal from a couple years ago. But the issues with that earlier proposal have been addressed. So let's take a look at that really quickly. So this is a native input element, and it has an attribute called placeholder, which probably a lot of you are familiar with. It controls what's going to be shown in the input if there's no value there. And when this was out of the platform, of course, users immediately said, well, I got to style that. I want to style what that looks like. And the platform answer is what's called pseudo elements, and they have this colon, colon syntax here. And you can see it's sort of similar to AdApply. You can specify a whole set of properties here, just going to customize how the placeholder looks. In this case, it'll be orange and centered. So that's how the platform does it with pseudo elements. And a custom element with this new proposal would do it like this. Here's a slider element. And it's shadow root. I can expose these pseudo elements by specifying part attributes. So I make the slider have a track and thumb that's styleable, demable. And then users would be able to target these elements, these pseudo elements, like this with that same colon, colon syntax, now with part, and then the name of the part in parentheses. And so this kind of solves some of the same problems as AdApply. So that's looking good. It works better with pseudo classes, so that's great. But notice one issue, which is we had to be able to target the slider element. It had to be that element had to be in our shadow root in order to style its part. We can't do it from outside. So it's not great for theming, where theming is more of a global question. This is actually the fundamental problem with the earlier proposal for part. It didn't support this kind of composition. So the new proposal has an answer, and that is forwarding. So here is kind of a crazy syntax that may change. It's a little early still. But using this fat arrow, I can say users of my content view element here can style this slider's thumb by this new name here, slider1thumb. And it's comma separated. I could do the same thing for the track. But we also have a catch all that's proposed here. And that would expose all the parts with a prefix or a suffix. And then from, say, that content view element was in some my app element, I can target that exact slider's part there with a slider1 thumb. And it'll go and make that one blue. So that's actually pretty powerful. Looking good for theming. There's, of course, probably the more savvy of you are figuring that, OK, well, that looks a little cumbersome. I got to forward all that information. And that's good. That's explicit. That's probably what you want to do most of the time. But there's an answer for if maybe you can't do that all the time. And that's colon theme, colon, colon theme. It avoids this need to be required to forward everything. So if we use colon, colon theme, then that part name will be targetable anywhere in the shadow root of the my app element, even in shadow roots in elements inside of it. So how might we use this in our simple input example that we've kind of been going through? Well, let's go back to the template and look at that div that we had here that was for that underlying animation that users wanted to apply that styling to, that we used at apply for. We can just add a part, and that's all you need to do. So that's actually looking pretty good and promising. So part and theme were proposed earlier this year at the CSS Working Group meeting. There's a lot of enthusiasm for it because, again, as I said, it's kind of how the platform itself accomplishes this same goal. And Tab is currently fleshing out the spec. You can have input on it if you want. We're actually right now in the process of sort of thinking about what this means and when this is going to come actually natively in the platform, which we think is at least a year or two out. And how we might make a shim for this in the meantime. And so then if we kind of zoom out again and go back to the feedback that we had at the beginning here, making elements faster, smaller, easier to maintain, and add more features, we kind of think that if we make things sort of along the lines of that simple input using extension, adapting to the platform as we need, squint a little bit, that we actually might have made a lot of progress towards that. So let me now go back to the sort of demo that I showed at the beginning here. And this actually is not it. This is a new version that we've been prototyping with some elements made sort of along the same lines as that simple input element. You can see that there's some missing stuff yet. It's not all there. But the old version was built with hybrid elements. And it's actually a lot of code. It's bringing along all that Polymer One legacy API. It's more than 100K. The new version so far, again not done, is just 6K. So that's actually a ton better, and we're really happy with that. So there's still a ton of work to do, still early, but we're iterating pretty quickly. And that's all I have. So thank you. All right, so now we've got the second half, which is Kevin Schauff. So the thing to know about Kevin is he's actually a Game of Thrones die-hard fan. So feel free, if you see him anywhere around or at the Ask Polymer Lounge after his talk, ask him all about it. Normally the code of conduct we have and being kind to each other means no spoilers. So make sure you only talk to him about it. But he's seen the latest episode, so you can talk to him about that, but make sure no one else is around. But he may protest, he may say, no, I never watched that damn show, why did Matt say that? It's just an act. So Steve is here talking about elements and how to make our elements better. We get a lot of questions about how to make apps with Polymer and how to deal with state management and how to do the big things you need to know to build a big app with Polymer. So with that, we've got Kevin Schauff. Thank you, Matt.  All right, my name is Kevin. I'm a developer on the Core Polymer Library and today we're gonna talk about apps. So as you probably all know by now, web components are great for building highly reusable user interface components like the ones on the screen here. And that's not really surprising because that's kind of a core use case that web components, the specs were designed to try and solve. But on the Polymer team, we've also shown that web components are great for building applications as well. And in a lot of cases can be the only component model that you need to build an application. However, that's not to say that web components are all that you need to build really robust, awesome apps using the platform. And we get a lot of questions on the team about what that actually looks like. What's the end-to-end experience look like building applications with Polymer and web components? So that's what I'm gonna focus on today. So imagine this scenario, right? It's a Monday morning.  He comes running and he's like, hey, I know I've got a great idea. I know how we're all gonna get rich. I need you to build us a real estate listing app. Okay? Now stay with me. It's gonna be awesome. It's gonna have a really slick, cool user interface, really modern. Users can search for whatever they want. It's gonna come up in a nice list. You'll have sorting and filtering in the list. You can switch to a map view with pins flying around showing you where all the houses that meet your criteria are. You can go to a detail view, maybe a mortgage calculator up in the corner. All that data is gonna be pulled out of a server and kept in sync as it's changing. The users can log in, bookmark their favorite homes. Of course, we're gonna have a responsive layout so that this one app works on all the different form factors we need to target. It's gotta load super fast on 3G. It's gotta have amazing SEO, so users can find all these houses using our site. Of course, it's gotta be accessible and international to reach the most number of users we can. And you have two weeks to get it done. Right? So this is the question. Do you feel like you have all of the tools and patterns that you need to get up and start it quickly? To build out futures quickly and iteratively to deliver a great, easier experience with maintainable code that's gonna scale well into the future because that jerky boss is probably gonna want you to keep adding features after you get this first proof of concept done. So if we walk through the scenario from start to finish, there's actually a lot of things that we as web developers kinda have to learn and master and know where to start. So we need to make sure that we know how we're gonna structure our application to deliver great performance to our users. We wanna scaffold out our app from a good starting point so we don't have to reinvent the wheel with every app that we're doing. We wanna make sure we're following good patterns for factoring the UI so it's maintainable and reusable. We wanna make sure it's internationalized and accessible. We wanna make sure that we're following good layout patterns for responsive layout. We want to make sure that we have really solid and repeatable patterns for managing state in our application and making sure the application is easy to reason about. We want good developer workflows for serving and debugging and linting and testing during development. We wanna optimize our build for deployment. We wanna make sure that we're efficiently serving the application for deployment. It's a ton of stuff that we have to master to get an awesome user experience out. And it can get kinda blurry, right? Trying to figure out where to start. But the good news is there's help. So the Polymer App Toolbox we launched at IO last year actually provides answers for a lot of these topics. So the Polymer CLI, the init command there will scaffold out our application from a good template, a good starting point. We have the app localized behavior which helps us format strings in our Polymer templates and browsers actually now have good cross-platform support for formatting numbers and dates through the internationalization API. The paper elements that our elements team produces have always had a really strong focus on accessibility. Our app layout elements provide components for common layout idioms, responsive layout idioms. The serve command in the CLI gives us a nice development server to use while we're developing. Chrome DevTools actually has built-in support for web components which is really awesome. Shout it out on my custom elements and we're committed to helping the Chrome team improve the development experience using web components. Polymer Lint provides a static analysis during development. Web Component Tester gives us a framework for continuous integration. And the Polymer build gives us, performs a lot of the common optimizations that we need for minification, translation, that sort of thing. But as you can see, there are a few places of the story that I actually sat down and built this application that I talked about for this talk. And there are a few places of the story that I realized that we probably deserve a little more focus than we've given them in the past. So these are what I'm gonna talk about today. Talking about how we're gonna structure the application to hit the best performance, how we're gonna factor the UI, how we're gonna manage state in an application, a complex application like this, and how we're gonna serve it for deployment. So there's a reason that I put performance first on this list. And that's because the number one way you can make sure that your application performance is gonna be horrible, is to think about it at the very end of the app development. Get it all done and then go, hmm, I wonder how fast this thing loads. So you owe it to your users to make performance the number one concern for how you're structuring your application. And a lot of the front end web development world is enamored with this concept of server-side renderings as a means to good performance. Where they'll send down server rendered static HTML first to get something painted to the screen while we're waiting on the rest of the JavaScript to load. But when you think about it, unless your application is just a kind of a shell around passive static content, what the user actually wants to do is interact with your application, right? They wanna select a departure date or sign up for a newsletter or buy a product or bookmark a house in our real estate application. And server-side rendering really helps with none of this. It just gives them something to look at until the code loads so they can actually do what it is they came to your app to do.  And if you don't believe me, what I'm gonna show up here are two actual real-life server-side rendered applications. So I get this going. So, as you can see, they actually render to the screen really fast. And they give you this impression that you can start using the application, it's there. I've got this throttle down to 3G, so this is running in Chrome DevTools on kind of mobile type settings. And you can see it results in this horrible experience for the user. They have to sit there wondering when the thing is actually going to become interactive. And this is not to say that server-side rendering is wrong or a bad technique to have in your arsenal for good performance. In fact, Trey Shugard is here to give a talk tomorrow about some really awesome work he's been doing on being able to server-side web components on the server. But rather, it just says that there's just really no shortcuts to delivering a good user experience. We just have to be focusing on the right metrics. And for a lot of applications, the right metric is probably not the time to first paint but the time to interact with, the time until the user can actually do something on your site. And the best way to ensure a good timed interactive is this. Don't make the user wait for anything they didn't ask for. So that means only send down what the route requires in as few round trips as possible, sending as little duplicate information as possible between routes, right? And that sounds easy enough, but historically it's been fairly difficult to achieve. And this is why on the Polymer team, we've been working really hard to kind of promote and get people thinking about the purple pattern. And this gives us a straightforward pattern for factoring applications for optimal delivery. So in short, we'd start by factoring our application around decoupled routes that can all fit back together into an interactive experience. And then we're going to push down only the code that's needed for the initial route with as few round trips as possible. So only what the user asked for in their first URL, that's the only thing we should be burdening them with first, right? And then from there, we're going to render and get that initial route interactive as quickly as possible. And then while the user's enjoying the route that they asked for, we can, the service worker can boot up and in the background, we can be pre-caching the rest of the application. So the code needed for all the other routes in the background so that when the user is ready to move on to other parts of the application, we can then lazily import the code that's needed for the remaining routes right out of the cache and get those rendered quickly as well.  And it gives us a nice pattern to ensure that we're giving the user exactly what they want and no more, right? But that's not good enough just to follow the pattern. We actually have to be measuring. We have to measure the metric that makes sense for our app. And we recommend using WebHS for this. So they've recently added an easy mode so you can just go to webhs.org slash easy and it'll open up the site pre-configured for testing on mobile devices. So you just want to check the Lighthouse checkbox there, drop in your URL, hit start test, and then it will run a performance test of your application using real mobile devices and real throttle networks. Once it's done testing, you'll get a result page, something like this. If you click into the Lighthouse score, you can scroll down just a little bit and in there will be the timed interactive. So this is a really good metric to be focusing on when you're building your app to judge how good your experience is going to be. And then to ensure a good experience, we recommend setting a budget for yourself. And we like to target around three and a half seconds on these mobile 3G networks. And on these settings, the first byte from the server actually doesn't get down to the client until two seconds. That's because SSL negotiation requires a lot of round trips to the server.  So that only leaves you a second and a half to get something interactive. The thing that the user wanted to do on your app get that interactive on the screen. And we found that this one and a half seconds of budget, if that's what we're budgeting, translates into about 50 kilobytes of code, right? That doesn't sound like a ton, but with new Polymer 2.0, that starts at around 12K. So that leaves you about 40K left for your budget. As you heard in our last talk, we're doing a lot of work coming up in the future to make sure our element sets are highly optimized so that they can help you fit into this budget. And we found that the best way, anytime we're putting our recommendation out, we want people to follow us to give it a name, right? Because names are powerful. As soon as you have a name, you can talk about it with other developers and that sort of thing. So we're calling this one Purple 50, right? So this means apply the Purple pattern and budget yourself to 50 kilobytes. That's a good rule of thumb to ensure that you're hitting a good performance. Okay, so let's see what applying the Purple 50 pattern looks like in our real estate app here. So we're gonna start with an application shell that's responsible for handling the route on the client, loading the top level components for the route. And then we'll think about breaking the application down into meaningful routes. So for this application, we might have a home route and an explore route and a detail route. So we'll start with those features and then we can add more later on as the boss comes in and asks us to. And then for each of those routes, we're gonna build a custom element that encapsulates the view needed for each of those routes. So here we'd have a homepage, explore page, ETL page, something like that. And then following the Purple 50 pattern, we're just going to try and keep an eye out on the code that we're putting into each route and try and stay within our 50 kilobyte budget. So this is the general idea how we're gonna approach meeting all of our performance requirements and ensuring we have a good structure for the app. Okay, so we've got the structure down. Now let's move into how we're gonna start building out our user interface. So this usually involves taking UI mocks that designer might have sketched up and then factoring those, drawing boxes around them, bringing them down into individual components. Some of those we can get off the shelf and others are gonna be our application-specific components. And then we'll use composition to build those all back up into our final application. So we're gonna wanna leverage reusable components wherever possible, right? Because the best line of code is the one that you didn't have to write, right? And just like MPM is kind of our go-to source for JavaScript libraries, webcomonents.org is our go-to source for reusable web components. So we can go there and see what in the catalog might fit our needs in any given application we're trying to build. So for a lot of our app UI, we can just stand on the shoulders of others in the community and not reinvent the wheel where we don't have to. So if we look at our mocks, we can get elements out of the catalog, maybe tabs for the navigation here, maybe some icon buttons. Even the Google map, right? There are components for things like maps in the catalog as well. But again, using custom elements for our reusable, using custom elements are not just for our reusable components. We can use those to build our application-specific components too. And this has a lot of benefits over using a non-standard component model, some other library to do your application. So among these, so we can achieve a smaller payload because we're using the component model that's built into the browser. We don't have to download code to get that. Whenever we're scaling an app to a large team and encapsulation is really important to help with that coordination problem when developers aren't all working really closely together. And we get encapsulation for free with web components built into the browser. Like I mentioned before, Chrome has really awesome DevTools support for custom elements in Shadow DOM. And most importantly, our components aren't locked in to any given framework silo. I want to pause here because that's a really important point. I don't just mean that you're just locked into a different silo. That's not the point, right? The point is that as long as you're using custom elements as your component model and properties and events as your interface for the component in Shadow DOM to encapsulate the rendering, really how you transform the inputs to the component into whatever the component does is purely an implementation detail of the component. We have a really nice abstraction between the interface and the actual implementation. So we can actually extend from whatever base class we want without losing interoperability with other elements in our application. So if we were building an application, we could build the whole thing by extending Polymer element, our base class that we showed with Polymer 2.0. But that's just one choice. Down the line, we could switch some of our components over to using the simple element base class that Steve just talked about building. And those can totally work side by side in your application with Polymer elements. We could try Skate.js. Trey is here and he might sell you on Skate.js. You could try that out in your application without switching the whole application over. And someone is bound to make some new, better web component base class in the future that we all might want to shift over to. And we can do that incrementally over time without throwing our application away each time, right? So think about that. If you wanted to change from popular framework one to popular framework two today, that's a total rewrite.  When we start building our applications out of web components, it gives us this ability to incrementally change over time without having to throw everything away and without losing kind of the ability to innovate. Okay, so back to our real estate app, right? So let's take a look at how we'd factor our application views down into components. So let's just focus on this one route, this explore page element, and then we can use reusable elements from the catalog. So the Google map, the paper icon button, we can even use native selects here, style them a little especially, right? And then we might want to factor some of the rest of the view down into other application-specific components that we're just going to compose together. So we're just going to keep kind of breaking down and composing back up until we've got the final view for our route. And then at the top level of our application will be our app shell. And this component is responsible for the top level layout of the application. So the real estate app is our app shell. Inside of there we might have app toolbar, paper tabs, so it's doing the layout and the navigational components. And then the app shell is also going to have the code for the router. And then the knowledge of how to lazily import the components needed for each route. So if I go to the explore route, the app shell would be responsible for loading that explore route element or explore page element and getting it rendered and interactive. If user changes to a detail route later, it would load and get that element rendered. So to get started with an app shell template kind of set up for this sort of factoring, you can check out the Polymer starter kit template in the CLI to get going on that. Okay, so we talked about structure for performance factoring the UI. Next we need to bring our application to life by loading it with data and managing state changes in the application. So application state management is kind of one of these areas that the web platform has really had the least to say about. And so it's an area that we get a lot of questions about. It's probably our biggest area of confusion and questions and that sort of thing and request for guidance. So two years ago at our first Polymer summit in Amsterdam, I gave a talk called Thinking in Polymer. And it put forth the concept of a mediator pattern we think about composing and coordinating state changes between components. So just a really quick recap. In short, a mediator owns a scope of other components. So it owns them and is responsible for propagating data down to the components, listening for events from the components to handle user interactions, that sort of thing. And then based on those events, perhaps mutating some data and propagating those changes back down to the components it owns as well as up and out via events. So the mediator pattern is really useful for creating reusable standalone components that can handle their own complex state changes internally while still communicating the changes up and out. And that's because it encapsulates the statements management, so it's portable. So these are the kind of things you're gonna find in webcommonets.org, things that you get off the shelf. You don't have to, they don't have to tell you how to do your state management. It kind of comes along with it. And using this pattern, we've shown that you can actually just kind of keep composing mediators into mediators. And as you keep building that up, you end up with a final top-level mediator that's mediating other components and you can build your application out of that. So it's kind of the turtles all the way down mediator concept. However, the community has also shown that there can be benefits to having less granular and even global mediators of state. So it's kind of a trade-off space in a spectrum here. And particularly as components become more and more app-specific and are largely used to compose kind of more generic components together with application-specific logic, having one mediator for all application data can make the application more easy to reason about. And it opens up nice developer workflows that we'll see in a minute. So these global mediator patterns, so Flux is one really popular example, popular in the React community, they kind of formalize this concept of having one central place to put all the application state that flows down to components. And one place to dispatch events that cause application data to be mutated. And pass down. And so we can just think about you know, these kind of global mediator patterns as the mediator patterns, the instance of the mediator pattern is just at a global level, right? Now there are lots of choices out there to implement the global mediator pattern, kind of too many to go to in this talk. But a lot of times developers just come to us and say, just tell me one to use, just tell me anything that you know is good and I'll do it. And if you're looking for that kind of answer, we actually think Redux is a really good choice. It makes really well to web components and we know that people have had success for it. So Redux is really simple. It really has very little magic in it. It implements a really simple mediator pattern. And there's a really strong ecosystem that Redux has built. The library actually starts really simple, very easy to understand concepts. And as the needs of your application become more complex, there tend to be ecosystem based answers to handle that complexity. So a lot of times these take the form of add-ons that help you manage async flows of data in and out of a server, for example, or kind of complex flows through the application that the user is going to take, that sort of thing. Okay, so let's just take a look at what applying Redux to this application would look like. So first let's introduce some terms. So in Redux, the global mediator, they call that the store. And so for passing data down kind of into the application from the store, there's a subscribe callback that elements can call to be notified of any changes to state kind of the global state in the store. And then actions can be dispatched kind of in place of events, actions are dispatched to the store to tell the store to kind of change the current state of the application.  So these are functions that we write and give to the store that tell how to change the state based on actions that happen. So like I mentioned, there's a bit of a trade-off going from localized state management where it's all self-contained to global state management where you put it all in one spot. But one of the key benefits is that it opens up really nice developer workflows like the DevTools that ship in Redux. So this is a screenshot of the DevTools that you can install into Chrome.  And we can, on the next screen, I'll show what this looks like. But basically because we're centralizing where all the actions that can possibly mutate the state go, it's able to log everything that's happening in the app that led to a state change. And then because all the state is sitting in one spot as well, it lets us see all of the state altogether. So that kind of helps make it a lot easier to reason about as you're building an application. So here's an example kind of using the application in the DevTools. And as you can see, for every user interaction that happens in the application, in the action log there, we get an action that's logged. So we can kind of have a log of every event that's leading to a state change and actually see the state changing over time in the application. So for each user action, you get action state changes. And then what's really neat is it introduces this concept of time travel debugging, which you might have heard about. So it lets you scroll back up into the action log. And because the DevTools are snapshotting that global state object at every action, you can actually play back. You can go back in time, kind of look for, for example, if you had a bug, like maybe this little pop-up got screwed up there. I can actually jump back in time, find the action that caused the state to change in a way that caused the bug, and makes it a lot easier to kind of debug your app and find what's going on. OK, so there are lots of ways to connect custom elements to Redux. And it's fairly simple to do so. So I'm just going to show one way. There's lots to do it. But one way is to build your elements as generic views that just accept properties and fire changes out and don't mutate any state themselves. And then what you can do is then subclass that element so that the generic element you could use in any application in your lineup, that sort of thing. But then you can subclass it and connect it to the store of a given application. And then in the subclass, to connect it to the store, we would just have the element called the subscribe callback to Redux to get any state changes and set those into properties. And then we can add event listeners, just normal DOM event listeners that listen for events, and dispatch actions to the store that are going to change the data. And one other kind of pro tip I want to point out is that if you're kind of moving and looking into global state management techniques, most of them don't come out of the box with a way to kind of separate all of the state management code. It kind of leads you towards having a big blob of all of your application, its global state management. So you put it all in one spot. And this kind of runs afoul of our purple concept, right? We only want to load the code that the user actually needs for the route that they added. So that's something we want to pay attention to that we'll see here. So just very briefly, so pretend that Explorer page is the element that we created, the view just takes properties in and events out. And we're going to subclass it. In the constructor, we're going to call redux to the subscribe method. We get a new state object. And then we simply dereference any state that's needed in this particular component out of the store and set those into properties. And here I'm using Polymer 2.0 Set Properties API, which allows us to set a batch of properties to an element once really efficiently. And then on the other side, we want to dispatch actions and event listeners. So for any events that happen that should cause state to change, we just add an event listener and then call redux's dispatch method to send an action to the store. And here I'm using what redux calls action creators, which are just functions that we write that take parameters and return an action object. So I'm creating an action and dispatching it to the store based on the event. So we're going to do that for any events that our application fires that needs to mutate state. And then last, we want to make sure that we're lazily loading any of the state management code along with our element and not putting it centrally in the application. And the way I've done this here is redux has a lot of extensibility hooks. So I wrote a very simple enhancement to redux that allows me to add an API to the store to lazily install the reducers, the things that manage state changes into the store as more and more elements come in. They're lazily adding the state management code to the application. So here, the listings reducer is responsible for handling any changes to the listings. I load that along with this component, which, again, via the purple pattern is being lazily loaded just for that route and installed into the store. And then, likewise, any action creators, any action-based logic, you want to make sure that you're importing that along with the component as well. So we will continue experimenting with patterns for state management and how they can fit into web component-based apps. And I wanted to also call out a community library called Polymer Redux, which takes a declarative approach to binding Polymer elements to Redux. So that's something you could also check out. And like I said before, there's a ton of innovation happening in the community. And redux is just one of those. Most of those can also be happily paired with web components. So we encourage you to share ideas, share how you're building applications, share them with us, share them with other people at the conference today. So we're done managing state. Finally, we have to actually serve our application to our users. So we'll need to host and serve it to our clients. And although a lot can be accomplished by statically serving our client application, we feel that there are a few key minimal features that are required to be implemented on your server to actually get the best user experience. So these include serving the app shell for all routes. So based on any route in your application, making sure that you're serving the app shell, which is then responsible for lazily loading the components you need. Using HTTP push when possible to reduce round trips and to serve granular components when that makes sense to improve the efficiency of your caching. And when HTTP 2 is not possible, then alternatively serving bundled assets but that are bundled per route. We want to make sure that we're sending the optimal code down for the capabilities of the browser. So for browsers that implement ES6, for example, we might want to take advantage of native custom element subclassing by sending non-transpiled code, for example. And then finally, we want to make sure that we're serving SEO-compatible output for any bots that might visit our site. So we've been doing a lot of work on a reference server that does all of these good things that we're calling purple server node. And that's designed to work hand in hand with the outputs that come out of the Polymer build system. So it's a node-based server that's set up for client-side routing. And then it has a lot of extra features to do these kind of smart things. When I was doing a run-through a couple of days ago, Chris, awesome developer on our team, was like, you're kind of short-selling purple server node by using that kind of lame database clip art there. Can't you jazz it up a little bit? Because the server is actually pretty awesome. So I put some sparkles on there. I don't know if that made Chris happy. But basically it has some presets in there that allow us to that can automatically detect the capabilities of the browser and serve the optimal code for each. So for browsers that have ES6, for example, it can serve raw ES6 code so that we can take advantage of the native ES6 subclassing of custom elements in the browser. And then for browsers that don't have ES6, we can serve the transpiled code as well. It can also differentiate between browsers that have push so we can serve a granular component to reduce round trips when possible and serve bundles for non-push compatible browsers. And then it will kind of do the permutation of things and serve the right set for the capabilities of the browser. And then last, kind of under this heading I'm calling bot, so these are things like Google being search crawlers, that sort of thing, as well as social snippet generators that kind of create the cards that show up in social networks. We're actually integrating purple server node with another project that we're working on on the Polymer team aimed at tackling this SEO problem with web components. And that will actually serve rendered HTML, fully rendered HTML that's compatible with SEO and social snippet generators. And I'm just going to tease that today because we have a whole talk on that tomorrow that you guys should stick around for and check out. All right, so you can check out the beta of purple server node here. Give us feedback. So this is kind of set up for you to deploy onto a hosting site like App Engine, something like that. Sit behind a CDN and get really good serving efficiency. OK, so with purple node server, we kind of fill in the last big gap in our story about how we're actually going to deliver these awesome experiences using the platform. And hopefully you feel more confident now that you have all the tools you need to build robust real world apps like this real estate app. And at the beginning, I said we had like two weeks, right? That was our setup. We had two weeks to build this. So to be honest, I didn't have a whole lot of time to kind of put this talk together, but I really wanted to build an app. And I actually was able to build this out in two days, this much. It's a proof of concept. I still need to do a little more work to get the demo ready.  So hopefully from this proof of concept, I feel that I'm way more confident now that I've got a really well factored UI with components that I can reuse across other applications. I've got easy to debug state management that will scale well to adding more routes, adding more features. I know I'm going to be set up well for performance. I've got a structure that scales well for performance with the purple 50 pattern. And I've got a great serving environment with purple server node. So hopefully you feel like you can be this productive with the web platform too. So we're going to continue working to take all of these kind of best practices that we come across as we kind of tackle more and more challenges on the web platform and provide guidance and provide features and provide products to help help move this along. Thank you very much. All rig