Lit-HTML – Wingdings Translator Online

What is Lit-HTML and how to use this library to create HTML templates in Javascript, capable of offering very high performance.

Polymer 3.0 is about to be released (Updated: it’s been out for a while now). At the time of writing these lines, they have already presented several “Preview Releases” and perhaps when you read this text we will already have a first final release. I’m sure there are many other developers who are eager to start working with this library based on Web Components, so to warm up today we’re going to talk about Lit-HTML.

Lit-HTML is a Javascript library created by the Polymer team. However, it is a stand-alone library, which can be used anywhere, even outside of Polymer development.

The library has been developed to meet the demands of a high performance HTML template system, working alongside Javascript with ES6 Modules. We are currently in an early stage of development, but it is already very promising, for various reasons that we are going to explain in this article.

If you keep reading I will give you an introduction to Lit-HTML, a comparison with VDOM and finally a description of the first steps to use Lit-HTML, directly with Javascript, without using Polymer.

Why Lit-HTML was born

To understand the birth of Lit-HTML we have to look at Polymer 3.0. The main change from Polymer 2 is the change from HTML Imports to ES6 imports. This detail means that several things have changed in Polymer, since now the development framework of a component is not an HTML file, but a Javascript file.

Therefore, it was necessary to find a friendly way with the developer, as well as being powerful and versatile, to be able to define templates from Javascript code. Other libraries had done a great job in this regard, such as ReactJS with its “Virtual DOM” (VDOM), but there was still room for improvement.

In the first previews of Polymer 3 the template was written with an ES6 Template String. But that first approximation did not provide the flexibility and performance that the Polymer team wanted, so they devised Lit-HTML, a new system of HTML templates, friendly, light and powerful, which are defined from Javascript.

Lit-HTML Keys

Template systems are created to offer a developer a way to write view code, in HTML, in a way that is easily maintainable. Also, to establish a bridge between the data that is in Javascript and the presentation that is in HTML.

However, the requirements to satisfy for a template system are sometimes difficult to combine. If we want to offer a friendly development experience, it will often be detrimental to the performance of the template system. That is, it often happens that ideal code for the developer translates into the need for more processing for Javascript. Finding a compromise between these two parts is what has been sought when creating Lit-HTML.

The objectives on which Lit-HTML has been built are the following:

Offer a friendly and versatile experience for the developer.
Offer a high performance, when starting the templates, but especially when updating the content of the templates.
Facilitate the extensibility of the template system, so that other developers can easily extend it by adding new functionality.

Also, due to the reported change of Polymer templates, which have gone from HTML to Javascript side, it was necessary to cover those requirements on the Javascript side and not on the HTML side as we had before.

The library developed to meet this need has managed to combine the initial requirements in the best possible way.

It allows you to write HTML inside Javascript code, in a developer-friendly way. At the same time, it is much more powerful than a simple ES6 template string.
It generates templates quickly, basically because it takes advantage of most of the native Javascript ES6 code and also has a template caching system. Thanks to this caching system, if the same template is used several times (something quite common), the template generation process reuses the previous processing.
It updates very fast when there is data that changes inside the template, even faster than React’s VDOM (Later we will do a little comparison of both systems)
It is very small. It occupies less than 2KB.
It is easy to use and extensible for developers, who can build new functionality on top of the library to meet future demand.

Comparison of Lit-HTML and VDOM

One of the most representative libraries to work with views so far is the one implemented in ReactJS, called VDOM or “Virtual Dom”. Since it appeared, it has captivated the community due to its high performance when it comes to manipulating the DOM of the page.

The way VDOM works is well known: There is a virtual DOM created in memory. Every time the data associated with a template changes, an update of the virtual DOM is performed, which happens extraordinarily fast. Then, the virtual DOM is compared against the real DOM of the browser and simply updates those nodes that have undergone transformations. Updating the browser’s DOM is more expensive in processing time, so the VDOM manages to optimize template updates by really only touching the actual DOM where it’s strictly necessary.

