 Hello. My name is Justin Finiani, and I work on the Polymer team here at Chrome. And I'm going to talk about HTML templating and give you an early look at a new library and approach to client-side templating that we're very, very excited about on the Polymer team. First, I want to talk a little bit about why templates are so important. Templates are absolutely critical for today's web. Just about every single site that you visit or build uses some form of a template system. Whether you're building a pure content site that might use server-side templates or rich dynamic applications that are rendered completely client-side, one of the primary jobs of your code is building the user interface. And on the web, our user interfaces are built with HTML, a declarative document format. And because so much of what we're doing is taking data and transforming it and displaying it, this HTML is usually generated from data. It's not completely static. Some of it is, like I covered here in green. And some parts are dynamic, like I have in pink. And merging and managing this static and dynamic content, it can lead to some really nasty code that's hard to maintain. Like our old friend, manual DOM manipulation, where we had to create elements individually, build them together into a tree, maybe hold on to some nodes that were going to be dynamically updated later on. And this is really difficult to maintain. And so templates can help save us from this fate. Templates let us express our intent in a declarative format that's much closer to the output. And they let us mix static and dynamic content via expressions. So this is easier to write, easier to read, and easier to get correct. So this is great, right? Templates solve all of our problems. Well, not quite, especially because writing a good template system is incredibly hard. Template systems have some very challenging requirements to meet. And they sometimes have to make very difficult trade-offs. So first, template systems have to deliver a great developer experience, because that's maybe their main reason for existing. So this includes things like how templates look. Developers really like templates to look like their output. Even JSX has shown the popularity of using markup for templates, because it brings markup directly into JavaScript. It also includes how templates are structured. Most developers seem to like their templates to be pretty declarative. But they can't be completely declarative sometimes, because often you do need to do some interesting logic to build up your user interface. It also includes how expressions and control flow work. Do your developers need to learn a new expression language? And it includes tools. Do you need a compiler? If the template has its own file type or syntax, is that widely supported across editors? So even just getting developer experience right is very, very difficult. But as important as developer experience is, it's not nearly enough. Templates have to be fast. They have to boot fast, because they're on the critical rendering path for your application. The expectation for great websites is really, really high these days. Study after study shows that sites lose real users and real money for every extra millisecond it takes to render. And if that's not enough, template systems also have to update fast. Single-page apps, especially really rich content creation apps, they need to respond to user input and data changes as quickly as possible. And this goal is often intentioned with booting fast, because one way to update fast is to do computation ahead of time to try to track what data is associated with what notes. In complex template systems that do that, they're often larger too, which can increase the page load time. And then finally, template systems end up being this bridge between the worlds of JavaScript and HTML, which can be challenging as well. So JavaScript is where your application logic, more importantly, your data lives. And HTML is what we need to build. It's the stuff that the template system manages. And it's the natural way in which a lot of developers think about their UI. So typically, if you write your templates in JavaScript on the JavaScript side, they either don't look a lot like your output, or maybe the code might be too imperative and hard to follow. And if you write them on the HTML side, you might not have direct access to your data. The template system has to pipe that in for you. Or you may lose or have to recreate many of the features of JavaScript, like expressions. So altogether, these are some really, really challenging requirements with a lot of tough choices in unexplored territory. So it's no wonder that there are a lot of many different opinions and approaches out there as framework and library authors explore all the possibilities and the limits here. And this is actually really great, because we get to try out a lot of different things and see what works best. And if you are building a new template system, this is a really, really great set of targets to aim for, which brings me to this new library that we're working on on the Polymer team called Lit HTML, which aims to do as well as possible on all these criteria. So for a little background, like Taylor mentioned, a few months ago, Polymer announced that we're moving away from HTML imports, where Polymer users typically write their templates. Two JavaScript modules, and this necessarily means that we're crossing this JavaScript HTML bridge over to the JavaScript side. But for backwards compatibility, we're doing the simplest thing possible with the templates. We're taking the templates that were written in HTML, and we're just moving them into a JavaScript string inside of your component definition. So this is really easy to migrate to, but it's a little bit less satisfying than we'd like. So we started to think about how to make something a little more satisfying, especially now that we're writing our templates inside of JavaScript. We want to be native inside of JavaScript. And that's how the experiment that became Lit HTML was born. So what is Lit HTML? Well, primarily, it's a library that lets you write HTML templates in JavaScript that both boot and update fast. And it's a very, very small library. And it has a simple, easy to use, but extensible API. So let's look at how we write HTML templates in JavaScript. So this here is a Lit HTML template. And we're using a feature of ES6 called Tag Template Literals, which, in my opinion, is one of the most unsung features of ES6. So this looks like a string, except for that we use backticks instead of quotes. And it can span multiple lines. And it can have JavaScript expressions embedded directly into it. Now, this is really useful for building strings from data. But in addition, another really powerful feature is that template strings, template literals, can be tagged. And a tag is a special function that processes the template literal and the values from expressions. And it can customize what's done with those values. And the tag goes right in front of the template literal, like a prefix. And it's interesting. It doesn't have to return a string. It can return any type of value that it wants. And Lit HTML takes advantage of this to enable really fast updates. OK, so here's our lit template. And the expression creates a JavaScript value. So to use it, we're going to have to do something with this value. Like maybe put it into a variable here. But first, I want to talk about exactly what type of value this is. So this looks like it might be a string. But I mentioned that strings would be not that useful, maybe. They're not that great for using with inner HTML. Because if you produce inner HTML, you're going to have to blow away all your DOM when you produce some new inner HTML for a component. So maybe they could return some DOM. But we have kind of the same problem there. We don't want to rebuild an entire DOM tree every time we render or blow away the DOM for our component. So instead, what we do is we return something called a template result. And a template result is an object that contains a reference to the template that we want to render and the data that we want to render it with. So it's the instructions for how to render some DOM, not the DOM itself. To actually render the template result, we pass it to HTML's render function, and then give it a DOM container to render to. And the first time, this is going to render the complete template. And then after that, it's just going to update what's already there. And I keep talking about updating, but this snippet doesn't really show how to do that. A more realistic and useful way to use the HTML is to write a function that takes some data and then returns a template result like this. So here, we've moved the tag template literal into a function that takes some data, passes that data to the template, and returns the result. And once we have that function, we can call it over and over with new data. And then we can render it efficiently to the same container. So for those of you familiar with React, you might notice some similarities here. And there are some as well as some major differences. So first, this definitely looks a little bit like JSX, but it's standard JavaScript syntax. And templates being JavaScript expressions and JavaScript values are going to lead to some of the same patterns that you commonly see in building up JSX templates. But under the hood, the systems are quite different. In particular, HTML doesn't have any VDOM or doesn't do any diffing. But besides the similarities and syntax, there's another similarity in philosophy I want to talk about. And that's the idea of building UIs a pure function of state. For any given state that your application or component is in, it should always render the same output, the same UI. And to build your UI, you write a collection of functions that transform state into a description of the UI, VDOM for React and template results for lid HTML. And then the library takes care of making the UI reflect that description. So this is one way in which they are very similar. OK, so now let's take a look at some examples of the things you can do with the HTML, starting with the types of values that you can pass into templates. So first is simple text content. Anything that you can turn into a string will just be rendered in place. And this works for attributes as well. And since we're using the full power of JavaScript in our templates, you can put JavaScript expressions in line with the template. So let's say you have a page index. And because we're computer scientists, that index is going to be zero base. But our users are probably not computer scientists. And they expect their pages to start at page 1, not page 0. So you can simply add a 1 in line with your expression here. And this is a great place to do that kind of template and display logic. You can also pass a template result to an expression in order to compose templates with nested templates. So here we have a header template that we can include into another template. And we can actually include this in many other templates as well. And then when HTML renders the containing template, it'll render both of them together in place. And because template results are values, we can compute them using the full power of JavaScript, like using a regular if statement here to display a different message based on whether a user is logged in or not. The HTML supports arrays and iterables. So if you pass an array of data, it'll render each item in that array in place. And this is really powerful when combined with nested templates. So we can use JavaScript's arrays map function here to transform a list of data into a list of templates. And then when it renders the containing template there, it'll render your UI with a list in it right in place. It also supports nodes as a data type that you can pass to a template. So sometimes the easiest or fastest way to create some DOM is actually by hand. Or maybe you're using a third-party library that builds some DOM and just gives you a reference to it. Well, your template library shouldn't get in the way here and HTML doesn't. So you can pass a DOM node into any expression and Lit will just render it there for you. And we support SVG as well. Since SVG elements have a different namespace than HTML elements, you can use a special SVG template tag to create partial SVG templates to build up dynamic graphics very easily. And this is very similar to D3 maybe, but in a declarative kind of way. And we support promises too. So for instance, you can fetch some data off the network and put the promise of that data into your template. And when the promise resolves, the template will update and render the results right into your template. So putting all this together, you can build some really interesting and complex templates by using the full power of JavaScript. And the HTML doesn't try to dictate a style to you either. If you prefer functional programming, where you want to use map and reduce to build up your templates, you can do that. If you're doing imperative programming and you want to build up templates by bit using statements, you can do that. Or if you want to follow a more declarative style, where you have a single template expression and compose it out of other templates, you can do that too. So you can choose whatever style you want. OK, next let's look at how HTML boots and updates fast. So the first thing that we use is we try to use the platform as much as possible. And we use the HTML template element under the hood. And for those of you who haven't used HTML templates yet, they're a really, really useful part of the web component specs. And a template is basically a container of inert DOM. And here inert means that inside of a template, scripts don't run, styles don't apply, images don't load, and so on. And templates can be really efficiently cloned to create new DOM. So typically, that would look something like this. You write your template in HTML. And then in JavaScript, you go find the template, and then you clone it with import node, and then you append it somewhere into your document. But we don't usually want to repeatedly clone a static chunk of DOM. Usually, we want to replace some of it with our data. And this is exactly what HTML lets you do. In fact, you could describe the HTML as a JavaScript syntax for writing efficiently updatable HTML templates. And it works like this. So here's a little HTML template. And lit takes your template, and it replaces all of the expressions in the template with these generic placeholders. And so we get a string of HTML. And then it uses that string to create an actual HTML template element with the placeholders inside of it. And then once we get that element back, we can walk the element and find the dynamic parts, find these replaceholders, and remember where they are. And we create these things we call parts. And these parts have an API that lets us set the value after we've created some content. So we remove the placeholders. And now we have a template without our expressions that we can clone over and over again to create DOM that's just waiting to accept data. And because we've remembered the locations of these dynamic parts, we can go back after the fact. And we can insert data into the parts, into the placeholders. And because we remember the locations of the dynamic parts, we can then really efficiently go back and do updates by adding new data directly to those parts. So another thing that helps make HTML fast is template literals. So they have a couple of nice properties. One of them is that the literals that are passed to a template tag are the same for every call to that tag with the same template. So this lets us do one-time setup work like that HTML template preparation I just showed you. So this is a little bit subtle, but really important. So let's go into a little more detail here. So I mentioned before how a template tag is just a function. Well, the first argument to that function is an array of all the literal parts of your template literal. And if you evaluate a specific template tagged literal multiple times, the tag is called multiple times. But that first argument is the same every single time. So this means we can use it as a cache key to look up our prepared template. So all that work of transforming a JavaScript template to an HTML template and remembering the dynamic parts, that's only ever done once per template, no matter how many times you call it or no matter how many places in your application you use that template. So this is really, really important to how HTML works. And to visualize this, let's consider a really simple template here that we call say hi. We're going to call it once to say hi to Amy, and then we're going to call it again to say hi to Alex. And both times we return a template result that contains a reference to the template and the values. And these templates, they're the same. And they're not just equal the same, they're actually identically the same object. So they share this template in here and they only have to compute it once for your entire application. OK, another property of template literals that we use is that they naturally separate static and dynamic content. So let's look at why that's important. Every HTML template system is responsible for creating and maintaining a tree of DOM nodes. But only some of those nodes are ever updated after they're created. Templates have the structure that I talk about, the separation between static nodes, the blue ones here, and dynamic nodes, the green ones. And then we have the updates. Not every dynamic part changes all at once. Sometimes you just update one value. And so when thinking about the rendering costs of a template engine, I find it useful to think about these two numbers here. One is how many nodes are updated when you make some changes. And two is what is the cost per node? And if we look at something like Polymer that has a very advanced template system, it's able to analyze the relationship between your data and the DOM. And it knows exactly what DOM changes when certain data changes. And so Polymer can scale not with a number of nodes in the template or even the number of expressions, but the number of changes that you have. And if we look at something like VDOM, it takes a very, very different approach. And with Virtual DOM, you re-render your entire virtual tree for your whole template every single time. So VDOM scales with the number of nodes in your template. But it tries to make up for this by driving the cost per node down as low as possible. And so with LitHTML, we're trying to sit somewhere in the middle here and get the best of both worlds. So LitHTML never has to look at or compare the static parts of a template after the initial render. It just leaves them alone. So it just looks at the expressions. So it scales with the number of expressions in your template. But then it tries to drive that cost down as low as possible because expressions are just JavaScript values. And it's mostly just forwarding that value. And if the value doesn't change, it doesn't update the DOM at all. And all of this falls out quite naturally from using template literals. Because we can tell exactly what parts are dynamic and might change and what parts are static and never change. And we don't even have to do any work to figure this out. The syntax of JavaScript just does it for us. Next, we're fast because we take advantage of the fast built-in parsing of the browser. For parsing strings, which make up the biggest part of template literals, a parsing strings in JavaScript is roughly three times faster than parsing generic JavaScript expressions. The VM just has to churn through characters until it gets to the end of the string or the beginning of an expression. And then we take that HTML content of a template and we pass it to the highly optimized C++ written HTML parser. And so this gives us fast parsing speed, and it also means we don't have to ship any parsing logic with our template system, which means that HTML is very small. It's really small. The entire core library fits on a single slide here. At 18 point font, with a little bit of room to spare at the bottom. The HTML is roughly two kilobytes in size. And we're working really, really hard to keep it that way. OK, so here's a lot of things that should theoretically make the HTML fast. JavaScript template literals, HTML template elements, not doing any diffing, being really small. Does it really add up to speed? Well, it is still pretty early in the project. So we haven't released 1.0 and we haven't done all the optimizations we want to. But we have started to port some benchmarks. And one of the first ones that we've done is called the Marko search results benchmark. So eBay released their internal UI framework a little while ago. And they included some nice benchmarks implemented across many frameworks, like Preact, React, View, and Inferno. And so I implemented this benchmark using the full vision for HTML, which is combining HTML with web components, using custom elements, and Shadow DOM. And these are very, very preliminary results I'm about to show you. But they still need to be double and triple checked. But so far, it's looking pretty good. So here we go. We've run it against these other frameworks here. And HTML is amongst the fastest in this benchmark. Here, higher is better. These are operations per second. And this benchmark also tracks the bundle size for each benchmark, for each framework that implemented. And here, lower is better. And HTML is also the smallest of the frameworks in there, coming in at just over 6K for the whole benchmark. So that's not the library. That's the library plus the benchmark components, including all of their templates, a size that's smaller than most complete libraries on their own. So it's really early, but I think we're off to a pretty good start. We've also started to port the DBMON benchmark, where HTML is also competitive with the fastest frameworks there. And it also shows really good stability across a wide range of update workloads. So at least our assumptions about how to make something simple and fast appear to be on the right track. And we still have a lot more optimizations to do. So next, let's look at the API and what makes it easy to use and extensible. So in earlier examples, you already saw most of the HTML API. It's really just the HTML template tag in the render function. Those alone get you a lot of functionality with the types of values that it supports. But HTML is also trying to be as small and as unopinionated as possible. And it can't possibly stay that way and give you all the functionality that you're going to want. So let us extensible in two different ways. The first is what we call directives. So I showed you how a value can go into an expression there. And I showed you how every expression creates a part where there's an API for the part that you can call. Well, this is what a directive looks like. A directive is basically a function that gets invoked instead of the value being passed through. And you mark something as a directive by using this directive kind of decorator function here. And that tells the HTML to call the value instead of passing it along. And what it calls is a function that takes an argument, which is the part. And now that you have the part, you can do whatever you want with it. But the part really only has one API, which is set value. So this is the simplest directive you can write. It's kind of a pass-through directive that just takes a value and puts it into the part like you would have with a simple expression. So that's how easy directives can be to write. Let's look at a real example. One of the built-in directives is called until. So I talked about how promises, if you pass them to a value, it waits for the promise to resolve and then writes the resolve value to the template. Well, sometimes you're going to want to have some placeholder text that shows up before the promise resolves. And so until that you do that, you give it both the promise and some placeholder, some fallback content. And it displays the placeholder first and then displays the promise when it resolves. And it's implemented in only two lines of code. So first, here's the example of using it. We get the response from the network as a promise. And instead of passing it directly to the template, we call this until directive with the promise here and then some placeholder, this loading text over here. And then here's the implementation of until. So it's a function that takes some arguments there and returns a directive. And that directive only has two real lines of code in it. The first one immediately sets the content to the placeholder, so that shows up right away. And then the next one goes ahead and right afterwards sets the value to the promise. And this is going to let it overwrite the placeholder when the promise resolves. So that's a really simple example, but a real world example. And your directives can be as complex as you need to handle custom logic inside of there. And so the other thing that you can do to extend the HTML is to use what we call custom parts. These are ways that you can customize how values are handled across an entire template, including the templates that are nested inside of them. So we've packaged together a couple of custom parts into an optional library that we call lit extended, which gives you a little bit of sugar for your templates. First, it sets properties by default instead of attributes. And then it lets you fall back with an explicit syntax to set attributes if you want. And it also adds declarative event handlers. And the entire lit extended library weighs in at only 540 bytes gzipped. So here's a lit extended template. It looks just like a lit HTML template. First, we have a property binding. And I want you to notice something here is that I used mixed case property name there. Even though lit templates are HTML, because we write them in JavaScript, we can actually go back into the JavaScript value and pull out the original case sensitive property name so that we don't have to do any lowercase to uppercase mapping here. We can set any property name we want. And then if you want to set an attribute, you can add a dollar sign after the name. And here we're going to set the class attribute, not the class property. And finally, if you want to add an event handler, you can just prefix the name with on dash and it will take the rest of the name there and add an event handler for you. Okay, so one thing that helps make lit simple is that we have a very focused API. Lit HTML is doing templating only. It's not a framework. It doesn't have any component model. And we actually designed this to complement web components very well. So to show you what that's like, I wrote a little web component mix in here that adds some lit rendering behavior to HTML element. And the way this works is that your class that you write is going to implement a render function that returns a template result, a lit template. Kind of like React, actually. And then when you want to trigger a re-render, when you notice that something changed that you want to render, your element can call the invalidate method. And the invalidate method simply batches calls to lit's render function and then renders the result to the shadow root. And then here is a custom element using this mix in. So the first thing we do is we apply the mix in to our base class. And then we want to implement a property. So here I implement a property as a getter setter pair. This is something like Polymer will do automatically for you. But I wanted to show you something that wasn't magic. And so what we implement here is a setter that calls invalidate when the value changes. And that's going to enqueue a render of the element. And then finally, you implement a render function which returns on the HTML template. So this is how simple a custom element can be. And in the future, this is actually going to get even simpler. When JavaScript gets decorators or if you're already using decorators with Babel or TypeScript, we can use a decorator to automatically generate that getter setter pair for us. So this can be really, really simple and lightweight with a focused templating library like the HTML. I think a full featured base class that does some other things too might weigh in at less than 3K for the whole thing. That's including the HTML. So together, directives and custom parts, they let you craft kind of your own template system with the capabilities and opinions that you want. You're not stuck with our choices. So we hope that the HTML can do really well across a lot of different measures. Ease of use, using standard JavaScript syntax, speed size, expressiveness, extensibility. We really hope to do well on all of these different requirements that template systems have. So where are we today? We have browser support across the latest version of all major browsers and we're working on IE11 support, which should come very soon. We're also starting to get some great community contributions. People have made fixes and commits to lit itself and some people in Microsoft have made IDE plugins for VS Code and their language service that let you have syntax highlighting and code completion, hover over documentation and all the full intelligence features right inside of your HTML templates. So next up, like I said, we're gonna be working on benchmarks and optimization, IE11 support, we wanna get feedback from users, we'll show integration with web components, get some documentation finally written and then we're gonna work towards a 1.0 release. And we would really, really love for you to try it out and give us your feedback. The API is very simple, so we're not worried that the API is gonna change a lot but we wanna see what people do with it and how they like working with the system here. So you can install it off of MPM, just MPM install lit HTML. And if you wanna have, leave some feedback or find some issues, you can do it at our GitHub repository, it's the lit HTML repo in the Polymer Labs organization. All right, that doesn't, for me, so thank you very much. You can find me on Twitter here and ask questions or I'll be in the lounge and you can ask questions there too. All right, thanks a lot.