 All right, thank you, everyone. And welcome to the first ever Polymer Summit. My name is Taylor Savage. I am the product manager on the Polymer team. It's going to be an amazing day. We all just can't wait. It'll be a whirlwind tour through everything that we do on the Polymer project. But right off the bat, I want to say thank you. So thank you to our incredible Dutch hosts in this beautiful city of Amsterdam in this incredible venue. Thank you so much, as Matt said, to the Polymer team, to the Chrome team, to all of Google. Everybody who's put in so much work to make this happen. And you can really see how passionate the whole team is, that everybody's out, everybody's here to answer questions. We're so excited to meet all of you and hear what you have to say. And finally, thank you all for coming. We have developers here from every single continent except Antarctica. We're going to work hard for the next summit to get some folks out from Antarctica. But I want to kick things off first before we dive in to the really hands-on talks to kind of give a little bit about where Polymer has been in the recent past and where we're going in the near future. So just the other day, it was Chrome's seventh birthday. And Polymer is part of the Chrome organization at Google. We are the official developer library of the web platform at Google. And we sit next to a lot of the Blink team who actually works on the Chrome renderer up in the beautiful Google San Francisco office. So for Chrome's seventh birthday, we had a nice toast with the whole team. It's really exciting to see a product come so far in seven years. And if there's one thing that you should know about the Chrome team and the web platform team is we really, really, really love Legos. And who doesn't? Legos are awesome. Polymer team as well, we really love Legos too. And Legos are a great metaphor for the kind of things that Polymer lets you build and that web components that you build. They're composable. They're modular. They're reusable. You can use the same kinds of pieces to build really, really incredible things. And so as a nice little diversion from preparing for the summit, we had a Lego building contest for Chrome's seventh birthday across the entire office. And I am very, very proud to say that the Polymer engineering team won the Lego building contest. These are their creations or abominations. The challenge was to build the craziest seven for Chrome's seventh birthday. But instead of building sevens, our engineering team really should have been building threes. The master branch of the Polymer library is about to turn three years old next month. So our first commit was on October 10, 2012. Back then, the project was called Tool Kitchen. And the very early spec of web components was just kind of getting started. And Polymer and web components were evolving in tandem. So this is from the first commit on the read me of GitHub. And what I really love about these early Tool Kitchen commits is how both foreign and familiar they are to today's Polymer. So the names and the APIs have obviously changed dramatically. But the fundamental tenets of what makes Polymer Polymer have remained exactly the same. So you can see on this first read me, it says, emphasis on modularity and encapsulation via a component model. Be declarative. Say what you mean. There's another reason we should have been building threes instead of sevens. The 1.0 version of the Polymer library just turned three months old. It's really amazing to see how far it's come and how far the community has come in just a short three months. We've been seeing incredibly exciting and exponential adoption and innovation on the 1.0 library. So there's been exponential growth on the public web for applications built with Polymer 1.0. Over 150,000 public-facing production web pages are using Polymer today. Actually, when I landed in Amsterdam, this slide read 100,000. And I have to update it since we were here. Starterkit has been downloaded 65,000 times. And the paper elements are used on thousands of different websites. And some major companies are also really seeing and buying into the component model that web components in Polymer now lets you build with. So this is a quote from a recent article about ING Direct's adoption of Polymer. And this is from their IT head of strategy. We no longer build applications. We have and are enriching a modular market sourced from industry and the ING global community. Modules are assembled into applications as the business requires. And I think that's just a really elegant statement of this new world of web components. Polymer 1.0 internal adoption at Google has also been growing spectacularly. So over 300 projects internally at Google are now using Polymer 1.0. And we just launched three months ago. And as everyone here knows, it can take a really long time to build applications and then ship them out into production. But we've already seen some pretty exciting production ready launches of Google products using Polymer. Patents.google.com recently launched. And then even more recently, the YouTube gaming site launched in production on the web using Polymer 1.0. So you'll see more and more of these coming out in the coming months as these products that are building with Polymer go into production. So now, barely three months old, we are here at our first ever Polymer Developer Summit in beautiful Amsterdam. I've gotten a lot of questions. Why Amsterdam? Why did we pick Amsterdam to have a conference? So first, why not? It's a beautiful city. There's an incredibly strong developer community here and in broadly in Europe. It's a beautiful location. It's a beautiful venue. Amsterdam and San Francisco are also very similar in a lot of ways. They're these both gleaming cities on the water, relaxed policies toward recreation, just a lot of fun cities to be in. And the Polymer community is also spread out across the entire world. So this is a map of where we held Polytechnic events last fall. And as you can see, again, every single continent, there is a group of devoted Polymer developers to hold these Polytechnic events, except Antarctic again. There are holdouts, but we're working on that. There's another connection, though, between the Netherlands and web components. So about four years ago, Alex Russell first introduced web components at the Frontiers Conference right here in the Netherlands. So the web components in Netherlands go way, way back. And on web components, they've come an incredibly long way from Alex's talk just four years ago. And recently, there's been some pretty significant steps toward broad browser adoption on web components. So I want to give a little update on where we are. As a quick recap, there are four specs as part of the kind of web components umbrella. There's the template, which is native-side templating on the web. There's Shadowdom, which gives you these really nice composition primitives. Custom Elements, which lets you create your own DOM nodes and DOM elements. And HTML Imports, which lets you load web components, so loading HTML with HTML. And of these four specs, they're all critical. This is the foundation upon which Polymer is built. Template and Shadowdom, in particular, are really the hardest to polyfill. And they're also the ones that give you the true encapsulation and reusability and composition that is so wonderful with web components. And I'm really, really pleased to say that we've made incredible progress across all the different browser vendors on getting closer and closer to shipping broadly with template and Shadowdom. So browser standards conversations can be really subtle and delicate. And I really don't want to put words in anyone's mouths. So I'm going to use direct quotes from the other browser vendors on these specs, in particular. So Wilson Page from Mozilla recently published a great state of web components article that ends with this quote, web components have been in planning for over three years, but we're optimistic the end is near. All major vendors are on board enthusiastic and investing significant time to help resolve the remaining issues. So that's really exciting. The Microsoft team, the Edge team, has also been working really, really hard to get web components in the new Edge browser, which we're so excited about. So this is another quote from a recent article by Travis and Aaron on the Edge team there, where they wrote, we are happy to announce that we are starting development to add HTML template element support to Microsoft Edge today. This is just the beginning of our web components journey. The next goal is to implement Shadow DOM. So you can actually check up on the status of Edge implementation on Shadow DOM with this link on the bottom right. And also from Microsoft, Daniel Buckner on the Microsoft team is working to actually build out Microsoft specific web components using the XTAG library. And so we've actually demoed Polymer components and XTAG components working together on the same page with no problems at all. It's kind of the beautiful story of interop of web components. So we're incredibly excited about this too. And the WebKit team has also been contributing really deep and fundamental innovations to the specs, including the latest Slots API for Shadow DOM. So we're really excited to be working with the WebKit team as well. So as you can see, it's a really incredibly exciting time. Browser vendors are all working together. We're all making contributions. This is kind of out of the ordinary. Web standards processes can be slow and arduous, but I really, really think that we're in one of those renaissance periods of true innovation on the web platform and specifically around web components. So web components have come a really long way. Polymer library has come a really long way. It's being used in production on some of the biggest sites on the web. It has enormous momentum. It has enormous investment, but we're really just only at the beginning. Now today's conference is gonna be all about building things. This is a developer conference through and through. We'll be going deep into the practical know-how that you need to build really great experiences on the web with Polymer, which is our whole goal. So we'll be touching on three main themes today. The first is develop. So how you can use all of the features that Polymer gives you and the Polymer elements give you to be able to build end-to-end applications using Polymer. The second is design. So how you can make sure that your Polymer apps look and work great for all of your different users. And then finally, deploy. So how you can make sure that your app is fast and production-ready on the web. And we don't want today's conference to be about big splash announcements. This is a developer conference, and we wanna be hands-on and help building apps from start to finish. But I would like to paint a picture of where we see Polymer going in the near future. So our mission, as we've said before, is to help web developers just build great experiences on the web. And you are all out on the bleeding edge with us. Polymer is not just another framework. It is a massive change. It is a sea change in how we do web development. And we need to make this easier for developers that aren't as brilliant or awesome or good-looking as all of you, and all of you on the live stream as well. So there are three ways that we wanna help developers in the near future work and build with Polymer. We wanna help you decrease your developer friction, achieve great performance, and then build complex apps using Polymer. So how are we gonna do that? Decreasing developer friction. Using HTML with web components is a revolution in how we do front-end development. But it could be even more awesome. And there are a couple of sticking points in particular that I'm sure all of you have faced at some point or another when building with Polymer that we think that there's big opportunities to make improvement. So the first is managing and using elements. And elements are great. Our whole mantra, there's an element for that. You have a problem that you're running into when building your application, and there's an element for that on the web that solves your problem that you can just use. And the problem today is that this isn't necessarily true. There might be an element out there that solves your problem, but to get it into your application, first you need to install Bower, and then you need to install the element, and then you might have to resolve some dependency conflicts. It's just not really an elegant process to even use that element for your first time. And we really think that this should be as simple as this should be using element. You should just be able to import the element and then use it on your page. It should be like loading it from a CDN. You should never have to think about these dependency problems. So we're working on a tool, Google is working on a tool called Polygit to be able to load and deduplicate all of your element dependencies in the cloud on the web. So this will make getting started with new projects easier. It'll let you use elements in environments where you might not necessarily control the server, and it might even give you CDN-like performance in production applications. So we don't necessarily see a Polygit-like tool as blowing away client-side dependency management, but we do think it'll provide a much smoother on-ramp to getting started building applications using Polymer and these elements. The second developed time experience that we can help improve is actually writing code and actually editing code. So when we're developing the Polymer core library, there's a mantra that we kind of keep repeating, which is that every byte has a cost. Every byte has a cost. Polymer is so lean that we don't include error message strings inside of the actual library. So it can be a little hard to know what's going wrong when you might have a bug. And this leanness is really great in production. It's what you want, but it can kind of make the developed time experience tricky and hard. So you might have run into this problem, the dreaded blank page problem, where you're editing in your text editor. Yeah, some people have run into this and you make save and you refresh the browser and you just get a blank page. And there's no error in the console, nothing's showing up, you just kind of have a blank page. And this can be really frustrating. And more than likely, it's just a small typo or you forgot an import somewhere. But still, it's that kind of grinding feeling when you run into a wall with this blank page. And we don't think this should ever happen. So we're working on a tool called Polylint. Polymer is lean and light and we want to keep it that way. So we're going to move all of those developer error messages into this tool called Polylint, which will help you at developed time constantly link your application and make sure that you're not making these kind of errors. So you can catch them before you even refresh your browser and run into that blank page. And Polymer's MO is all about composability. So I'm talking about a bunch of different tools, you know, Polygint, Polygit, Polylint. And these are, you know, it's a lot of different tools. That's absolutely true. It's a bunch of small tools. But the beauty of Polymer's is composability. So we want to build the tools in the same way. So you can compose these tools into bigger tools to build exactly what you need for your workflow. And so we'll get into a little more on this with talks later this afternoon. The second big thing that we want to help developers with is achieving great performance. So Polymer is a Swiss Army knife. You can build really awesome, cool things with it. You can also build slow things with it. It lets you do whatever you would like. So we're working on a number of different tools to help you get deeper insight into the performance of your application and the Polymer elements that you're using. So the major cost when you're building an application using Polymer is using lots of elements. The elements are super great. You know, they let you do all these kinds of cool things, but they're not free. Just like if you were working with basic HTML, if you're using tens of thousands, 100,000 elements on a page, it could get slow. And so the big problem is that knowing the cost of your element is really critical to achieving great success with your application in Polymer. And so we want to make this element cost much clearer as you're developing the application so you can kind of optimize throughout and know where your bottlenecks are. So we're working on a tool called Polydev to help you measure what we call kind of the atomic mass of a particular element. So what a single element's cost might be and then more broadly how all of these elements contribute to the overall performance of your app so you can really see where your bottlenecks are when you're building with elements. We'll be using these tools to constantly be slimming down our own elements. So we focused on performance of the core library with the 1.0 launch and we'll be using this as a major effort to slim down all of the elements that we released with Polymer. And it really speaks to the great part of reusing elements is if we make an performance improvement to one of the elements and you bower update, you're just a bower update away from getting a lot of these performance improvements. So keep your elements up to date. And if you're developing elements, same thing, you can constantly be improving the performance of your elements and your users are just a bower update away. Finally in the performance bucket is HTTP2. We've seen some really incredible gains with the brand new HTTP2 standard can achieve in terms of loading cost. I would love to tell you about it because it's really amazing but Eric is gonna talk a little bit about them this afternoon and he would kill me if I spoiled the surprise. But suffice it to say that with HTTP2 and PolyGit, we're starting to really see this radical simplification of building web applications out of components and we're working to make this feasible and possible really, really soon. So the final thing that we wanna help developers with is in building really complex apps. And we talked a little bit earlier about how the Polymer team is, we're big fans of Legos and Legos are a great metaphor for the kind of things that we build. And one of the ways that the Lego analogy really, really works is you can build incredibly complex things all completely out of just Legos. You don't need anything else. You can just use Legos and build incredibly complex structures. And this is because all Legos can form to the same basic format. This is great because you can totally mix and match Legos from different sets. You know, you can buy a set over here, you can buy a set over there and you're guaranteed that all the parts are just gonna work together. And again, this is because they are all using the same basic format. So I looked this up. This is the original Lego patent. And those little nubs on the top of the Lego are called studs and the holes on the bottom are called tubes. And no matter where you go to buy a Lego, you're just gonna have the exact same stud height and the exact same tube width. And this simple stud and tube model is what gives you this powerful interoperability so you can use all of these Legos together, guaranteed and they'll all work together and you'll be building really strong structures out of it. The stud and tube model for the web platform is DOM. You have nodes and you have events. And Polymer directly lets you use this platform at the metal to help you build elements. And when you're building elements right on the platform, when you're building right down to the metal, the performance improvements that browser vendors make and the performance improvements that come with browsers are reflected right away and immediately in the applications that you build. So we think that the best way to build web apps on the web platform is to actually embrace the web platform. We don't necessarily think that the future of web development is going to be throwing away the platform and building your own kind of platform and user space on top and then throwing away that platform when a new kind of user space platform comes around. It's a bit like building a Jenga tower on top of a base of Legos. Elements benefit directly from the consistency of the platform and are fundamentally of the platform and you get all of the benefits that come with that. So we focused our element product lines that we build on the Polymer team on solving really, really minute and specialized problems for specific use cases. We built the iron elements, the paper elements for material design, the Google Web components for wrapping Google APIs in elements, the platinum elements for the cutting edge web platform features, the gold elements for e-commerce. And we're going to continue expanding this model, dramatically increasing our reach in e-commerce vertical and potentially the publishing vertical as well, in addition to new verticals. But the one major set of problems that we haven't really tackled on the Polymer team yet with elements is how you structure an entire application end to end. And we get a lot of questions about this. I want to use an element. How do I do app layout? How do I do routing? How do I do lazy loading? And our answer up to this point has been, they're Legos. You can put them together however you want. You can use a library that you want for routing. You can wrap it in element. The world is your oyster when it comes to elements. Polymer is, again, a Swiss Army knife. It doesn't enforce the kind of app-level architecture or hierarchy every little piece of how you need a structure application. It leaves it up to you, the developer. But the problem is that there's a little bit of paradox of choice here. If there's so many different ways to structure your application, it's hard to know where to start and that can be frustrating. So I'm really, really pleased to announce that we are working on a new set of elements, tentatively named the carbon elements, that are all focused around solving these application-level structural problems. So when you're building with components. So things like routing, layout, lazy loading, and everything you need to kind of build an entire application. Now, I want to be clear, these are definitely not the only way you can solve these problems with elements. Obviously, if you like a different routing library, you like a different lazy loading solution, you can swap these in and out. They're just elements. But we will build a polymer idiomatic and framework-oriented set of components with the carbon elements. We think that the best framework can sometimes be the platform itself. And so these elements will really reflect our philosophy here. So this is in its very early stages. We'll announce more as these ideas develop and we're obviously gonna open them up on GitHub very early so you can kick the tires and start playing with them, giving us your feedback. So there's lots of new and exciting things in Polymer on the horizon. We'll be decreasing developer friction with code hosting and code linting tools. We'll be making performance easier with all kinds of element measurement tools. We'll be providing a well-lit path to structuring end-to-end applications using Polymer components. So we're just incredibly excited for the next steps of the Polymer project and to continue working closely with all of you as these tools evolve and grow. So to stay up to date with the latest, you can follow the Polymer blog. We will keep constant updates there. You can follow us at Twitter or on Google Plus at the Plus Polymer projects. But enough talk, enough promises. Let's get down to actually building stuff. So I'll throw it back to Matt to introduce our next speaker. Thank you.