However, this approach can still be improved in several ways:

In a template there are static parts and dynamic parts. The static parts are never updated and the dynamic ones, which are basically the data that you have to dump into the template, can receive changes. It is useless to check changes in the entire DOM of the template, when really the changes can only be produced in certain and specific points.
It would be necessary to see to what extent it is really necessary to maintain a copy of the DOM, in a “Virtual DOM”. If the same work can be done without that copy, we will be reducing the amount of memory and processing.

That is where Lit-HTML has been able to optimize VDOM. It doesn’t create a virtual DOM and separates the template into its static parts and its dynamic parts. When data changes occur, you only need to check the dynamic parts of the template, updating those nodes that are really necessary.

In summary, while in VDOM the processing cost (the complexity of the algorithm) grows as the number of nodes in a template increases, in Lit-HTML it grows only depending on the points in the template where values are being interpolated. Apart from occupying less space in KB than VDOM and using less memory, in most cases, the Lit-HTML algorithm is more optimized, because it has to do fewer checks per updated template.

Note: The Google team has published a benchmark in which they compare the Lit-HTML template engine against the one implemented with React’s VDOM, including that of Preact and that of Inferno, Angular, etc. In the metrics obtained so far, Lit-HTML has been the winner.

The image we see below tries to explain this point of the algorithmic complexity of various systems of working with views (it is taken from a talk on Lit-HTML by Justin Fagnani @justinfagnani at the Chrome Dev Submmit 2017):

In the previous diagram we have the static nodes marked with blue color and the dynamic ones in green, where there really are things that can change as the template data is updated. However, when changes occur in a template, not all of the data changes, so it is possible that not all pivot points will actually need to be updated. The “A” represented in this diagram indicates that this data node is the one that has changed.

We have three alternative algorithms represented:

VDOM: where the cost per template update (algorithm complexity) depends on the number of template nodes, both static and dynamic.
Lit-HTML: where the cost of updating the template depends on the number of dynamic nodes.
Polymer: where the upgrade cost depends on the number of nodes that have changed.

Note: In view of the previous image, if we were left with some algorithm, perhaps we would prefer Polymer’s. But you really have to take into account two parameters for performance: 1) The cost per number of nodes and 2) The cost that each node takes you. ReactJS, Preact or Inferno with VDOM are very good because they have been able to optimize the cost per node, due to being processed in memory, but nevertheless they are forced to compare a large number of nodes. Polymer has a high cost per node, but instead performs fewer node updates, as it only checks for nodes that have actually been updated. The advantage of Lit-HTML is to combine the best of both alternatives. In addition, it uses native Javascript behaviors to a greater extent and thanks to this its weight is less and the speed is much greater. Lit-HTML scales based on the template’s dynamic points, which might be fewer points than the ones that have actually changed, but because it renders faster, it achieves better performance than the others.

Native resources that Lit-HTML relies on

As is customary at Polymer, Google engineers have produced an algorithm that uses existing capabilities natively in browsers. We summarize it below, although we do not have to worry about this whole process as developers, since it is something that Lit-HTML does underneath. However, it is interesting to know so that we can better understand how this new library will be used.

Native Label Template

When building Lit-HTML they have been based on the existing template tag in all browsers today.

What they do is build a template tag, a native HTML template. In this template they memorize the holes where the values that come from Javascript are inserted. By changing the data that is dumped into the template, they know at which points they should place it, with which the operations are carried out very quickly.

In addition, the cost of creating a Lit-HTML template is done once per template. If that template is used later, because a certain block is repeated several times, the template tag generated the first time is reused.

Tagged Template String Literals

They are well known. However Lit-HTML goes one step further to take advantage of “Tagged Template String Literals”.

They are simply string literals in which we have various extra capabilities:

We are able to write the strings in several lines of code.
We can use Javascript expressions in them ${} (these expressions are the ones that the template strings themselves already implement)

…