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 hide a 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. Hello and welcome to day two of our Polymer Summit. So we've got a bunch of really, really awesome speakers here for day two. And to start off is two of my oldest friends in this industry. I've worked with Ben and Dion for about 10 years now across three different companies, just the latest being Google. And I'm such old friends with them. You saw they let me write their abstract for this talk, which if you notice, they're gonna do some interpretive dance. So definitely pay attention near the end when Dion lifts Ben over his head and twirls him around. It's really spectacular. So with that, I'd like to welcome onto the stage Ben and Dion. It's a pleasure to be here with you this morning to kick off day two of the Polymer Summit. He's Ben Galbraith. And he's Dion Elmer. So to start out with, I do have a bit of bad news. We have actually been practicing our dance number for quite a long time now. Yeah, and we were just informed that we didn't get the riots for the music. Oh man. It's a shame because we had tailored this number to this one particular song. And without it, we're just gonna have to move on to our backup talk, which we'd prepared just in case. There's one little bit of good news though, which is Rob Dodson snuck in and did a little video of us practicing. So maybe we'll get something for next year. Yeah, maybe, maybe. So we've both been working on the web for a really long time. Initially as developers, building things on top of the platform back in the mid-90s. And we've worked in various capacities, places like Google, Palm, like Matt was just talking about, and Mozilla pushing the web platform forward. And now we're at Google. This is Dion's second time, my first, where Dion leads developer relations. And Ben's product lead on Chrome. And in our new roles, we're in positions again to help steer the web. And so we've been thinking a lot about its future. And this morning, we wanna share some of our thoughts with you, just to sort of get a conversation started, both here and afterwards, and hear your feedback about where the web platform should go. And as we've got to riff on this again, and really kind of go deep, we can't wait to share just how excited we are about the future of the web. Which may not be obvious to some of you, because the web's actually been through some tough years lately. Which is kind of a shame, because the web in its early years was such an amazing wonderkin, sort of personified by Mark Andreessen on the slide. It's amazing when you sort of sit back and ponder all that the web was able to accomplish in such a short time. And I think one of the first accomplishments that comes to mind is the global disruption of basically every industry that the web kicked off that's transformed the world we live in, and that disruption is still reverberating today. And before the web, do you remember this? Do you remember using things like Gopher, FTP, IRC? You know, I was at the University of Minnesota. Yeah, there we go, there we go. Wow. I was at the University of Minnesota where we gave birth to Gopher, and it was really useful in the computer lab, but not so much for kind of the average Joe. And so really the web, to me, kind of packaged up the internet and made it the first consumer-friendly and really developer-friendly platform. I gotta tell you, I'm a little upset about all the applause because I'm gonna have to listen to stories about Gopher now for the next two weeks. It was amazing. You know, the iPhone, we sort of forget about that eye in iPhone sometimes, and that goes back to the iMac where it explicitly stood for the Internet Mac because back when Steve Jobs came to Apple a second time and sort of figured out how to bring the Mac to market, he felt like he needed to do something different to compete with the Windows app ecosystem. He had to change the game, and so he marketed the iMac as the best way to get to the Internet and position the Internet as really the thing that mattered, not apps. And he kind of had a point back then because the Internet was where all the cool new content was that people wanted to engage with. And so the Internet, in addition to its other accomplishments, it also opened up the marketplace again for a platform like the Mac to come in. Yeah, and it wasn't just the Mac. Can you imagine using Linux without being able to use a browser? So at this point in time, the web was a truly unprecedented success. Then what happened? The web had a little younger brother come along, we'll call him Mobile, and when your first younger sibling comes along and got this cute little baby, who doesn't love a little baby, right? He doesn't love her. Look how cute it is. And even had cute little toys that it could play with. These were so fun. You could do some fun, cute little things with them. And like a lot of younger brothers, you try and kind of emulate and act like the older brother. So he tried to do cute little web-like things back then in Mobile. And then before you knew it, that little brother, Mobile, grew up and turned it to something that was, maybe something that someone might think is a little bit stronger, a little bit more capable, a little bit more talented than his older sibling. And people suddenly noticed. And before you knew it, Mobile apps became the new thing. And at this point, we started to question, were the web's best days actually behind us? And you know, the web's been through lots of difficult moments before. If you remember things like Java applets, Flash and Silverlight, all tried to go over the top of the web and replace the web with a different UI layer. And the web's constantly been able to reinvent itself in pivotal moments like Firefox coming to market and restoring browser diversity at a time when people openly questioned whether there was even a need for browser innovation. Or Ajax spurring a reinvention of web apps, resetting what was even possible to build on the web. Or Chrome bringing speed, stability and security to a whole new level and enabling the landscape we have of really sophisticated high-performance web applications today. So the web has this history of reinventing itself to adapt to the changing landscape and new opportunities. And then mobile certainly became another one of these opportunities, right? At this point in time, the web as the vendor kind became maybe a little bit bloated, maybe a little bit out of shape compared to mobile apps. And it was time to kind of get back to the gym to get fit again. And we did that. And that resulted in things like AMP, PWA, all of these capabilities we've been talking about the last few years, making the web truly awesome on mobile. And that continues as we come with new technologies like WebGL, WebAssembly, Houdini, et cetera, et cetera. The web's working out hard to enable these new class of applications. And so now the web's kind of catching up to that younger brother, but... What about the future? As we look forward to what's on the horizon, we actually think the future of the web is set up to be really exciting. And to explain that, we want to talk about three trends that are just around the corner and how the web is situated to meet these opportunities. First, the proliferation of even more devices. And we want to talk about augmented reality for a minute. And finally, we want to talk about assistive interfaces. To start out with, let's consider today's smartphone desktop world. There are so many devices. It's really hard as a native developer to keep up with compatibility across all these different devices in all the worldwide markets. And that explains why things like watches and smartphones, sorry, watches and tablets aren't universally supported because of the effort required to extend to these. And then consider smart TVs, which are pretty ubiquitous, and other smart devices that are now hitting the market and new ones that are just around the corner. How are we going to manage developing for all of these different devices? And it sort of helps you realize that native is really fun when you're targeting a relatively homogenous device surface, but it can be a nightmare when you're tackling all of this complexity. And so it really makes you appreciate that native makes the most sense when you're creating an experience that's tailored to a particular device or device sort of profile. And that's really why you sort of use the word native because it sort of indicates that you're targeting something that's really specific. And then also help explain why one of the world's most popular, vertically integrated hardware software companies has their own native SDK split into different flavors for watches and TVs and tablet smartphones and laptops. It's sort of like us coming to Copenhagen for the best experience. We'd love to like fully understand and learn Danish, but A, that's kind of hard. B, we're only here for a week and that doesn't really scale. Like we're going to Poland in a couple of weeks to speak at a Google Developer Day. Fortunately for us, there's a cross-platform language called English that's kind of a fantastic alternative. Thanks very much, by the way. And so the web's always been about this trade-off of sacrificing sort of tight native coupling for the ability to adapt to a wide variety of devices and platforms. And the idea of the web adapting itself to these wildly different device types has been back to the web in the very beginning. Even the original version of CSS contemplated the feature to enable a web page to adapt to text-to-speech devices, for example. And these mechanisms in the web were largely ahead of their time. You could use them for theming and you can see this in sites like CSS ZenGarden, but now in the multi-device world we're entering, we're finding new use for these mechanisms and things like media queries bring them to a new level of maturity and usefulness. So as we enter into this multi-device world, we think the web is actually ideally situated to help us cope with its challenges and it's ready for this fundamental trade-off that will be required to scale to this world we're entering of new platforms, form factors, and modalities. Let's talk about augmented reality for a second. You know, with AR, we're seeing a lot of these different scenarios pop out that are pretty compelling. You know, we're merging digital and physical objects for shopping, gaming, and much, much more and seeing it through a phone is neat. It's already useful. It's nice to be able to kind of go zoom in and play around with things, but what's gonna happen when this explodes in the future and we get full field of vision through glasses or whatever technology is actually gonna bring this to you, we think this is actually gonna be pretty fantastic. And when you think to this future, you look at the heart of AR, to us, it looks kind of like a browser. It's about mapping physical addresses to virtual content and this is what the web does every day through URLs. And what do you want here? You wanna link to third-party content to seamlessly browse around and explore different things that are out there in the world. You don't want to install apps for every experience as you go around. So to us, when we look at AR, it seems like a natural extension to the model of the web itself. The last thing we wanna talk about are assistive interfaces because now that computers can understand you when you speak to them and they can speak to you, it's a fantastic way to get things done. I mean, really, why use the linked list of native app launchers and bespoke app interfaces when you can use the voice hash table to get right to the functionality bucket that you're looking for? I mean, it's pretty fantastic if you can say set a timer for 30 minutes instead of having to open up the app and navigate through it, it's really effective. But not always. Does anyone remember calling into phone hotlines, something like a movie phone listing where you're sitting there on the phone while this voice comes back with like, there are 10 movies close to you. First movie? Does anyone remember calling in? Was that a thing here? There's like a hand in the back. There's one hand. It was like, all right. Painful voice trees. Everyone's gone through that a little bit. It was a very frustrating experience. And it really shows that assistive UIs to be effective, they have to span all of the screens in our life because you wanna be able to start a session and have that session seamlessly go to whatever screen is around you. In the movie phone example, you wanna be able to use your voice to say what movies are playing, then you wanna see the listings on a tablet or a TV that's close by and communicate which one you wanna see. And so this means that the assistive ecosystem that we're running into also is coupled to the device problem we mentioned earlier, but it introduces another problem because now the assistant has to act as an agent for the user and in order to do that, it has to understand the content of the experience. Where have we heard the term user agent before? So in order for this to work, we have to introduce a semantic layer into our content which again takes us back to the future of the web. As a recent article by Zach Bloom on the history of CSS sort of reminded us that included this awesome quote from Mark Andreessen where he talks about having to explain to developers that it's a feature of the web that you don't actually get to control the presentation of your content. That the web is just about content. That actually eventually failed as browsers bowed to pressure to hack in presentation tags into HTML. And the web tried again with CSS. The original vision of CSS was to enforce this separation and also there was a failed pivot to XML and XSL. Do you guys remember that anyone? Again, no, we got a few, more than a movie phone actually. So we've tried and I think these attempts really ultimately failed because they were just too far ahead of their time. Ultimately, everyone was just trying to display pixels on the screen and this sort of multi-device, multimodality future was science fiction and that there's one thing we're really good at as developers is finding the easiest path to solutions. But with the need for intelligent agents to broker these experiences and for those agents to understand what's happening, we think it's time for us as a community to revisit these ideas and evolve them for the future that we're running into. And now we have web components where we get to separate semantic markup from the actual implementation. We've barely scratched the surface on how we can separate those things at the moment. And so in review, when we look at these trends, when we look at the devices that are coming and augmented reality and intelligent agents, we think they actually play to the web's strengths. And it's one of the reasons why we're so bullish and excited about the future of the web and it also paints for us a potential roadmap of where the web needs to go from here. So coming back to the brothers again, they each had their kind of time in the sun. At this point, they've kind of matured. We've got mature platforms on both native and on the web. And we believe both actually have a long future ahead of them. We've got interesting things to come. Unless, of course, another little brother or sister comes along and gets to usurp them. Thank you. Thank you very much. So I know the lack of dancing was very disappointing for everyone. It was disappointing for me. But happily, since the Codelab area isn't actually being live streamed, I'm pretty sure we have the rights to play their music over there, seeing if they're still paying attention. So there's a lot of things we do on this team that aren't actually Polymer. That's why it's called the Polymer Project. There's the polyfills that everyone thought were Polymer. It's the elements we build that everyone think are Polymer. But we do a lot of experiments as well. And one engineer in particular, we have really, really, really likes to experiment a lot. And here to talk about one of his latest experiments is Justin Fagnani. Hello, hello. So my name is Justin. And I work on Polymer tools. So normally, I'd be up here giving you a tools talk. But like Matt said, I like experiments. So right now, I'm going to do something a little bit different and talk about or give you a sneak peek on this library we've been working on that we're very, very excited about. And this is only a 15-minute talk, so I'm going to go really, really quick. Hold on. All right, so I'm going to talk about templates. And obviously, we're going to talk about HTML templates. And so we're very familiar with those here, because templates are pretty central to the Polymer developer experience. But HTML templates and other techniques for updating DOM have been around for a long time. And they're constantly evolving. So before I get into this library I'm so excited about, I wanted to give you an extremely brief history of HTML templates. So in the beginning, we had manual DOM manipulation. You had to create some nodes individually, wire them together in a tree, and then maybe hold on to some of these nodes so you could update them later. And this was a lot of code. It was verbose. It was not very fun to write or to look at. Alternatively, you could try to use inner HTML. You could build up a string of HTML. Then you inject it and let the browser take care of creating the nodes. But then if you wanted to update it, you had to traverse this tree or use query selector or something like that. So it ended up being a lot better. So then we had this Cambrian explosion of declarative template systems that embedded expressions inside of them and then control flow constructs like ifs and for loops. And Polymer belongs to this category here as well as systems like Angular or Ember. And then a few years ago React introduced JSX and VDOM, virtual DOM, into the world, which take a different approach, both syntactically and functionally. So JSX isn't standard JavaScript syntax. It's an extension that embeds markup into JavaScript, which is then compiled out with a transformer. And virtual DOM took a new approach to updating the DOM. Instead of pinpointing exactly what data is embedded into the DOM, it just goes ahead and re-renders the entire tree, the entire template. And it does this in a virtual tree and then it compares that to the last data it had, figures out what changed, and then applies those changes to the DOM. So with all this evolution of templating solutions, what comes next? Something does come next, right? There's always a next. Well, we have one idea. And since it's 2017, obviously that means that idea is going to come from ES 2015. And that, we think, is JavaScript tag template literals. Template literals are one of the most unsung features of ES6 or ES 2015, because they're way more powerful than they appear at first. They're basically strings, but instead of quotes, they use backticks. And they can span multiple lines. And you can also embed JavaScript expressions inside of them, which is great for building up strings from data. And this is where people usually stop with template literals. But interestingly and very powerfully, they can be tagged. And a tag is a special function that processes the template literal, both the literal and the expression parts. And it can return whatever it wants. It doesn't have to return a string. So this is interesting. Template literals are actually designed to allow domain-specific languages to be embedded in JavaScript. And HTML is a domain-specific language. So you can see how these features together let you write something that at least syntactically looks like the HTML templates that we're already familiar with. So this seems like a promising direction to explore, especially because of our move to JavaScript modules that we announced yesterday. Polymer templates inside of modules are just strings. And when we worked with this a little bit, we wanted something a little bit better. And we really wanted to be able to take advantage of the fact that when we're writing templates in JavaScript, we can be right in the JavaScript scope that holds the values that we want to put into the templates in the first place. And we also wanted to take advantage of the fact that we could use real JavaScript expressions, which are going to be as fast as possible. The key, though, was figuring out how to keep updates fast and make minimal updates to the DOM. And we're starting to see a number of other libraries now that use a similar approach, including libraries like HyperHTML, HyperX, Bell, and T7. And now I'd like to introduce you to the library that we're so excited about, which is called LitHTML. Now, LitHTML is still very, very experimental and underdevelopment. But we wanted to give you an idea of what templating in a module-only world might look like. So we call it Lit because, well, it uses literals. And it's very little. And we needed a name, and this name was cool. So what is LitHTML? LitHTML is a combination of JavaScript template literals, the HTML template element, and a render function that lets you efficiently render and re-render these templates to the DOM. Let's see what this looks like. So LitHTML templates are just JavaScript template literals. They contain embedded JavaScript expressions. And they're tagged with LitHTML's HTML tag. And then we have a render function which lets you render a template to some place in the document. Now, on the surface, this looks like it. We could just be building up an HTML string and using innerHTML to set it on the document. But that's not what's happening at all. If we were using innerHTML, we could just replace the expressions with their values, join them together into a string, use innerHTML, and then we have our template. But this would be very difficult to update because we've lost the locations of the expressions from our template. So instead, what LitHTML does is it replaces the expressions with these placeholders. And it creates a string out of that. And then it uses that to create your template. And after it's created the template, it goes through and it finds the placeholders again. And it remembers where they are. And we call these things, these places where these expressions are, parts. And then we remove the placeholders from the template. And now we have a template that we can use over and over again to create DOM. And because we remembered the locations of these dynamic parts, we can replace them with values after we've created that DOM. And because we have those locations, we can efficiently update them with new values when the values change. Now here, we're probably going to use templates mostly to create Shadow DOM for custom elements. So what would it look like to combine LitHTML with Polymer? Well, here's a Polymer 3.0 element in a pure JavaScript module. And we have an inline template here that's returned from a static method, the template method. If we convert this to Lit, you can see that it's very, very similar. Except for that instead of a static method, we have an instance method, because we want access to that instance-level state. And even though this doesn't appear very different, the developer experience is actually a lot better, because the expressions are real regular JavaScript. So now you get all the syntax highlighting, linting, formatting, type checking if you use TypeScript, all those features that you're used to from your tools because it's just JavaScript. It's also more powerful because it's just JavaScript. You can do arithmetic in expressions. You can call functions. You can build up templates from parts using if statements and for loops. And you don't have to hang everything that you want to access in expressions off the prototype anymore. You can just import it or declare it and use it. Next, I want to talk about the three main goals of Lit HTML. First, we want to make it efficient, because quickly rendering DOM is one of the primary tasks of a template system. Then we want to make it expressive, because you should be able to build very interesting templates or with your template system. And then finally, we want to make it extensible, because no template system can build in all the features that you're ever going to need. So first, let's talk about what makes Lit HTML efficient. So one of the things is template literals themselves. They have some really nice properties that we take advantage of. One is separating static and dynamic content. Let's look at why this is really important. So every HTML template system is responsible for creating a tree of DOM nodes. But only some of those nodes are ever updated after they're created. So templates have this structure. There's a separation between static and dynamic parts. And then you have the updates. Not every dynamic part changes at once. Sometimes you update just one value. And so when thinking about the cost of templating, it's useful to have these two questions in mind. How many nodes are updated? And what's the cost per node? And if we look at something like Polymer, we notice that Polymer has this association directly between the data and the nodes that depend on it. And so Polymer can scale its cost with a number of changes that you have. If you only change one thing, Polymer only has to do one thing to apply that change. And if you look at something like VDOM, it takes a very, very different approach. VDOM re-renders an entire virtual tree every time any of your data changes. So it actually scales with the total number of nodes that you have in a template. But they try to make up for this by driving the cost of each node down very, very low by using a virtual tree. Well, with lit HTML, we try to be somewhere in the middle and get the best of both worlds here. We're only going to update the dynamic parts of your template. So we don't update every node in the template. But we also try to drive that cost down very, very low so we can be as fast as possible. And this all falls out quite naturally from using template literals. Because with template literals, we know exactly what parts are dynamic and might change and what parts are static and will never change. And we don't even have to do any work to figure this out. The syntax of JavaScript just does it naturally for us. So besides separating static and dynamic sections, they also have this property where literals that are passed to a template tag are exactly the same for every call to that tag. This lets us do one-time setup work like the HTML template preparation I was talking about. Let's take a look at an example for that. So let's say you have a function that takes some data and then puts it into a template. So we're going to call this function. We're going to say hi to Amy. And this function is not going to return DOM. This function is going to return a template result. It contains the template that we want to render and the values that we want to render into that template. And then if we call this function again, now we're going to say hi to Alex, we get a new template result which contains the template we want to render and the values that we want to render into it. Well, it turns out that these template objects, they're not just the same, they're exactly identical. So we only have to create it one time the first time we ever see a template. From then on, every time you call this function, all we're doing is passing along the values that came with it. And that's very, very, very cheap. So another reason why template literals are great is because parsing strings in JavaScript is extremely fast. Parsing streams is somewhere between three and four times faster than parsing generic JavaScript expressions, which is what most HTML and NJS solutions use. So also, we're fast because we try to use the platform as much as possible. We use the built-in JavaScript and HTML parsers. We don't ship any parsing bits ourselves. And we use the template tag for fast, deep content cloning of our templates. This is the full minimized source code of HTML. I stole this slide from Jason Miller of Preact, where he did this one time showing Preact on a slide. And I wanted to show that we can put it all in here in 18-point font with room to spare. It's less than 1.7K minified. I was conservative when I put less than 2K up there. So it's quite small, and this helps us be fast, too, because it doesn't have to load much data over the network. So that's efficiency. Now, let's look at what makes it expressive. Let's take a look at what kinds of values you can hand off to lit. So you have simple string values. We can say, hello, summit. We also have expressions inside, or you can put expressions. Like, imagine you're showing a page number on a template.  And you have a zero-base index that represents your page number. You can just add one to that inside the expression. So things like this are extremely easy. You can also set attributes, obviously. Here, we're setting the value attribute of an input element. But you can do some more interesting things, like you can directly hand-lit HTML DOM nodes. So you might have some complicated structure that you want to create, and it's easier to do that imperatively by hand. Once you do that, you could just hand the result off to lit, and lit will put it in the right place on the template. You don't have to worry about using query selector or some other method of finding that dynamic spot that you want to manage. We also support nested templates. So you can build up templates by parts, and you can share these parts around with different templates. Here, we're injecting a header into a container template. And because we support nested templates, you can build up templates dynamically with logic. So here, we're going to show a different message to the users based on whether they're logged in or not. We support arrays. So if you hand an array to lit, it will just render every item in the array.  So now, you can take an array of data, map it over a template, and you get an array of templates, you hand it to lit, and lit will efficiently render that to the DOM. There's some other interesting value types we handle like promises. So let's say you do a fetch of some content over the network. You can just hand that promise to lit. And when that promise resolves, lit will render the result in your template. You don't have to do anything there for it. So if you put all this together, you can see that we can create some really complex and expressive templates. You can take a string and split it by new lines and generate a paragraph element for every paragraph in the string. You can dynamically choose what kind of templates you want to render based on the data. And then at the end, you can put this together in a more declarative form because we support that too. So we try to give you the spectrum of doing things very dynamically and imperatively to being able to do things declaratively and very structured. All right, finally, let's look at extensibility. There's two ways that you can extend the HTML. One is with directives. So a directive is a function that lets you customize how a value is handled by the HTML. So I told you about promises where you could give it a promise. And when it resolves, lit would render that content. Well, a lot of times you want to render some default content, a placeholder that renders until that promise is ready. And so that's what this until directive does. You give it both a promise and a placeholder. It renders the placeholder. Then it renders the promise when it's ready. And I wanted to show you how easy this is to implement. So this is the entire implementation of the until directive. And a directive is basically a function that gets a part. And a part has an API, setValue is the method it has. And so you can just call setValue. Here we call setValue with the default content. And then you can call setValue again when the promise resolves. And that's your entire directive right there. So it's very easy to extend and customize. Thanks. Another directive that we bundle is a repeat directive. This is very similar to DOM repeat and Polymer. This lets you do efficient lists where you can reorder the items in the list. So if you change the order of the list and then give it back to lit, it can track what data went to what DOM node and then just rearrange the DOM nodes without having to re-render your entire list. OK, another way to customize lit is by using custom parts. Custom parts let you change how values are handled across an entire template. And we've bundled a couple of these together in a library we called lit extended, which gives you Polymer style sugar on top of text nodes and attributes. You get property bindings by default, and we have declarative event handlers. So for property bindings, let's say you have a custom element and it has some property where it's expecting some rich data to be bound into it. You can just go ahead and with lit extended use the normal bindings syntax and you get a property binding. But notice something here. Notice that capital P up there. It turns out that because we're storing the attribute names in JavaScript, we can go back and get the case preserving names of the attributes there. So now we don't have to do this kebab case to camel case mapping anymore. We can just use the real property names. And that should eliminate a lot of errors that people accidentally get into sometimes. We can also fall back to attributes if we need to by using the dollar sign suffix just like Polymer. And we support declarative event handlers. This looks like Polymer because we have the on-dash prefix, but it's a little bit different because we actually take a function value into the binding expression. And so you can write inline handlers like this, or you can just reference a method on your custom element. OK, and that's what makes it extensible. And that's basically all of lit HTML. The next question is where to now? Like Matt said, this is currently a bit of an experiment. So we have a lot of testing and optimization and benchmarks to do to make it real. But from what we've already done, we know that lit is very fast and that it works great on the modern browsers. And then we want to write a mix in for Polymer so that you can use this together with your Polymer base classes. And then finally, we want to add tooling support so you can get syntax highlighting, code completion, hover over documentation, all the features that we give you in our Polymer IDE plugins. So if you want to follow along, there's a GitHub repository. It's in Polymer Labs, lit.html. And you can already install this from MPM. I'm going to push a new version this afternoon, and you can just MPM install lit.html. And if you follow me on Twitter, I'll be talking about this as I develop it. All right, thank you very much. Thank you, Justin. So we've been doing this quite a while, and I wanted to have someone who was there from the very, very beginning come out and talk about what we've been doing all along. He happens to be another really old friend of mine. He can be a little scary on Twitter, but he's not quite as scary in the office, but still a little scary. Please welcome to the stage Alex Russell. Thanks. Thanks, Matt. I didn't hope to scare anyone today. I, Matt, made me promise not to turn this into a half an hour of telling you why your websites are too slow. So I'm going to try to refrain myself. I am a software engineer on the blank side of the Chrome team, which is to say the engine bit, and I help lead our standards efforts on Chrome. But once upon a time, I also helped start the team that built the project that ended up as web components and ES6 and a bunch of other improvements to DOM and to JavaScript. We put together kind of a dream team, I think, that set out to solve problems that seemed really urgent to us back in the day. And that problem was why were the web apps that we were making so blow and slow did? Blow did and slow, that. We were looking at this from the perspective of Google's own apps, Gmail, Sheets, Slides, Docs, all the rest. And after a couple of years, after we'd released Chrome and a year after we'd released Chrome Frame, what we saw was that the front ends that we were making still weren't using the new stuff that we'd finally enabled through Chrome and, hopefully, an IE through Chrome Frame. We had this huge, high query per second system that did nothing but generate rounded corner gifs. I don't know if you used to make rounded corners like this, but this was like one of the highest QPS systems that we had in a bunch of our backends, because there was this nine grid system that made a table. So every time you wanted a rounded corner to get it to work on IE6 and IE7 and IE8, to all the browsers that mattered, you would put in some JavaScript that would generate a table and all the elements that go along with it and then make an image request and then put that around the outside. And then you get the idea, right? It was super inefficient. And that really bugged me. And it bugged some of the other folks on the team. We used to have a lot of code hanging around like this. In fact, this is still, if you go to the Closure Open Source repository, don't read this, it's a bit of an eye-try. But what you get in the comment there is a sense for the DOM that's generated to give you a rounded top and top left-right or left-right for your element. And that actually didn't do real rounded corners. That didn't even use the GIF hack. This is just sort of faking it with one pixel offsets. This is how we used to make rounded corners. So perhaps you were lucky to start doing web development after that era. But what we were seeing at Google was that teams that were starting fresh in 2010 still carried around this kind of legacy baggage. Either their frameworks were baking the sort of thing in by default, and they just used it off the shelf. Or they had these assumptions about which browsers they had to support, which may not have been questioned in a while. And so they always seemed to bring along this least common denominator approach. Even when most of the users came from modern browsers, they still used these slow paths. To this day, Closure has components like this. This is not at me, obviously. We're kind of performance is sassed at Google, and this doesn't seem great. But we didn't really have hard data about what we were really losing to this sort of inefficiency. How much was this actually costing us? So I did a little project to find out. I stole a couple of weeks from my 80% project. I kind of just didn't answer any email, I go to any meetings, or really. I may not have been on the planet as far as anyone was concerned. Basically slept under my desk and just started hacking up Gmail. I got the servers running. That took half a week. Don't ask. And my goal with this project was just to remove as many elements from Gmail's DOM as possible. Now I wanted to make sure the app was pixel for pixel the same, keystroke for keystroke the same, that it worked exactly the way that it did, but see what you could do if in 2010 you started fresh. Like what would it take to iterate to use some of the more modern stuff? So there's a lot of stuff in Gmail. This is a screenshot of a recent Gmail. And a lot of things in the engine are linear in the number of elements. Some of the things are linear or super linear in the number of nodes above you in the tree, the depth of the tree. So fewer nodes, the theory goes, and shallower hierarchies would be faster. So looking at where the elements were going, it seemed that modern platform features could help remove some of the inefficiency, rounded corners, for instance, getting rid of a bunch of the extra elements for layout. But that was all conjecture. Turns out it's really difficult to measure the contributions of small elements in large systems. After about a week and a half of sleepless hacking, my prototype got to a 40% reduction in the total number of elements in the Gmail DOM. That 904 today used to be a lot larger. I was using CSS rounded corners instead of nine grid tables and GIFs. I was using Flexbox instead of a custom dual pass layout system written in JavaScript. We were dropping hugely nested layouts in favor of things that were much more modern. And in general opting for the thing that you do if you could start over circa 2010. So did it work? And testing locally on a fast machine, my development workstation, which was a 16 core i7 workstation class box, was super inconclusive. It was kind of a bummer. I'd spent a couple of weeks on this. And I'd really hoped to find that something was going to be a lot faster about this. I had thought intuitively knowing something about how the engine worked and something about how websites worked, that this would turn into a faster experience. But for the life of me, I couldn't find a way to say that it was faster. The changes made the toy template soy templates a little bit smaller. But try as I might, I couldn't detect any large performance winds on that really fast device. But that didn't keep my friend Emil, Eklend, from the Gmail team from productionizing portions of my prototype patches. Those changes wound up dropping the total size of the Gmail DOM by something like 30%. Given the ambiguous data we'd seen locally, both in local testing and in the population control groups at Google, we didn't really have high hopes for anything other than some code cleanups. We thought that this might lead to a nicer way to work on Gmail. But we didn't think that it was actually going to be a big performance improvement. Boy, were we wrong. With the reduced element count version in the wild, it turned out that this was a huge impact on real world latency. Many users saw their Gmail inboxes load half a second faster. To put that in context, this was the single largest latency win in Gmail in years. And there was an entire team staffed to doing nothing but reducing Gmail latency. None of us had any idea that this was going to work this well, even the folks who decided to productionize it like Emil. We'd gotten lucky. We'd gotten super lucky with this. But what lesson do you learn from that? That's a fascinating question. We started to ask ourselves, what should we do next as a result of figuring out that we could make things faster this way? One possible lesson might be that making JavaScript faster leaves a lot of money on the table from the platform perspective in terms of cross-cutting optimizations that you can make inside of your applications. We'd proved that lesson to ourselves quite a few times since in the wake of the blink fork back in 2013 when we started to remove a lot of the ON squared algorithms that were sitting around inside of the layout code, for instance. Another possible lesson that we could learn is that moving common stuff from user space into system space, into the platform itself, let us reduce not just the cost of development time or reduce our complexity for developing a particular feature, but it also potentially let us radically improve the user experience, too. It turns out that this only works if we can get developers to use those features, though. Compelling new features don't need a lot of help here. Developers eventually tend to realize that building and sending their own versions of a standardized feature down the wire is really expensive. This is a little like the way that in the US, state laws preempt city laws or federal laws, national laws preempt state laws. When the bigger, slower-moving entity finally acts, it doesn't just add up to an umbrella to keep you out of the rain, it changes the weather entirely.  We see this a lot in the platform in other areas, too. Query select role, promises, you get the idea. So with that in mind, we started writing design documents about how we might upgrade the web platform. In time, this turned into a pitch deck for a project that we jokingly called parkour. This is a slide from that internal pitch deck. The naming of course was very tongue-in-cheek. If you looked at us, we were the least likely set of humans to actually try real parkour or put the other way, the most likely set of humans to be grievously injured by trying it. So what did we do? Well, every couple of weeks, we sequestered ourselves every Thursday. We cleared our schedules and for most of the day on Thursday, we would meet in a conference room, this crazy U-shaped conference room that used to be the building, used to be owned by the gap, the clothing manufacturer. And so it was sort of this wood panel, like grandiose thing where you expected a marketing pitch deck for the next line of jeans to be presented breathlessly. But we filled it with nerds and we just debated. Sort of halfway between San Francisco and Mountain View near the airport, we just spent our Thursdays digging in, trying to figure out what was in there. What did we need to add? We spent so many hours in that room, arguing, prototyping, researching, arguing, prototyping, lots of arguing. And we recruited from the ends of the earth. This is the Sydney team. And they eventually wound up owning a large portion of Blink's style engine. They still do. As a fun aside, some of these folks were just coming off of the Wave project. A lot of our initial design documents were written in Wave, when some lose some, I guess. And we made sure to have experts from nearly every aspect of the platform in the room. Folks like Annie and Eric on the right there knew basically everything there is to know about how to do web development in that era. And folks like Tab on the left and Chris Burroughs were language and standards experts. And together we could figure out solutions that work not just in practice, but also in theory. Kind of valuable when you need to actually go write it down as a standard sometime in the future. We pulled in designers and toolkit engineers and folks from all over the company to help us hone our understanding and try to understand aspects of problems that weren't clear yet. Both the problems themselves, but also the ambiguous design space around how we might potentially solve them. And did I mention the whiteboards? We had a lot of whiteboards. We spent a lot of time at whiteboards. So many whiteboards. All the whiteboards. And when it wasn't whiteboards, it was video conferencing from all over the world. At one point we had folks pitching in from Sydney, Tokyo, San Francisco, Mountain View, Seattle, London, Munich, and St. Petersburg all at the same time. We didn't sleep a lot. It was sort of shocking how many designs we worked through in the space of a couple of years. It was exhausting. It was an incredible amount of work and discovery and prototyping. Turns out that inventing new platforms is relatively easy. Iterating on existing ones compatibly is much, much harder. One of the most fruitful veins of exploration for us was digging into the then popular JavaScript frameworks to try to understand how they worked, what was in there, what was common between them. Members of our ad hoc team had built JavaScript frameworks that were at the time powering some of the largest products from Google, IBM, and Sun. Remember Sun? And we took it upon ourselves to learn the ones we didn't know already. We looked beyond the JavaScript tools too, not just jQuery, Clojure, Dojo, and YUI, but we looked at Flex and XAML and Zool and XBL and Java FX and pretty much anything else we could get our hands on. What we discovered were striking similarities but wildly different levels of platform support. There was a huge difference between some of these environments in terms of batteries included versus bring your own. The web it turned out was very much in the bring your own camp. We tried to boil a lot of what we learned down into these documents, these endless documents that sort of cataloged the ways that people were trying to plaster over what the platform did or level it up through common idioms and interfaces. Just to give you a sense, this was what we did, please don't read this. This is one of the investigations we did just to try to compare and contrast the event systems. This is copied directly out of a document I wrote. And it gives you a flavor for some of this research. We wanted to know what toolkits and frameworks needed to provide because the platform wasn't either nice enough to use or expressive enough to get the job done. And we tried to identify areas that were common. Something that really jumped out at us was how much infrastructure each library was bringing around to support creating widgets or components. This is jQuery UI's idea of something like a menu. Behind that dollar-dot widget is a huge world of infrastructure being created to support stamping out instances of this thing. Here's something very similar from Clojure, the JavaScript library that traditionally had powered almost all of Google's largest front-end products. That goog.inherits line at the bottom shows that this class really is trying to be a widget. It's trying to inherit from a control class. This is the dojo version. It's very similar, that declare method at the top. That's the thing that does all the magic. It sets up functions. It wires up the prototypes. It mixes in all the interfaces. It does all that stuff for you. But under the covers, it's the same thing. There's a function. It's got its prototype wired up. It's a class, basically, that you can instantiate and it creates some DOM from a template and manages its internals in a componentized way. jQuery's approach hung all those custom details and tried to stuff them inside of the element itself, whereas almost all the other libraries that we investigated did the opposite. They created a parallel tree of components which happened to have elements hanging off of them. Dojo, Clojure, YUI created this parallel hierarchy that just wrapped the DOM. Here's YUI's version, for instance. It basically takes the same approach as Dojo and Clojure. Studying the landscape for a while, it became clear that what everyone was really trying to do was to create a logical hierarchy of components that didn't have all the implementation gunk in the way. Frameworks are spending tons of time and bytes on the wire to make this possible. A major challenge for companies as big as Google was that even when these tools were open source, they were also incompatible. You couldn't take a YUI widget and use it inside of a Clojure application without pulling in the entire library that came with it. There was a huge sunk cost to importing any other thing into your system. You couldn't compose Clojure widgets into GWT. As Google, that sucked. A lot of us were ex-framework authors and at some point in the distant past, we'd all basically had this question at the top of our minds. Why in the heck can't we subclass HTML element? But when you're working on a framework, this isn't really a meaningful question. You can't do anything about it. It's not actionable. Browsers are browsers, them's the brakes. You just take what you're given and you move on. But now we worked on the browser. What if we could fix it? What if we could make subclassing HTML element possible? It seemed like we'd be able to finally build portable components. And if we were able to define our widgets in terms of HTML, let them integrate exactly into the DOM, we might be able to finally end some of this war between all the different frameworks that we had built or that we had discovered and studied. So to validate our assumptions, we started building prototypes. We built entire applications and we threw away all the libraries that we had used before. We got rid of them and we built as little infrastructure as we needed to use tip of tree, WebKit and V8 circa mid 2010 to see what was still missing. If we could use the tip of what the web platform had, was it all just sitting there and we didn't know it? We just hadn't used our CSS rounded corners in this case? It was fascinating to see what fell away and which parts we had to rebuild. To define menus in our apps, we still needed to contort the word function to mean class in some cases and do some nasty underbar, underbar, proto wiring to convince Chrome that our instances were actually elements that you could call methods on them. It kind of worked. It was definitely less messy than the other way but it still didn't let you say what you meant. We built entire apps including a cross between an RSS reader and Google Maps. You could see the current news if you zoomed in and search for things all across history but if you zoomed out and scrolled down, we backfilled with Wikipedia data. It was pretty cool but I can't get a screenshot of it because I tried to get it working and unfortunately we built it on the RSS APIs from Reader.  Can we do that? Just a moment of silence for Reader? All right, I'm still sad. As we built these apps, we took note of every single time that we had to build a little bit of library to support ourselves. It turned out that this was a great to-do list for things that we might go and add to the platform and over the next few years we attacked those gaps and I'm proud to say that we were relatively ambitious. We were not shy. Between 2010 and 2012, we developed an attempt to advance work in HTML and DOM, JavaScript and CSS. We'd seen what happened to other efforts which tried to solve all known problems in web development using a single tool. For example, undounded extensions to the input element or dozens of one-off CSS properties because when all you have is one hammer, everything looks like a nail. So we took out some wrenches. We got some saws. We built an entire workbench. We decided that we would try to target our improvements at the places in the platform where they made the most sense and so we built a team that was broad enough to let us start to attack each of the problems where they lay, not necessarily where we could most easily turn the wrench. By taking a broad view, we were able to target minimal interventions in many areas of the system, which each of which I hope are valuable, but together kind of add up to Voltron. Web components aren't one addition.  Peter Hall in the chat on the right here helped us design classes, traits and modules, async and await syntax, for instance, and prototype it all in the first JavaScript next to JavaScript now compiler called Tracer. Taking them to T-39 turned out to be pretty slow going though, but eventually we got a lot of the things that we really needed to make this better few for possible done through standards. Working through its standards is sort of the grinding terror of business travel combined with the high stakes whiteboarding. It's just as much fun as it sounds. We persisted though and occasionally we even won a few. Incidentally, this is Dimitri Glaskov, my engineering partner in crime and all of this and now the uber tech lead for all of the Blink project. When I originally posted this photo to Flickr back in 2011, I initially captured it, he's never going to live this down. So I feel like adding it to this presentation is just sort of keeping a promise to myself. Anyhow, it wasn't all smooth sailing. After we opened up the design process and started making public proposals in 2011, we got a lot of mixed signals from other browser vendors. The standards process isn't necessarily something that you can gain. We need to actually forge agreement, but most of what we got was in difference. Browser engineers tend not to viscerally feel the problems that we feel as web developers. The grounding explorations that we were doing to understand the state of the art and where the problems lay were actually not the norm. Most browser engine projects don't do this. A lot of people were surprised to hear that browser engineers don't understand web development very well, but having worked on both sides of this line, it makes sense to me. It's not like you beat the boss at the end of the web development level and suddenly get handed a chromium checkout, an MSDN subscription, and a copy of Effective C++. Web development and web engine development are separate skills, and we hire separately for them. The problems we're trying to solve in 2010 and 2011 were partially about speed, but also about expressivity. The problems that we front in community today is trying to solve are very much have the same flavor, except that many of us now are so up to our necks in frameworks and CLIs and tools that we can't really even see how changing something in our apps would actually affect that eventual outcome for our users, especially in the context of the existential threat that we face in terms of mobile performance. Back in 2011, when we put a slide like this up, developers understood that this code didn't feel right. It was div, div, div, div, div, div, div. It was not saying what you meant. So the expressivity argument tended to work, but the performance argument has kind of always fallen flat. Desktop computers were getting faster, Wi-Fi was everywhere. Was this really a problem that we needed to solve? A problem we needed to solve right now? We tried to sketch out a simpler future, one where you didn't have to have heavyweight frameworks and build steps to enable the edit refresh cycle that we had grown up on, the one that we were so addicted to, and really enjoy. All this code came from a snippet in the slide deck we put together nearly seven years ago. And what we thought it showed was the value of being able to say what you mean. Class, split pane, extends, HTML, div element. We built ES, next to ESNow compilers, to prototype all this and try to feel it for ourselves and see if it actually worked out pretty well. And very much to counter to today's ethos in a lot of the JavaScript ecosystem, we built all of this with the hope that we would be able to invest it all into the platform directly, and then we would be able to evaporate those tools away. We built them with a sell-by date. Tracer was meant to go away. Transpilers were meant to be an ephemeral feature, not something that lives forever in the platform. And we didn't get it all, but this code works today.  But this code works in Chrome and Safari and Opera and Samsung Internet today and without any tools and soon in every other browser because the standards process allows us to forge consensus that's broader than just one platform, just one browser, just one runtime. So we started all this in the desktop era, right? And now when we have web components, you've been hearing about them for at least one day, going on too, but we're not in the desktop era anymore. So, having finally solved all these problems, does it matter? For context, 2G connections still make up almost half of mobile internet connections. If you saw this stat in one of our slides last year, it was nearly 60%, so that's on the decline, which is good. But if you're trying to enter emerging markets, 2G is how your median next user is going to feel your experience. The situation is changing rapidly in emerging markets. Reliance Geo, for instances, is having a massive impact in India this year, but the global reality for the next billion users is that 3G is how people experience your apps and sites. For those users, the experience isn't just about the network. It's also about the hardware that they have in their hands. I promised Matt that I wouldn't make this a performance rant, but we really do need to understand these devices if we're going to deliver the sorts of UI that we want to the users that we want to have experienced them. Okay, quick digression. More cores is not faster. More cores is not faster. There's probably no better trade-off in mobile CPU design today than to take all of the extra cores that are actually most of the time spun down and turn them into caches for the cores that are spun up. If anyone from Qualcomm or MediaTek or Samsung are listening or see this video later, just know that we see you. Endless marketing of more cores is better has run its course. The king is actually kind of naked. We need devices that have good thermals, which many of them don't. This is the Nexus 5, of course. The CPUs are super slow for lots of reasons, and it's not just the terrible thermals. I could go on and on and on and on about the 28-nanometer process that coincided with the switch to 64-bit and how the electron-voltage leakage caused everyone to not be able to scale their CPUs up, but I'm not going to do that. What I will say, though, is that most of the web development community has a really long way to go in appreciating how far from good the current practice really is. A user waiting on a huge pile of JavaScript to arrive and execute just to see content or to start using it, to start tapping on it, doesn't give a wit about whether or not your developer experience was very good. Who were we doing this work for? It's a question worth answering. Kevin Salk yesterday emphasized webpagetest.org slash easy and time to interactive, and I think that's absolutely the way forward. Accurate network simulation plus real hardware gets you actually pretty close to ground truth of the experiences that we're building today and shipping to users over unreliable networks. Perhaps the most important thing for us to understand collectively, though, is that when hardware gets cheaper, it has a different effect here than it does in an emerging market. For wealthy users, more transistors every year, Moore's Law, right? Every 18 months, double the transistor count. Here, that turns into basically constant dollar spend or euro spend. If I spend the same number of euros next year on a phone, it's a faster phone. In an emerging market, where most people in the world or in those countries don't have devices, that turns into a broader market for a cheaper version of what you already have. That is to say, we don't trade transistors per dollar for faster phones in emerging markets. We trade it for a larger market for the same speed of phone. That creates a larger set of users carrying devices that we might charitably think of as mid-tier back in 2015. And we should expect that trend to continue for a couple of years, which sounds pretty bad. So for example, this is the Samsung Galaxy On 5. You probably have never held one of these. It's just about $100 US or 90 euro, more or less. It's a gig and a half of RAM and about eight gigs of storage. It's pretty popular these days in India. It's, I think, the third most popular phone in Flipkart. The CPU on this device is quad-core, but if you've seen my other talks or heard me rant just earlier, what you'll know is that more cores doesn't actually mean a lot. What's interesting to me about this device, though, is that it runs the latest Chrome. The hardware might be stuck in 2015, but the platform doesn't have to be. So house low was $100 phone. Well, here are some Geekbench 3 scores for Android's ecosystem system on chip packages. The offline Nexus 5 that used the Snapdragon 808, it's down sort of toward the bottom of this, as you can see. So where's that Galaxy on 5? You kind of got to scroll a while. Oh, yeah, there it is. But you know what I'm not bummed out about? Is that our thesis from 2010 was right. We can use the platform evolution to preempt heavyweight user space apps and frameworks and get some of this back. We can dispense with tools that only work for the wealthy users. And thanks to the platform evolution, we can level the playing field for everyone. You all know about the Shop App by now. It's a beautifully executed example of what's possible with Polymer. But what's interesting to me about it is it demonstrates how this progress plays out and how we can cope with the next few years of evolution in the marketplace as we're waiting for phones to actually get faster. We don't have to drown anything in JavaScript. Here's Shop using Polymer 1.7 and I dug it out from an old checkout. It loads something like 340K of resources total. When served, well, it can be super snappy. It can get to time to interactive on a Moto G4 on a 3G network in something like five seconds, which is, I think, the gold standard front first load. But here's the unbundled version using Polymer 2 and ES6. It's exactly the same functionality, but it's 60K smaller. What changed? Well, it's able to use the custom elements one APIs and we're able to serve just the things that this browser can support. For users on slow connections and flaky networks, this is huge. Shop was fast already, but every kilobyte we lean on the platform for instead of sending down the wire really pays us back and it pays us back in terms of reach over the next few years. Polymer is converting on the promise of we believed in back when we started the parkour project, but in a context that we just didn't see coming. Web components, it turned out, were the answer to a problem we didn't know to ask. When Darren and Alex and Matt and the rest of us all bet on this effort back in 2010 and 2011, ES6 and web components were sort of something we just were gonna figure out, something that we kind of knew were gonna be important, but we didn't understand why. But we got lucky again. When we started ripping elements out of Gmail, we didn't know that it was gonna make anything faster. Turned out it did. When we started upgrading the platform, we knew it would make it nicer to use, but we didn't know how much faster it could make things. But now we know. We're in a special moment right now. Smartphones are opening up computing to people who've never had access to them before. And the web, I believe, can be the single best way to deliver experiences to those users if we don't drown it in JavaScript.  That's great news for us as developers, but it's mostly great news for our users if we use the platform. Thanks for having me and thanks for making your sites fast and small. Thank you, Alex. All right, so we're ready for our morning break. I just have a couple of quick announcements. So there will be food and refreshments across the way. Just a reminder, there's the Ask Polymer Lounge where you can get your questions answered that is staffed right now, and we'll be back here at 11.30. So one quick announcement, we're gonna be doing a panel later on. This is everyone's favorite chance to put us on the spot. Give extra hard questions this year because I'm not gonna be on it or moderating it. In order to put a question on, we'll have microphones here, but also if you have any questions you think of in the meantime, tweet them at hashtag Ask Polymer. That way it doesn't get confused with the other summit stuff. So as you can tell, we're big into use the platform. A lot of times that gets misconstrued online. If you really wanna know what it means to us on the Polymer team, if you go to polymerproject.org slash about, we've got a nice article there about it and what it means to us. To find out what the platform, what the web platform means and how it's made, please welcome to the stage, Mariko. Hi, so, hi, Mariko. This is my Twitter handle and GitHub and pretty much everybody on the internet. I am from web developer relations at Google, but it's leading new job for me. I joined about five months ago. I was a web developer before that, so it's kind of like a new field for me right now. So the events like this are great. Not only I get to meet you all who use the platform, but also I get to meet the team behind the people who's building and a lot of people who works on the Coleman stuff. So, you know, I go to people and then ask, like, hi, I'm Mariko. I'm new here. I recently joined. What do you do? And then I get the reply, like, I'm on the platform team and, you know, okay, cool. And then I go to my email and then I get invite, like, what platform meeting. Cool, I'm gonna go to that platform meeting. And then in that meeting, the conversation goes like this, like, well, so, like, X, some framework, use web technology, but not on the platform or, like, from a platform point of view, blah, blah, blah. And then also there's a whole hashtag, use a platform, which, you know, I'm sure you've seen it, like, yeah, banners. So platform, platform, platform, platform, platform. So, like, do you know those souvenirs that you get at the tourist destination where it has all the city names and, like, tote bags and everything? So if I were to design a swag for my five months of experience at the Google, this will be the textile design. Um, so, web platform, right? To me, this keyword is kind of like a sort of, like, a programming technology that I use, like, you know, one of those things that I kind of know what it is and, like, copy and paste it and use it. But as soon as somebody challenges you, like, so explain to me, I don't know, JavaScript promise, I can, I'm going, like, I use it, I can't really explain what it is. But platform me, to me, is like that. So I tried to find that example of, like, me kind of pretending that I know. So this was from March. Somebody asked me, like, I don't really understand what the Node.js is in, like, the relation to V8. So I looked at the diagram and the diagram itself is not important. But then, like, zoom in. I used the web platform, even though I had no idea what the platform was. I just, like, titled it, web platform. So it got me thinking, like, I don't really understand what web platform is, and I'm not the kind of person, kind of like a toddler who asks everything and questions everything in the universe, like, I must know everything. So I got to people, engineers on the team who works on the platform and asked them, like, tell me what exactly is web platform. One thing I got was, like, things you built, like, websites and apps out of language of the web. And I'm like, okay, it's like, I don't know, building blocks, Lego, I don't know. Another one I got was a set of interoperably implemented technologies available to developers across the web browsers. And I'm like, that's great, I have no idea what you mean. So platform, right? And then I got kind of like, I must understand this and me dive into it. The thing is, in my past life, before becoming a developer even, I worked on the platform. I was in the software platform industry and I would go into client and tell them about, like, you should join a platform, build a product on a platform. I was on the company that make the video platform. And then I go back to office and talk to engineers and product managers and other stakeholders about, like, what should be in a platform, what kind of API should we expose and most importantly, how are we gonna make money from selling this platform? Because in 2008 and nine, like, SARS, the software as a service, was like a one thing, one wave, and then, like, platform as a service was a thing to do. So I know what platform is in software sense, but when I started web development, nobody called me or emailed me saying, like, you should use web platform or nobody charged me money to use, to start writing HTML, right? I just started, like, and opened up the text editor, read the talk, FTP to the server, and then, voila, there was a website. So what is the web platform? Because even, I don't even remember who told me or when I was told, but there was this, like, general understanding that web is open. It's the open web platform. So I was like, okay, that's a keyword I can Google. There is a definition on the W3C Wiki, which is the open web platform is the collection of open, loyalty-free technologies which enables the web. So let's dive into this sentence and what it means. So first of all, open, loyalty-free. Almost everything, anything I feel like, that goes into web platform is done and logged in open. And what I really mean is open, that you can find a conversation as far back as 91, logged on the internet, about discussion about what the worldwide web should be. My favorite part of this log is the first email in this log is titled, Test Again from Tim Berners-Lee, inventor of the internet. And then he says, like, Test Again, clearly he sent these messages before because it's a gain. And then, like, if you got this, delete it, sorry. But this is the one that did not get deleted and now it's logged forever. Well, joking aside, if you go through those thread, there's, like, really interesting history and artifacts of how web was formed. So this thread, I think, is particularly interesting. It's a Mark Andreessen who was at the time working on the Mosaic Blizer proposing the image tag. And it goes, like, I'd like to propose a new optional HTML tag, IMG. The acquired argument is SRC equal URL. And if you read through this thread, there is a conversation about, do we even need to embed an image in HTML? Should we just have a link to some of the external resources and not even display the image? Can we use other tags that we were considering instead of IMG?  And it ends with Mark Andreessen going, like, yeah, that solution doesn't need to work for us. I don't think that works for us. By the way, we already wrote the code and we are shipping it. So that's the open part. The discussion is done in open. Nobody is trying to say, like, whoa, my HTML are going to have embeddable image, and I'm going to charge money for it. No, like, the ideas and technologies and how the API should be is discussed in open. Another part is that it is a collection of technologies that enables the web. We looked at the image tag, for example, but it's not only just defining the HTML tags. So what kind of technologies do we have on the web platform? Well, the web is evolving ecosystem. So one example is the pointer event. So we used to browse websites with keyboard and mouse, but then now we browse on those devices and we use our fingers and two fingers. So we needed a way to address those interaction in the web, and we added a pointer event. Another one, the web used to be just a document that we shared across the internet, but now we make applications. And which internet application needs to get access to a local file system, maybe, so that you can upload an image and make something like Instagram. So a file leader API was added. This is the API that is near and dear to my heart. This is the API I use for the first application I wrote on my job, not the side as a hobby, but the first application I wrote on the job. I use this file leader API because I had two weeks of off time. I wasn't a web developer yet, but I was on the business side, and I had a week, two weeks of off time that client wasn't sending me assets. I was like, well, I learned JavaScript recently, and I know how to console log, and I know how to HTML. I'm going to try to make this like a little tool that's going to help me do this analytics thing. And what I used was file leader to load all of the data, the attributes that I needed to automate my job. So when I did this, my company did not buy me license. I did not ask for money to start making the thing. I just opened up my text editor and did it, and that's great. So collection of technologies which enables the web. And this definition is a lot close to the description of the platform I got from the engineer, a set of technologies for the web. But that's only half of what he described as the web platform. There's a whole other set here, which is interoperably implemented across web browsers. So I went back to the same engineer who said this and asked him, like, so how does browser interoperably implement things? And his answer was, well, we used to just copy each other's bugs, but now we write spec for standards. And that's the way we make platform. And Alex, the speaker before this, kind of talked about how that came about. So you got that thing. But every web API and the platform features that we use that as a web developer, we might encounter it on MDN or any tutorials that we publish. Behind that is thing called specification documents. And it looks like this. And if you go in, here's the custom elements section where it defines the element. It goes in detail what to look for, when to look for, what to check for error, and what kind of error to throw error when. It goes in step-by-step detail also how this API and how this feature should work. And you might have ended up this in page when you were trying to search for some tutorials, and then you might look it away, because I did. I certainly remember this design of a blue bar, side bar thing, but I don't ever remember just getting any information that I can use on a web development job to finish this PR from this document. I was just like, ah, that's not for me. I'm just going to look away. While I was just having this conversation, another colleague of mine asked me interesting questions. So he walks on standards I thought at Google. He asked me, so I have a question. Why don't you just contribute to standards? And my answer was, that's an interesting question. I have never thought that's possible, because somehow I think the standards are like a mystical creature called W3C and ECMA standard gives me this golden document that we can use. And I've never thought that there was somebody or some human close to me writing these things. So I told him that I just never considered as things that I can do. And he was like, oh, that's interesting feedback. Glad to know, because we never thought that was what you thought that way. And he told me, by the way, here's the way to contribute to the spec. And it turns out it's a lot closer to how we make web application and how we do software development. So let's look at how we work on spec. So let's say, for example, if you want to edit or add something to the existing spec, what does it take? Here's a HTML spec that is defined by WG. And here's a link to the document that is kind of like I felt like that's not for me. But all of those are hosted on GitHub. And there is an issue tracker that has all of the thing that needs to get updated. It even has a label for good first bug. And it's interesting that this spec is an English text. When they say mean bug, it means fix this English text. So if you look at the PR that is made against this HTML repo, you find things like this. Like explicitly mention possible values for image smoothing quality. So this was from one of the good first bug. It just means that somebody noticed that in the spec text is a little ambiguous. When they say the values image quality, it didn't say what kind of quality is possible. So this edit just adds three more words to what kind of image quality needs to be added. And now, the person who made this PR is contributor to the HTML. Much like we write tests for software, web platform and spec has a test called a web platform test. And if you dig into this repo, you can find how each of the web platform features should behave. And you can lead through what each of them should do. And I'm kind of the person who sometimes when you don't really understand bug, you lead the test and then see like, OK, this is what it's supposed to do. And here's what I need to fix. I really enjoy looking at web platform tests and knowing how things should work. But what if you have a new idea? What if you're working for a company or working on a project that is completely out of what we consider as a web right now and you need something standardized? How do we go about that? I'm going to show the example of how to do it on W3C. But many of the standards follow the same steps. There is a thing called web platform incubator community group, YCZ at W3C. And if you read the announcement, which happened, it's a little bit recent thing, like an announcement from 2015. It specifically says, we will develop spec use cases document like we develop any open source software. So how do we do that? YCZ have discussed. And then there's a value of things and features and discussions are happening there. So let's say you have an idea, a new API that you want to bring. You create a new thread. Here's one from Sarma, who is speaking later today, and makes a proposal. Usually, those thread comes with a little bit of explainer. So in the GitHub, there's explainer like one markdown file says, here's a problem we have and here's a potential solution that we want to solve with this new API. If you read these threads, the threads go into people asking like, well, what do you mean by that? Can you clarify your question? Is it really a valid problem? Or any other things like, can't you just solve this with this other thing that already exists in the web platform? And those discussion happens. Once the mature discussion happens and community agrees that this is actually a problem that we need to solve and this cannot be solved by existing technology, we should make a new thing, then it moves on to the next step. So if you are curious about those specs and explainer docs, YCZ, WebIncurator Community Group has a GitHub org and you can browse through all of the LEPOS with all of the explaining things. It's kind of a good place to know what kind of new things like WebUSB are considered for web platform. Once that discussion matures, they do think of intent to migrate, which means that we identify the problem, community agrees that we should work on it, and we want to formalize the process. And it moves on to what is called Working Group. Working Group is kind of like a subset in the W3C that works on specific features and discuss. And it brings a lot of stakeholders together to discuss how can we actually make interoperable technology. So CSS has Working Group, Service Worker have Working Group, and Working Group usually have GitHub. And you might think, well, we already had the GitHub, what's the difference? Well, the LEPO is now under W3C org and there is a whole bunch of process to move the spec in order to be official spec or recommended spec. So there is a document that feels like a gazillion pages of the process. If you're interested, you can scroll through and you can find things like, OK, if you have a spec, it goes from walking draft, WD, to CR, to PR, to recommendations, and you can lead a whole through that. But once you identify the problem, then identify or agree that we should actually work on it, then there is a whole other set of process to bring more stakeholders together and make sure that the specs are done. So if you're curious, if you're browsing MDN, you can see what kind of specification this platform feature belongs to and what steps in those spec process that is in. And it's in the table for the MDN and it's kind of fun to look at. So as Sam writes, I talked about W3C case, but generally other standards bodies follow the same thing. Somebody has an idea and that somebody start the conversation about, hey, I have this problem. I want to solve this. What do you think? And people say, I also think that's a problem. And if somebody, that conversation happens one and two and many cycles, and then if they agree that, yeah, we should actually invest the time and bring the stakeholders together, it moves to a little more organized steps, and then they do another more set of discussion around it. And then once that's done, then it's verified and now everybody's happy and go party. So I asked the same engineer who told me about the web platform, how many web platform standards or how many standards goes into making a web browser? And his answer was all of them. There is a lot of standards bodies specifies many bits of parts of the platform. So W3C has CSS, a lot of web API. What WG defines DOM and HTML. ECMA is specifically ECMA Technical Committee 39 is the one who's defined the JavaScript. Unicode, most importantly to me, defines emojis. And you can propose new emojis to Unicode. There is a process for that. And IETF has things like HTTP. So before going into this, I felt like this person to person, somebody who is definitely not me working on spec, was a process for spec writing. But after this, I came out that, well, it actually many parts of standardizing a web platform and defining the what platform should do, it's something that I, it looks like something that I do day to day. It looks a lot like software development. But I warn you, it takes time. And sometimes it's a little frustrating. I'm sure we were at a Polymer summit and we get frustrating, ah, is the spec ready? Is it like already recommended? Like why is it moving so slow? And there is a reason for that. Web platform is platform built on many different environments. Since joining Google, I got opportunity to attend one of those standards meetings. And I witnessed interesting conversation. So there was a conversation about internationalization API. And one browser was saying that, well, our browser is built on top of specific architecture, specific OS that does not use this internationalization library, which other browser uses. Two other browsers share the same library. So their point was that, well, you too might think this is easy to implement because it's in your library. But it doesn't work for architecture. It doesn't work for OS. And it's really hard for us to implement. And those discussions, making sure that it is interoperable, takes time. Another one is that web is really unique ecosystem. You have to support HTML from 20 years ago. And you have to think about supporting HTML from 100 years from now. You know, we can't just say, like, oh, excuse me, sorry. In order to use Polymer 3, you need to install web 2017. That's not how it works. It has to work backwards, comparatively. And then it also has to work in future. So a little story time, when they were considering those backwards-compatible and future proofing, what kind of conversation happens at the standards? So 2014, one of the engineer who was sitting next to me, I think so, Rob's talk from a Google I.O. And he was really excited and told me that you need to write this thing called Polymer and use web component. This is the new and Chinese thing. You should do it. And I was like, OK, great. I can write my own HTML tag. I want my HTML to look like this. I was in business, so I was thinking about data dashboard. And this looks pretty. I can define my elements and make my thing. Well, my first prototype didn't work, because I didn't hyphenate the tag's name. And that's one of the spec. And so Polymer doesn't work that way. I have to make it my dashboard and bar chart and hyphenate the name. And I was like, oh, like why? I had this specific markup in mind that I want to write. I was kind of frustrated that Polymer didn't let me do it. And at the time, I was like, Polymer didn't let me do it. I didn't know anything about web platform. So that was my frustration. Two weeks ago, I was in the conversation with the engineer who was in the meeting when they decided that the custom elements should be hyphenated. It was just an enlightening experience to me. So when they were discussing, OK, let's have this thing called custom elements. And developers defined their own tag, basically. How should the syntax be? And this engineer who was at the meeting told me that they were like, OK, well, we need to define the way that doesn't conflict with existing HTML and HTML tag that might come in future. So we need to namespace it. Well, what about namespacing it with colon? Turns out XML use this syntax, and SVG use XML syntax. So let's no go, because it conflicts with what, SVG? So colon, no. Another one was, what if we just prefix it everything? So x dash custom element or something.  So they were like, oh, we really don't want to do that. So at the end, they ended with just simply hyphenating the word custom element. And everybody's happy, and that's how we code now. But this is so much more than just having a neat looking markup. When the specification decided that this is going to be, a custom element is going to be hyphenated, that means that they decided in future, when they were to be considered new HTML native element, then they will not use a hyphenated name. It will always be known hyphenated name, because the future HTML element, if they have a hyphen, then it conflicts with custom element. So that is kind of scary things to discuss.  And you have to take care of what would happen in the future. So it takes time. So hopefully, you kind of got the idea of what the platform is and what kind of discussion that goes into. And I admit, as a web developer myself, sometimes it's frustrating. I'm like, why is this doesn't work this way?  Why? But I hope you got the idea that where you should go, if you have those frustration, there is a community discussion forum that you can send to many of the engineers who are at this, engineers and people who work on the standards at this conference are more than happy to talk about why certain things that you're unhappy about happen that way. And I specifically want to thank the people who answer to my most London and Andrews question about, I don't understand the platform. I don't understand what the web platform is. So thank you very much. And thank you very much for Polymer Team for letting me share what I discovered. And thank you very much for listening to me. I think between Alex's pictures from a long time ago and the fact that I was in that meeting about the hyphens, I'm feeling kind of old today. So when we were putting together the schedule for this summit, one of the things we really wanted to do is make sure that we had a lot more members of the community that were speaking themselves. That's why we did an open call for topics. And we didn't just want people from the Polymer community. We wanted people from other frameworks and other libraries that are using web components now as they get more and more popular. So today I'm very excited to announce the next speakers, which are Max and Adam from Ionic. Thank you. So today we're going to be talking about Ionic moving to web components. We're super excited to be here, especially kind of a late edition. So if you don't know what Ionic is, we'll talk about that first. But before we do that, a little quick intro about ourselves. I am Max Lynch. I'm the co-founder and CEO of Ionic. I'm also one of the co-creators of Ionic Framework, the open source project. And I'm Adam Bradley, lead developer of Ionic and also a co-creator of Ionic. So really quickly, if you're not familiar with Ionic, Ionic is basically a cross-platform UI component kit. Initially kind of focused on building native style apps for the app store. So people used to call this, they still do call it sometimes, like Bootstrap for mobile. And if it's helpful to think about it like that, that's really what it is. It's open source, MIT licensed cross-platform UI kit. So you can build iOS and Android apps. That's really kind of our bread and butter. You can build universal Windows platform apps. But increasingly, people are building progressive web apps, responsive web apps and electron apps all with the same code base. So the right once run anywhere thing that's always been kind of elusive and people still laugh at, a lot of our developers are actually doing that today because it's just based on the web and the web runs pretty much everywhere. So we're 100% based on web technology, HTML5, JavaScript, CSS. And if you're used to building mobile apps, one thing people really like about a web approach is it's just really easy to customize. CSS and HTML is one of the easiest things to style. And so we're proud that we're based 100% on web technology. Ionic's one of the top of the source projects on GitHub and we've had millions of apps created. Some you might use like Dow Jones MarketWatch and Untapped, which is a social network for people who like to drink beer. And then one thing we're seeing a lot more of that I'm really, really excited about, these big enterprise companies are starting to build a lot of apps internally and Ionic is powering a lot of these. So we're really, really excited about that. They're starting to do their own mobile development and it's really great. Finally, it's a real business behind Ionic. We build services and tools for app development. If you wanna learn more about that, check us out at ionicframework.com. So real quick, we wanna go over a brief history of kind of how we got here today and why Ionic and the decisions that we made, why it is the way it is. So this was our original goal. Goes way back to when we first started that we really kind of wanted to focus on letting developers focus on building their applications and not so much the details. So in this case, we want to be able to enable developers to just add a toggle. Not worry about how does a toggle work, how to add gestures, what happens when it gets all the way to 50 pixels to the right or left. Rather, we just want the developer to worry about I wanna add a toggle there because I'm focused on my own app. So if you look back, we started this in 2013 and Alex had a great talk earlier kind of talking about the details of how difficult this was to do. And I will freely admit that in 2013, I had never heard of a thing called Web Component. But what we were at was we were largely using jQuery. And jQuery kind of was great, but it also had required a lot of kind of manual setup and things like that. And Alex's talk did a really great job of showing that. So it really wasn't the ideal solution. So then we came across Angular and Angular Directives. And personally, I was blown away by it kind of was exactly what we were looking for. So with Angular Directives, we were able to make components and provide a large UI library to all of our users so that they could have this cool UI library, pick and choose which components I wanna use and build large applications with it. But again, meeting our first goal of letting developers build large applications. And so we fell in love with AngularJS from the start. But then also, if you look at our very first commits, we had a bindings directory. And in that bindings directory, we had AngularJS, Backbone, Amber, and jQuery. And a few others were in there. So we were kind of naive and kind of ambitious to think that, well, we'll just make a binding for all of them because it's gotta be that easy, right? Within a week, we quickly realized that's not gonna happen. So we decided to stick with AngularJS, but it was kind of eye-opening for us of like how difficult it is to build components for just one framework, let alone many of them. And even if you were to fast forward today, you would have had to build even another 50 more components or 50 more things through the frameworks. So fast forward to today, I still love Angular. I'm personally a huge fan of it. I have nothing but the utmost respect for the core team and what they've brought to the web development community. But the reality is, is that Angular is not the only awesome framework right now. And then we've moved from which is the best framework, conversation to now, which framework do you prefer? Because they're all actually in reality, they're all great. So it kind of comes down to the team that's using or the developer of their choice of which framework they wanna use. So I think you can see where I'm going with this is that as web components emerged, as we realized it's actually a viable solution, we started a question and it's like, maybe this is trying to meet our original goal of maybe of what we wanted to do of kind of writing one component and having it work everywhere. So this is what we're here to talk about today. So that was kind of our journey to discovering web components and actually considering them a viable option. But at the same time, around this time, progressive web apps really emerged on the scene. And considering Ionic's goal was really right once from anywhere, kind of a UI framework for building apps on all platforms, it was obvious that we were gonna jump right in and embrace progressive web apps. And our early experiments were actually really, really disheartening for our team. We initially were, and still to this day, like we've focused on Cordova apps in the app store. And on a Cordova app, all your code is bundled next to your app in the same local domain. So there's no network latency, there's no 3G to worry about. And when we took that approach of building with a framework like Angular and bundling all our components together, we were seeing really, really bad results when it came to going to progressive web apps. We're talking like 73 scores on Lighthouse, on 3G emerging market tests, 13 seconds time to interactive. It's just not even usable. And we were shipping like over a megabyte of code for the first view. And the worst part about this, that Alex has mentioned a lot and it's totally true, we couldn't solve it. We hit an engineering wall. Our current approach of bundling all these components up and then trying to pull them apart and do code splitting once everything was already bundled together was just not working. We spent a lot of time, we spent a lot of effort and frankly spent a lot of money trying to figure it out and we couldn't. And so we kind of took a step back and at the same time, we had bet the farm on Angular and what had happened in the front end space is that frameworks really proliferated. Angular had a lot of usage, but so did React and so did View and so did Ember. You know, I'm sure if you asked individual developers of these frameworks, they would pretend like it's the only game in town, but if you look at the data, it's not at all true. And so Ionic was looking at this fragmentation happening and saying, well, we're having issues with framework performance in general, but if we want to support these other frameworks, now we have to go and build bindings for each individual framework. It just wasn't really gonna happen and so we felt like we were kind of stuck. But then we started experimenting with web components. We started taking our Angular components and pulling them out and porting them to vanilla web components and it was actually really, really promising and it actually ported over really well from Angular too and I give the Angular API a lot of credit for kind of being similar to web components. And our first results were really, really encouraging. Our 3G time to interactives were four to six times faster, 2.78 seconds compared to 11 and 13 seconds before. We were shipping 10 times less code, especially for the first view. We're talking 39 kilobytes compared to 422. Like that's a really big difference and that was a highly optimized Angular Ionic 2 app. And then we had a build step because we used TypeScript and it was considerably faster. We're talking like 3.87 seconds for production builds compared to 50 seconds. So not only was it faster loading components but the developer experience was better. But we still felt like something was missing from these vanilla web components. We really, really love traditional frameworks and we think they've given developers some really great tools. Things like reactive data binding, virtual DOM, support and kind of embrace of TypeScript and also some key innovations that we saw like React Fiber where the approach for performance was moving from, how quickly can I synchronously render 10,000 items to how can I help the browser not lock up its UI thread and do less work. And we felt like those were key innovations that web components really needed to stay competitive. And finally, we wanted to use JSX. We're excited about some of the template literal stuff as well. And we knew that server side rendering pre-compilation had to work out of the box. So we took our great promising results from going to vanilla web components with the desire to bring these framework features that we really, really loved and missed and decided to see if we could combine them together. And so today we're really, really excited to announce a new project that we've been working on that's really an artifact from our own efforts that helps developers build faster web components with framework features that they desire but in a 100% standards compliant way. So today we're announcing a new project. We're calling Stencil. And Stencil is a compiler for web components that Adam will talk about in a bit. It's still super alpha, but we are using it for a lot of stuff internally. So we created it for ourselves. We're using it for ourselves. It's gonna power the next version of Ionic. So we're really excited about it, but keep in mind it's still alpha and we'll have links at the end. And this is really Adam's brainchild, so I should let him talk about it. Thanks, Mac. So Stencil is largely a compiler for web components. And so what it builds is optimized custom elements. So the big thing I wanna get across is that this is not yet another framework. It's not a Stencil framework.  Rather, it's using the build time compiler to build just vanilla custom elements that work in all browsers. And that was key that we really wanted to focus on. And so with that compiler, we're also able to enable virtual DOM, server-side rendering, precompilation, asynchronous rendering, and reactive data binding. And it's absolutely been inspired by the best parts of Angular React View and Polymer. And again, as Max was saying, it's based on TypeScript because honestly, we use TypeScript because it's made us really productive in building applications and building Ionic itself. So we use TypeScript because we enjoy it. The side effect is that everyone else gets the typed library that we have, but the real reason is because we prefer it. And we also use JSX along with that also. And I'd also like to add that is MIT licensed. So with our goal of creating just vanilla custom elements, we really want to make sure that we had no external dependencies of any library to include Stencil. Stencil is not a framework, but rather it's just the compiler for it. And so by reducing or removing every single external dependency and having just a vanilla custom element, we're able to then work in all frameworks, which is kind of our original goal. So if we go back to what we originally wanted to do in 2013, was just make it easy for developers to build applications. Fast forward to today, there's many ways to do it in many different frameworks. So we feel like this is kind of meeting our original goal and we're really proud of that. And on top of that, Stencil can be used to create just standalone components or it could be used to create entire applications. And it's been working great with all framework, with one caveat that we've had issues with React and that React hasn't been working the best with web components. So that's an area that we would love to work with the React community and improving upon moving forward. So the way I like to think about Stencil is that it's kind of a pre, it pre-bakes custom elements, pre-compiles, whatever. It takes a lot of these concepts that we've really expected and have gotten to like about frameworks like virtual DOM, lazy loading, change detection, all that stuff. And there's a simple compiler that just takes those concepts and builds custom elements with some of that stuff baked in. So we call it Stencil because it's just a tool to help you stamp out these components. It gets out of the way at runtime. All right, so demo time. So we talked a lot about asynchronous rendering, JSX and all that above. So we kind of wanted to show off something here. So a few months ago at a React conference, they had an amazing demo where they showed this. This is React version 15. And what's going on here is that there's the single node at the very top that's being updated with a new number every single second. And then that passes all the information down to all these child elements and so on and so forth. And then every single frame, each one of those circles is being animated out. And every single one of these circles has a mouse over and mouse out event on it. As you can see, this is React 15 is no joke, but this is very difficult app to pull off because you've got over 700 nodes being updated every single second. So what's happening here is why you see it kind of jank a little bit is because the browser is kind of freezing, trying to get sure that all those 700 nodes are updated. So this is why it's kind of janking like that. And so if you've heard, React Fiber is kind of solving this problem. So React Fiber is the next version of React. It's in beta right now. And we read all about it and we were really intrigued by how they're solving this where instead of trying to synchronously update every single node, it lets it kind of put into a synchronous queue, which then lets the browser kind of manage that. So we were curious, or that sounds awesome, React. I wonder if we can do that because frankly, we also have asynchronous rendering. Can we do that with Stencil? And so we're really thrilled to show, like we were blown away by the first refresh to see that actually this thing is pretty darn smooth. It's updating just as many elements. It's the same thing. All the properties are being passed down. And so it's kind of proving that this tiny little web component that we have here, which is just vanilla, not dependent on anything else, is just as performant as React 15 in the next version or React 16 in the next version. So we're really proud of kind of the performance that we've gotten from this. So back to the slides. So yeah, so that's a quick kind of demo from the performance with the asynchronous rendering engine. But we've kind of talked a lot and haven't really gotten any code, which is the best part, right? So I want to talk through kind of what a simple Stencil component looks like. And the cool thing about Stencil is this is pretty much the entire API. It's very small. It doesn't have a lot of surface area to the API. If you know ES6, if you know TypeScript, it's pretty easy to understand. So this is an example of a Stencil component. It's a simple ES6 TypeScript class. We are using decorators to indicate that this is a component. We specify the tag name, and then we can also link a style sheet. So we support SAS or vanilla CSS out of the box. Inside the actual class itself, you'll notice this at prop decorator. And what this does is basically indicate that this class member is going to be filled in from a property on the actual component. So someone above this component would actually write name equals blah or age equals blah. We have typing information, so we kind of know what the type is going to be. Stencil is based on TypeScript and we do use this type information to our benefit. And then inside the render function, you've noticed this a few times today. This is kind of where we feel things are moving. We compute the next view basically using JSX, but in theory we could use template literals or anything in here. And we're taking the value of this.name and this.age. The cool thing here is if name or age changes, the component knows how to redraw itself automatically. There's also another thing instead of prop, there's state for internal state. It's a very explicit way to indicate that this member variable is going to change. And if it changes, we need to redraw ourselves. So this is what a component is. And underneath the hood, we generate a simple custom element using this code. So there's really not a lot of surface area. If you know this little API, you know how to use Stencil. So and also because everything is broken apart and asynchronous, one thing we wanted to make sure we pulled off from the very beginning is that all of the components are lazy loaded. So a challenge that we've had with our existing versions of Ionic is that if you wanted to use a checkbox, you needed to use everything. And that works well in Cordova world, but moving forward, it's really not working well in PWA. So we wanted to make sure that if you only use toggle, it was going to be the only stuff you downloaded. So out of the box, we made sure that we enabled this, but also wanted meter goal of not having external dependencies. So Webpack was our challenge to say, like, could we do this without Webpack because that kind of seems to the standard right now. And sure enough, the way we're doing it is that we're able to just register just kind of the base information about a component. So we tell the browser, like, hey, these are all the components that are possible, but that's really about it. We don't go further into detail or we don't have any more code than saying, like, Ion toggle is a thing, Ion checkbox is a thing. And then, hey, browser, if you happen to see that, let me know. And that's about all that we register up front. And so then from there, what we're kind of doing is we're reversing how traditional lazy loading works, where traditionally, a developer on the computer will run the build step and we take these best guesses of which things should be bundled together and which pages should be bundled together and which stuff do we think the user is going to request. And then we ship that as one big final package. But with this, we're letting the browser decide exactly what it needs. We don't even get involved. We just say, hey, browser, let me know when this thing happens and when you need Ion checkbox, then we'll send it to you at that time. And so then users are only downloading what they need. And another awesome benefit of this is because we have a compiler, we can hash all the file names of these files. And so with that, we can then forever cash all of these files. So on your phone and CDNs and edge networks, all of these files can be cached. So if you have the slightest update to your app, let's say you had a misspelling and you want to update the app, you don't need to rebuild the entire application and reship it to all your millions of users for them to download the large bundle anymore. Now you can just say, I had this one file update. Let's update that file. And users are only updating the change file and everything else is still static on their phone or as fast as it can possibly be. So we're really proud of this being able to enable this with kind of how we're using a compiler to pull that off. And on top of that, we want to make sure that all of this stuff was easy to share. So with large organizations and any company really, or any organization, it's often a challenge of which different teams have different frameworks. So different developers use different frameworks. And so this has been talked a lot during this conference. And so we want to make sure that it's just as possible for people to put together a collection of their components that they can then easily share with all the teams in their company. And we want to do this also through MPM, which is awesome to hear that Polymer is doing the same thing too. But another challenge that we've had has been with sharing our SVGs of like our IANA cons. So IANA cons is a project of ours where we have over 900 SVG icons which people can choose from. Again, that has the problem of like, well I don't want to download 900 icons for this work. So we were able to solve that with kind of the same concepts here. But at the same time, it's easy for a developer to build this and have their 900 icons in their application. But as a UI library that wants to share these 900 files, it becomes a challenge. Because now it's in node modules, which needs to get copied to the correct folder in your application. And then at the same time, it needs to get requested from the same location from the browser. So there's kind of two steps here. That's always been a challenge that we've had a lot of work grounds. But with Stents, we make sure that this was seamless, where you just import or you just require which are you require the collection of IANA cons? And it's all handled for you, so you don't have to worry about that. And additionally, we're also able to group certain components together because in reality, there are certain components that will come together. For example, we have Ion Card. Ion Card has Ion Header and Ion Content inside of it. So chances are, if you use Ion Card, you're gonna use those other two also. So we wanna make sure that we can reduce as many requests as possible or separate requests as possible so we're able to easily bundle them together. And again, the biggest thing I wanna get across from this is that the final output is not a stencil thing. It is purely vanilla custom elements. And Ionic Core is really just another collection. So again, it can be reused in any framework to include Ionic Angler. So, and that's another thing I wanna make sure that I get across is that the next versions of Ionic Angler will continue to work the exact same. Everything you're using about Ionic Angler is just like how version three works, except now under the hood, we're using this to pull it off. And then we have the added benefits as the developers that we can then enable it for react developers and review developers and so on, and whatever comes out next month. Additionally, we wanna make sure that server-side rendering was enabled. Traditionally, that's been kind of difficult to do with web components, but we, because we're using our own asynchronous rendering engine, we're actually somewhat easily able to add this to our components. So what that means is your first paint can be just HTML and CSS so that perception is lightning fast and as fast as it could possibly be because you're only rendering the bare minimum of what that first paint has to be. But then on top of that, another thing that keeps coming up is TTI, Time to Interactive. That was our core focus to make sure that the actual time to interactive was really just as fast as possible could be. So what we're doing is making sure that all of the existing nodes that came back in that first request for that first paint are the same ones that we just enhanced with listeners. So we're not repainting the whole thing like you see in other frameworks. And also just like how we wanna make sure that you develop on desktop and you develop on mobile, you kind of have a single experience of what you're creating. We feel it's the same thing of like if you're developing for client side, a browser, or you're developing on the server. So we wanna make sure that the experience of developing stenza components is the same whether you're doing server side rendering, pre-rendering, or it's for the browser. So to do that, we're able to have window and document and everything that you're used to so you don't have to kind of change your mind or do a mind shift between the different versions. So just some FAQs here. Who is stencil for? Well, first and foremost, it's for us. We built it because we needed faster apps. Like we mentioned, we wanted to be and we do wanna be a major UI framework and solution for progressive web apps. And frankly, we're kind of dead in the water without coming up with a different approach. So we need faster apps with components that run in all frameworks because we can't possibly support all the frameworks out there with our components and the ones that will come out in the future. Secondly, it's meant for UI framework authors. I strongly believe that the days of building a CSS jQuery framework, like let's say a Bootstrap or even like an Ionic that has its own CSS and then trying to build custom bindings for every framework. I feel like those days are coming to an end. I think it's a really positive thing for both UI framework authors because they can do less work, but also users. I think we've all used a Bootstrap binding that had one set of features for one framework and had different features for another. And so web components kind of solve that problem for us and Stencil can help these developers build these components. For large development teams that are using a lot of different frameworks and build chains, using Stencil and using web components, they can share components like your team has a branded button or a specific thing that has to be in every single app. Instead of duplicating that every time, you can just share the components with everyone. And then finally for app developers, we all want faster mobile and desktop apps, right? So this can help us get it. So how is this different from current solutions? I think the biggest difference is that it's a compiler, not a runtime solution. So we do all the work during the build step. It's just a simple NPM install. There's no CLI, it's just a NPM script for your app and this just generates a set of optimized custom elements. So there's nothing Stencil in the final output. We keep saying that, but I just want to really like drive it home. There's no window.Stencil. It doesn't exist. It's just your components. And this complements all frameworks because we really like don't want to discourage anyone from using React or Vue if you like it. That's great. We kind of have taken a step back and saying, we don't really care what you want to use anymore. We're done fighting that battle. We're just going to create custom elements. You can use them if you want. But if you want to explore this brave new world where you don't use a traditional framework, you just use web components, we support that too. And we're actually really, really excited about that. Hashtag use the platform. And it's a small footprint. There's very little Vue code here. There's no CLI. And then finally, this is going back to kind of preferences. We built this on TypeScript. TypeScript has let us get a lot of rich typing metadata that we actually use for the tool. But as a company, we've really embraced TypeScript. We feel like enterprise usage is really, really accelerating on TypeScript. So we base it on TypeScript. We love it, but if you don't, then maybe this is a point of disagreement. So what's next with Stencil? Our Stencil-created components are going to go live in hundreds of thousands, hopefully, of Ionic apps. Who knows, this might be the biggest distribution of web components in the app stores in short order. So we're really excited about that. We're going to begin seeking some feedback on an experimental Ionic with Stencil starter instead of just Ionic with Angular or a typical framework. And based on the feedback, we might integrate that more deeply into our tooling. This is still experimental. We're not really sure how people will like it. We need better state management. I'll have something like Redux. So we're working on something like that, trying to make it easy to import third-party modules, looking at maybe template, literal templates like lit.html beyond JSX. Because we're just a compiler, it's pretty easy to swap that out, but we've just decided to go with JSX today. And then we're going to submit our HNPWA, which we're really excited about. Yeah, so we're really, you know, again, this is something we built for ourselves, but we're really proud to show this off and get some feedback of what you guys would think or what the community thinks. And so we have it up on our GitHub and we have a couple of demos out there that include the Fiber demo and the Hack News demo. So I've labelled enough, we've labelled enough about this, but one thing I want to say is take a look for yourself. So take a look at this Hack News app and do the traces yourself, look at the file sizes, look at how fast the time you're inactive is, and just take a look and you'll see that it rivals the best PWAs out there right now. And so we're really, really proud of it. And on top of that, it's built from a component of libraries.  This is an actual, legitimate, large-scale application that has modals and alerts, popovers, all the different things that you want in application, but it also loads just as fast as any other of the fastest PWAs right now. So please, we encourage you to take a look and we're really proud of what we have so far. Thank you very much. Thank you. So some of you may have noticed it took us a little while this summer to get the schedule out for this. One of the last pieces on the last day we were trying to get it up. We were like, you know, we asked the Ionic guys if they wanted to do a presentation at Polymer Summit and they got really excited about it and Dion had sent them an email and we were asking for the abstract and bios and all that so we can put it up. And finally, Dion sent an introduction email with us and them and we were talking to them and they kept tweeting about it that they were very, very excited but then we weren't hearing back about bios and the abstract. So finally we put together on the very last day we had had the email, Dion had the email wrong so the entire time we weren't actually communicating and apparently ionic.com is some other thing and they weren't even replying to us. So luckily we got all that figured out at the very last second. So it's lunchtime, just a few announcements just like yesterday, Halal and Kosher meals are available at the station over there. If you can't find them, ask a staff member. There's a code lab starting in 15 minutes. It's a really cool one. It's purple with Firebase and custom elements with Keanu in the code lab area and we'll be back here at 1.30 or 13.30 if you're not a silly American like me. See you in a little bit. Let's see. Our next set of talks are gonna be shedding some light on some mysterious black box stuff. Much like Shortender's cat in the box we're gonna reveal the true state of things. Speaking of which, anyone know what Shortender's favorite input type is? Checkbox. Okay, so our next speaker is also my manager so if you give him a big round of applause I can use that in my performance review. Gray Norton. Thank you, Brendan, that was excellent. Welcome everybody. My name is Gray Norton. I'm an engineering manager on the Polymer team and today I'm here to kick off an hour worth of content on server side rendering or SSR for short. I'll get the ball rolling with a brief introduction and then Sam Lee and Trey Shugart will follow me with a couple of different approaches to server side rendering web components. Sound good? All right, let's dive in. So over the next 10 minutes we'll ask and answer a series of key questions about SSR. The first one being why are we even talking about server side rendering here at the Polymer Summit? In short, because you guys asked us to. SSR is a hot topic in web dev and frankly we've seen there's quite a bit of confusion about what exactly SSR is, why it's important, and how it relates to web components specifically. So our goal is to answer that call for information, clear up some of the confusion and let you know about some recent developments specifically related to web components. To start, let's establish what we even mean by SSR. So for the moment I'd like to define it very broadly. We're gonna say that you're doing SSR if your web server ever delivers meaningful, renderable, route specific HTML to browsers or other user agents. So for example, given a URL like this, if your server sends something like this to a browser or a bot, then you're doing SSR. On the other hand, if you only ever send an empty HTML shell more like this then that's not SSR. So this may seem overly broad but stick with me, we'll get more specific soon. With that definition in mind, the next question is why would you want to use SSR? Turns out there are two major reasons. Now if you've been building apps for production or paying attention to public conversation on the topic, you probably know these, but let's quickly spell them out. The single biggest reason is to maximize your reach. To have any kind of impact to your app of course needs to have users. And the best way to reach users today are search and link sharing, both of which rely on non-browser user agents called bots. Search bots crawl the web and populate search indexes while link bots visit URLs and produce appealing visual snippets to encourage sharing. Sadly, many of these bots don't run your client-side code. If you don't serve them any meaningful HTML, your site might as well be invisible. Okay, I need to pause here for a second before we move on to reason number two. Because I'd just like us to recognize how messed up it is that here in the year 2017, we're depending on services to help us find and share information that basically see the web like their browsers from 1997. Now for anyone who embraces the idea of the web as a dynamic and capable platform, and I'm guessing there are probably a few of you in the room, I think this is an existential issue. So let's fix it, all right?  So the second reason you might use SSR is to maximize loading performance. Now we all know that performance is a critical component of user experience, and in the mobile era, loading is almost certainly the most important aspect of performance. The performance-based argument for SSR is pretty simple. Serving renderable HTML is generally the fastest way to get something on screen since the browser can paint right away before loading, parsing, or executing any of your JavaScript. Makes sense, right? So now we've reviewed the two key benefits of SSR, but I'd like to look critically at each one. First, do you really need SSR for search and sharing? Honestly, this is a question you need to answer for yourself based on the nature of your site and your business. But that answer feels a bit like a cop-out, so we're just gonna say, most likely, yes. Let's note the exception first, though. If you don't rely heavily on sharing, and if you're satisfied with the reach that Google Search gives you, you may not need SSR. That's because Googlebot uses a rendering service based on Chrome, and therefore sees your site very much like your users do. There is a caveat. Googlebot's version of Chrome isn't entirely up-to-date, and it has a few features disabled, so its rendering may differ from your users in subtle or sometimes not-so-subtle ways. The details are out of scope for this talk, but I encourage you to check out these resources on developer.google.com for more information. In general, though, you'll be happy to know that Googlebot runs your client-side code, fetches your data, and renders your app very much like a real browser. The problem is that Googlebot is not at all typical. As we've already mentioned, many bots don't attempt to run your code at all, and many that do do so in very limited ways. So if you care about non-Google search engines, or you depend on link sharing for much of your traffic, you'll probably want to use some form of SSR. We'll see how you might do that in a minute, but first let's ask the same question about performance that we just did