 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 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. So 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. It didn't end 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 ES 6 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 were 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 into 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 LIT HTML. Now, LIT HTML 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 LIT HTML? LIT HTML 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 LIT HTML templates are just JavaScript template literals. They contain embedded JavaScript expressions. And they're tagged with LIT HTML's HTML tag. And then we have a render function which lets you render a template to someplace in the document. Now, on the surface, this looks like 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 LIT HTML 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 templates, 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 HTML 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 and 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 and 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 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 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 we 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 in 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. 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. You can put expressions like, imagine you're showing a page number on a template. And your users are probably not computer scientists. So they're expecting a one base index. 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 in 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. And this becomes extremely powerful when you combine arrays with nested templates. 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 this 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 lit.html. One is with directives. So a directive is a function that lets you customize how a value is handled by lit.html. So I told you about promises, where you could give it a promise. And when it resolved, 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. 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 binding 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 the 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 at some 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.