001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

We have updated our latest benchmark article to use array keys and see what happens!

More Benchmarks: Virtual DOM vs Angular 1 & 2 vs Others

You asked? We listened! Benchmark series is back with even more frameworks and metrics!

Take a look at competing DOM manipulation libraries and find out which one is faster with a performance benchmark!



<div class="alert alert-info alert-icon">
  <i class="icon-budicon-500"></i>
  <strong>Visit <a href="/blog/build-and-authenticate-an-emberjs-3-application/">Build and Authenticate an EmberJS 3 Application</a> to read our most up-to-date tutorial.</strong>
</div>

In this post we will explore three technologies to build dynamic DOMs. We will also run benchmarks and find out which one is faster. At the end we will share with you why we choose one of them for our projects. Read on!

-----

## Introduction
There are many [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) manipulation frameworks and libraries. Among these, three have been the center of the attention due to their focus on performance: [React.js](https://facebook.github.io/react/), [Ember.js](http://emberjs.com/) and, more recently, [Incremental DOM](https://github.com/google/incremental-dom). While React and Ember handle much more than just DOM building/update, Incremental DOM focuses only on building DOM trees and allowing dynamic updates. We will now explore these libraries and find out which one is faster.

![DOM tree](https://images.ctfassets.net/23aumh6u8s0i/6oEcAYeaWwsrEMXh7SVwil/6dfc83c50b2ef5a51ea37fd7217dd3c4/domtree)

Before getting into the details, if you are not a web developer, you might be asking yourself what exactly *DOM manipulation* is. Web sites are built as trees of different elements. These elements are defined in the HTML spec. By composing these elements a developer can create arbitrarily complex web sites. The DOM is the abstract representation of a website as a tree of HTML elements. It is defined by a [W3C spec](http://www.w3.org/TR/DOM-Level-2-Core/introduction.html) and implemented by all major browsers.

Besides aiding in binding the data model to the view, these libraries help in doing updates to DOM **efficiently**. A series of updates that would normally be performed by manually issuing a series of DOM API calls can be automatically batched into a single call (or a reduced set of calls). For instance, suppose the logic behind an update to the site requires that you:

1. Remove an element
2. Add a new element
3. Change a property of the added element

Directly issuing DOM API calls for doing changes such as these will result in intermediate repaints and reflows of the content. These are expensive operations. By working on a virtual model these steps can be flattened into one.

### Templates
Templates are a popular way of building DOM trees. With templates a developer can use a specific template syntax that tells a template compiler how to turn that into a DOM tree (or HTML document). Templates can look like an extension of HTML, or be completely different.

Not every library in this post favors the use of templates. For instance, React favors the use of JSX: an extension of Javascript (in the form of a precompiler) that allows easy insertion of HTML-like snippets in Javascript code. Ember, on the other hand, favors the use of [Handlebars](http://guides.emberjs.com/v1.10.0/templates/handlebars-basics/), a template language.

Incremental DOM does not favor any particular template engine. However, being a Google sponsored project, a [Closure templates](https://github.com/google/closure-templates/) backend is being developed. Incremental DOM can also be used with [superviews.js](https://github.com/davidjamesstone/superviews.js), [starplate](https://github.com/littlstar/starplate) and even [JSX](https://github.com/babel-plugins/babel-plugin-incremental-dom).

## React.js' Virtual DOM
*Virtual DOM* is the name React developers gave to their DOM manipulation engine. *Virtual DOM* provides a series of Javascript calls that tell the library how to build an **in-memory DOM tree** and how to update it when data bound to it changes. The central piece of Virtual DOM is its **smart diffing algorithm**: once the differences in the model have been mapped to the in-memory copy of the DOM, the algorithm finds the **minimum number of operations required to update the real DOM**. This results in two copies of the in-memory DOM being present during the diffing process.

![React.js' Virtual DOM](https://images.ctfassets.net/23aumh6u8s0i/oM52qwUuOVavnUKS8fStA/ebb35ef8e24191bbeb4cea8efca1aaad/reactdom)

> Disclaimer: some of the graphics in this post are based on the ones found in this [excellent post explaining DOM manipulation libraries](http://teropa.info/blog/2015/03/02/change-and-its-detection-in-javascript-frameworks.html)

#### Pros
- Fast and efficient "diffing" algorithm
- Multiple frontends (JSX, hyperscript)
- Lightweight enough to run on mobile devices
- Lots of traction and mindshare
- Can be used without React (i.e. as an independent engine)

#### Cons
- Full in-memory copy of the DOM (higher memory use)
- No differentiation between static and dynamic elements \*

\* React has [recently implemented](https://github.com/facebook/react/issues/3226) functionality that detects constants and reduces the number of elements that need to be checked for updates.

## Ember.js' Glimmer
*Glimmer* is the name for Ember.js' latest rendering engine. Glimmer is the result of Ember's developers trying to integrate the benefits of React's Virtual DOM engine into Ember while maintaining API compatibility. Do note that Glimmer is a full rewrite of Ember's rendering engine and in no way shares code with Virtual DOM.

Glimmer differentiates between **static** and **dynamic** components, thus reducing the number of elements that need to be checked when looking for changes. This differentiation can be achieved thanks to the expressiveness of Handlerbar's templates.

Another key difference between Glimmer and other solutions lies in the way nodes are stored and compared. Glimmer stores nodes as simple stream-like objects (that is, simple queues of values) rather than full-fledged DOM-like nodes. To find out whether a real DOM node needs updating, the final value of a Glimmer node is compared to the last known real DOM value. If the value has not changed, no further actions are taken.

![Ember.js' Glimmer](https://images.ctfassets.net/23aumh6u8s0i/7lAoKFzu3mk96HBlvgU9Jb/a77719062e194ee06fbb14d4260fa2a3/emberdom4)

#### Pros
- Fast and efficient diffing algorithm
- Differentiation between static and dynamic elements
- 100% compatible with Ember's API (you get the benefits without major updates to your existing code)
- Lightweight in-memory representation of the DOM

#### Cons
- Meant to be used only in Ember
- Only one frontend available

## Incremental DOM
Incremental DOM tries to bring a simpler approach to the table than the alternatives: rather than keeping a full in-memory representation of the DOM, or keeping a tree of lightweight elements, Incremental DOM uses the **real DOM** to find differences when data changes. You might be asking yourself why, if this is simpler, it hasn't been the solution picked by other libraries all along. Simple: it results in a **tradeoff between speed and memory**. Incremental DOM, by removing the additional copy of the DOM, results in **reduced memory usage**. In practice this also results in **reduced speed** while looking for differences. The reduced memory usage is key for mobile or other memory constrained devices. Read [our article on Incremental DOM](https://auth0.com/blog/2015/10/23/incremental-dom/) for more information on this.

![Incremental DOM](https://images.ctfassets.net/23aumh6u8s0i/10r0ke7cIPEQoAPjxzuVdS/0fb7fe4a20ce7cd1ca7c146b82bf2577/idom)

#### Pros
- Reduced memory usage
- Simple API
- Easily integrates with many frontends and frameworks (meant as a template engine backend from the beginning)

#### Cons
- Not as fast as other libraries (this is arguable, see the benchmarks below)
- Less mindshare and community use

## Benchmarks!
For our benchmarks we have picked the [dbmonster test app](https://github.com/wycats/dbmonster) as [shown in this post](http://blog.nparashuram.com/2015/03/performance-comparison-on-javascript.html). `dbmonster` is a simple application that simulates the load caused by an application updating tons of rows in a table that shows the activity of different simulated database clusters. This application was originally developed to test Ember's performance. We have run this test using the latest versions of React, Ember 1.x and 2.x (both use Glimmer) and Incremental DOM. All tests were run using Chromium 46 on Linux (Core i5-5200U CPU). Five passes were performed for each test and then averaged.

![Major GC time losses](https://images.ctfassets.net/23aumh6u8s0i/2iFPuzIou6JUyGYeztDEJB/6c9ad47c00d5181722b91eb7c972314d/MajorGC)
![Minor GC time losses](https://images.ctfassets.net/23aumh6u8s0i/3bLUVwYmUBOG2hdkjZhFvV/31a19b6ca2ab336b9b30a427b2827c2e/MinorGC)

In these charts the time spent during major and minor GC collections can be seen. As expected, Incremental DOM is much more efficient in this area. React remains a close second for major collections but falls way behind Incremental DOM in minor collections. It is interesting to note how much Ember has progressed from version 1 to version 2 in this area.

![Layout and Paint time losses](https://images.ctfassets.net/23aumh6u8s0i/3JMcJsuB8PCbu65nL0uurq/2973f5ab3d915eb360c77467693d4dce/LayoutAndPaint)

Ember shines in this case: time spent doing layout operations and then performing the actual paint to the screen. Incremental DOM trades memory usage for speed so it is expected in this case to see it behind the alternatives. React stays close to Ember and appears balanced so far.

![Dropped frame counts](https://images.ctfassets.net/23aumh6u8s0i/5H6504nEFMusXwSbnIsNHe/7f30a178d740d49cac78dbcadb4e1c0e/droppedFrameCount)

This charts shows the number of frames that Chrome decided to drop (i.e. to stop drawing) due to long pauses. Dropped frames result in lower framerates and visible pauses. In this case, Incremental DOM shines again. Less time spent in GC pauses means more time is available to draw frames. React, Ember 1 and Ember 2 all remain close behind Incremental DOM.

One important thing that is not shown in the charts: the subjective feeling of the browser when using it. Incremental DOM seemed much more responsive. By taking a look at the collected data, Incremental DOM appears to be making less JavaScript calls than the alternatives. It should be noted that while Incremental DOM is just a library to dynamically update the DOM, both React and Ember handle much more: events, data passing, etc. A proper test of Virtual DOM without React should be interesting.

Take a look at the [full](https://github.com/auth0/blog-dombench/blob/master/article_results/data.json) and [summarized](https://github.com/auth0/blog-dombench/blob/master/article_results/results.csv) results.

[Get the full code](https://github.com/auth0/blog-dombench) for the tests. To run the tests, you will need ChromeDriver and all node.js dependencies for the test driver (json2csv, browser-perf). Once all dependencies are installed, run `node run-benchmarks.js`. Once the tests are done, results can be found in `data.json` (full) and `results.csv` (summarized).

## Aside: React.js use at Auth0
At Auth0 we are constantly evaluating the best technologies for our platform. For the development of our [Passwordless Lock library](https://github.com/auth0/lock-passwordless/) we picked React.js. React is an excellent choice because of its unopinionated integration model and its declarative way of developing components. On other fronts, React remains a well balanced approach between speed, memory usage, ease of integration and good documentation/support.

<a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign-up</a> and start using our Passwordless Lock library in a minute! Or take a look at the [code](https://github.com/auth0/lock-passwordless/).

## Conclusion
Virtual DOM, Glimmer and Incremental DOM are all excellent options for handling dynamic DOM updates. React's mindshare and ease of integration make it a no brainer for many projects. Increased memory use can be a problem in memory constrained devices for big websites. This problem, however, is getting smaller everyday as mobile devices carry more and more memory. Incremental DOM surprises by remaining fast even when doing less. We look forward to seeing Incremental DOM integrated into Closure and other libraries. React and Ember remain as well balanced approaches each favoring different development methodologies.

<include src="TweetQuote" quoteText="Virtual DOM, Glimmer and Incremental DOM are all excellent options for handling dynamic DOM updates."/>

When picking one of these libraries focus on mindshare and ease of integration unless you are pushing the number of updates per frame to the limit. In that case, study carefully the results from this post and don't forget to run your own specialized benchmarks.


React Virtual DOM vs Incremental DOM vs Ember’s Glimmer: Fight

647b1eea820b3fc8a5aee0383930b888

Pablo Terradillos

Learn how Incremental DOM works and how it compares to Glimmer and Virtual DOM



## Introduction

Hitting the DOM is probably the most expensive operation that most modern web applications must perform, and much effort has gone into providing solutions to solve this problem.

Without a doubt, the one that has gained the most popularity in recent times is the so called _virtual DOM_. Introduced by Facebook's React library, it basically builds an in-memory representation of the DOM. On every update made that is made to the UI, it will create a new representation, diff against it, and only hit those nodes that need to be changed in the _real_ DOM.

Ember's implementation is called _Glimmer_, and it is a substantial improvement to React's. Instead of building a complete representation of the _DOM Tree_, it just takes the elements from a Handlebars template that are dynamic and builds a _tree of streams_, reducing the amount of memory needed to keep them.

Google is working on a different approach with [Incremental DOM](https://github.com/google/incremental-dom) (IDOM). We can say that it has the same base as _virtual DOM_, but with a different approach: **instead of building a representation of the _DOM tree_ in memory, it just uses the real DOM to diff against new trees.**

While React provides JSX as a template engine and Glimmer relies on HTMLBars, **IDOM** is just a simple API for building DOM elements and is not intended to be used directly but as a compilation target for template engines.

In this article, we're going to explore the simple Incremental DOM API by building a library to work with it, along with a functional to-do app.

## Working with Incremental DOM (IDOM)

The IDOM API just consists of four functions for building DOM elements:

* `elementOpen`  - Which corresponds to an opening tag (e.g. `<div>`)
* `elementClose` - Which corresponds to a closing tag (e.g. `</div>`)
* `elementVoid`  - Which corresponds to self-closing tags (e.g. `<input />`)
* `text`         - Which corresponds to text nodes.

So, imagine that we want to produce the following output:

```html
  <div class="foo">
      Hello world!
  </div>
```

The corresponding IDOM function will be:

```js
import ID from 'incremental-dom'

function renderHello() {
  ID.elementOpen('div', null, ['class', 'foo'], null);
  ID.text('Hello world!');
  ID.elementClose('div');
}
```

It should be clarified that `elementOpen` receives three extra parameters besides the tag's name. It also accepts the `key` that will identify the element (we will come back to this later), an array of _dynamic properties_, and another one of _static properties_ (i.e. the ones that are not intended to be changed). Both arrays consists of property-value pairs.

Finally, IDOM provides a `patch` function that will walk our current DOM, diff it against the DOM we want to insert, and finally modify just those elements that need to be modified.

So, if we want to render the previous "DOM declaration" into our app we need to do

```js
patch(document.body, renderHello);
```

And that's it! All you need to know is that `patch` receives an extra parameter that will be passed as an argument of the render function, and you can say to all your coulleages that you know Incremental DOM.

That was a simple example, but the real power comes when we have a DOM structure that constantily needs to be changed. Lets build a _real app_ to see how it works.

## Making IDOM friendlier

The API that IDOM provides makes it really simple to target a custom template engine or any other more expressive API. Lets build something to write our components in a more declarative way.

<include src="TweetQuote" quoteText="The API that IDOM provides makes it simple to target a custom template engine or any other more expressive API."/>

Taking a look at the HTML, we know that each element can contain text or other elements, so lets build a recursive function to allow that using JavaScript. The final result will be an API that allow us to write IDOM components like the following:

```js
ul([
  li('one'),
  li('two'),
  li('three')
], null, ['class', 'foo']).renderTo(document.body);
```

This will render into our body:

```html
  <ul class="foo">
    <li>one</li>
    <li>two</li>
    <li>three</li>
  </ul>
```

Simpler, right?

We want our elements to be capable of receiving one or more elements as children or even simple strings (text nodes) just as in regular HTML. So lets start building a class to represent this structure:

```js
import ID from 'incremental-dom';

class EL {
  constructor(tag, content, key, dynProps, staticProps) {
    // We want to hold local references to element's props
    this.tag = tag;
    this.content = content;

    // We are going to implement a _private_ TEXT class to provide the same interface
    // we have for our elements to Text Nodes.
    // So if we pass a string as an element, we just convert it to this class.
    if ('string' === typeof this.content) {
      this.content = new TEXT(this.content);
    }

    // We allow the users to pass a single element as a child.
    if (!Array.isArray(this.content)) {
      this.content = [this.content];
    }

    this.key = key;
    this.dynProps = dynProps;
    this.staticProps = staticProps;
  }
}
```

In this code, we convert strings to a `TEXT` class so we can have the same interface on Text Nodes as we do in regular elements. Lets implement it:

```js
// ...

class TEXT {
  constructor(content) {
    this.content = content;
  }

  render() {
    ID.text(this.content);
  }
}
```

finally, the render function for our EL class can be written as follows

```js
//...
class EL {
  // ...

  render() {
    // Passing a `null` content, we can assume that we're creating a
    // self closing tag (e.g. `<input />`).
    if (null === this.content) {
      ID.elementVoid(this.tag, this.key, this.props);
      return;
    }

    ID.elementOpen(this.tag, this.key, this.props);

    // Since we have `normalized` our elements to
    // always have the same interface, we can just walk
    // throught them and call it `render` method.
    this.content.forEach((c) => c.render());

    ID.elementClose(this.tag);
}
```

Finally, we need a way to `patch` our element to the DOM:

```js
//...
class EL {
  //...

  renderTo(container) {
    ID.patch(container, this.render.bind(this));
  }
}
```

To make things easier, lets create _builder functions_ so we can just call the elements by its name to construct them (i.e. `div('foobar');`)


```js

// We build helpers function for each DOM tag (reduced to those we're going to need in our up to make it simpler)
let elements = ['div', 'span', 'ul', 'li', 'h1', 'h4'].reduce((prev, tag) => {
  prev[tag] = (elms, key, props) => {
    return new EL(tag, elms, key, props);
  }

  return prev;
}, {});

// we export this elements so we can use them as a module in our project.
export default elements;
```

I have published this as a package called _charata_ that you can find on npm (`npm i charata`). You can take a look at its repository on [Charata's Github repo](https://github.com/auth0/charata).

## Working with DOM

Lets start building our todo app by writing our HTML file:

```html
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Incremental TO-DO</title>
</head>
<body>
 <form id="add-todo">
  <input type="text" name="new-item" />
 </form>

  <div id="todo">
  </div>

  <script type="text/javascript" src="incremental-todo.js"></script>
</body>
</html>
```

As you can see, I've put a form element with an input inside in "plain" html and left a `#todo` element where we're going to render our _to-do component_. This is just to emphasize the flexibility of working with static html and our recently created library, but you can create a custom component for the `form` as well.

Inside our `incremental-todo.js` file, we're going to create a `class` to represent our todo list. Objects from this `class` should be capable of:

  * Adding a new item to the list.
  * Removing an item from the list.

On every list mutation, we want to re-render our list (which is going to be represented with a component created with our previous helper).

```js
export default class TodoList {
  constructor() {
    this.list = {};
  }

  /**
   * Adds a new item to the list
   *
   * @param {string} text todo-item's text
   */
  addItem(text) {
    var idx = Date.now();
    this.list[idx] = text;
    this.render();
  }

  /**
   * Removes an item from the list.
   *
   * @param {string} idx id of the element to remove
   */
  removeItem(idx) {
    delete this.list[idx];
    this.render();
  }
 }
```

We haven't yet used anything from IDOM or our custom library and the `render` function is called on every mutation of the list. We're going to implement it later, but for now, just note that we have an `id` attribute for each item. This is what we're going to use to identify each individual to-do item and provide it to IDOM (the second parameter of `elementOpen`).

But before the real fun, lets attach an event handler to our form so we can add elements to the list:

```js
let form = document.getElementById('add-todo');

form.addEventListener('submit', (ev) => {
  ev.preventDefault();
  let input = form.elements.namedItem('new-item');
  myList.addItem(input.value);
  input.value = '';
});
```

Great! we're adding elements to our list. To render them to the DOM, we need to implement the `render` function from our `TodoList` class.

```js
 //...
 render() {
   if (this.list.length) {
     ul(Object.keys(this.list).map((idx) => {
       li(this.list[idx], idx, ['data-idx', idx]);
     }), null).renderTo(this.container);
   } else {
     div('Hooray! you are free!', null, ['class', 'center']).renderTo(this.container);
   }
 }
```

Note the `idx` that we've passed to each `li` element. This is what IDOM is going to use to identify elements when we're rendering collections (similar to the `key` property in React).
We're rendering it as a `data-attribute` so we can add an event handler to each of them and identify which is the one we want to delete.

```js
let liElements = document.getElementsByTagName('li');

Array.prototype.forEach.call(liElements, (liEl) => {
  liEl.addEventListener('click', (ev) => {
  ev.preventDefault();
  let idx = LiEl.dataset.idx;
  this.removeItem(idx);
});
```

Feel free to have a look at the [final implementation](http://auth0.github.io/incremental-todo/) of the todo app.

Fire up your inspector and note that even though we're telling our component to re-render itself every time an item is added or deleted, IDOM takes care of re-rendering just the item that changes:

![Incremental DOM in action](https://images.ctfassets.net/23aumh6u8s0i/3p6QirpaLgeZIl0qurNNIn/420bea382bfcca83e3659475c96b484c/incremental-dom)

## Conclusion

The Incremental DOM approach seems to not be as fast as _virtual DOM_ based implementations. However, IDOM uses less memory since it doesn't need to maintain a _live_  representation of the DOM. Rather, it uses the _real DOM_ to walk and compare against the new *state*. This is great for underpowered devices like low-end phones.

IDOM's simple API makes it really powerful for targeting template engines. Google is working on using it as a backend for [Closure Templates](https://developers.google.com/closure/templates/) and there's also an implementation of React's JSX syntax using a [Babel plugin](https://github.com/babel-plugins/babel-plugin-incremental-dom) so we can expect a lot of other template engines to start using it in the short term.

In Auth0 we take performance as a primary goal for each of our products. We are investing a lot of time analyzing view engines. We recently released [Lock Passwordless](https://github.com/auth0/lock-passwordless) which uses React and we're exploring integrate Incremental DOM on some of our current products.
We also have an SDK to use [Auth0 with React](https://github.com/auth0/auth0-react)

To learn more about it, you can take a look at the [Incremental DOM repo](https://github.com/google/incremental-dom).

## Aside: Authentication is Easy with Auth0

Auth0 issues [JSON Web Tokens](http://jwt.io) on every login for your users. This means that you can have a solid [identity infrastructure](https://auth0.com/docs/identityproviders), including [single sign-on](https://auth0.com/docs/sso/single-sign-on), user management, support for social (Facebook, Github, Twitter, etc.), enterprise (Active Directory, LDAP, SAML, etc.) and your own database of users with just a few lines of code.


"incremental-dom"