Super Fast Tree View in JavaScript

I thought I’d share a way of writing your JavaScript that will make a tree view hierarchy render and respond very quickly.

Firstly, the demo. I’ve got 100,000 items, quite a hefty data set, which is randomly generated in a function. You can change the number of items easily in the JS area. Click on the + or – icons to expand or collapse nodes.

See the Pen Super Fast JavaScript Data Tree by Chris Smith (@chris22smith) on CodePen.dark

It’s still quick, like instant, with 100,000 items. It can start to slow a little at a million but I’d say it’s still acceptable given that kind of data.

One Long List

The trick is in how the data is structured. It’s one big array, not hierarchical data with objects inside other objects. The reason for this is pretty simple, it’s all about iterations or looping. If you have a single array you can run through the whole list of items once. If it’s nested you have to get into loops inside other loops and it gets more complicated and takes longer. In fact, you’d be lucky for it to work at all without getting stack overflow errors.

JavaScript Magic

With a single array you can use the built in JavaScript Array methods, which are very fast – map(), filter() and some(). I’d definitely recommend reading up on these. All three work in IE9+ so hopefully you shouldn’t have to worry too much about browser support.

I use map() to convert each data item into a HTML list item which I can insert into the DOM. I use filter() to quickly find the children items of any item by returning a subset, and I use some() to see if an item has children. The beauty of some() is that once its found it child it stops iterating, saving time.

Easy on the DOM

The other part of this is keeping DOM manipulation to a minimum. Playing around with data in memory trivial for a browser but making changes to the DOM and rendering things on screen takes time. So, only the nodes that are needed right now exist in the DOM – there are not hidden items waiting on the sidelines. So, a new <ul> is added when you expand a node and the <ul> is removed when you collapse. A + icon is shown if the item has children of its own but we don’t know anything about how many it has or what they contain until it’s expanded.


If you found this useful it might be worth looking at my older post Lightning Fast Filtering in JavaScript, which uses a lot of the same principles.

To DOM or Not to DOM?

I’m trying to work out when it’s best to put attributes in the DOM and when it’s best to just leave them in JavaScript objects. This is going to be hard to explain so bear with me.

Let’s suppose we have a list of users on a page. Each user has a number of properties, not things we’d display like name, age and gender but hidden things like permissions, e.g. isAdmin, canComment, isManager, etc. These properties are going to be used in logic to determine how things are displayed on screen – maybe an extra bit of detail or an icon. Just as an example, if canComment is true then a speech bubble icon will appear.

The basic HTML might look something like this:

  <li id="001" class="user">John</li>
  <li id="002" class="user">Paul</li>
  <li id="003" class="user">George</li>

Behind this is a JavaScript object, like this:

var users = [
    id: '001',
    name: 'John',
    canComment: true
    id: '002',
    name: 'Paul',
    canComment: false
    id: '003',
    name: 'George',
    canComment: false

So, user John is allowed to comment and we want to show an icon. There are 2 approaches:

  1. Use the DOM

    We could add the icon inside each <li> and then add a class (class=”user can-edit”) or a data-attribute (data-can-edit) to the <li> and use CSS to display it as appropriate, e.g. .user[data-can-edit] .icon { display: inline-block }.

  2. Use JavaScript

    Or, we could write a JavaScript function to filter the objects to just those with canComment set to true, get their ids, and then loop through the list items adding the icon HTML when the ids match the filtered list.

The first approach puts the property into the DOM, puts the icon into the DOM and then uses CSS to show/hide it. It feels easy. The icon is always sat there waiting, like an unchecked checkbox, only shown when needed (checked). There is still logic but it’s done up front. The DOM is actually human readable and it’s easy to see which users can and can’t edit for debugging purposes. I see this approach used a lot, including the hidden DOM elements, usually because of the way templates or components are used. It’s easier to include it and pass a property to toggle whether or not it displays. It also means that if we want to change the property during the lifecycle of the page, e.g. take away John’s commenting permission, it’s minimal change to the DOM.

The second approach only touches the DOM to insert the icon where needed. It does all the logic in JavaScript and the output in the DOM reflects what the user actually sees on screen. There are no hidden elements. This has advantages when it’s scaled up, in that it keeps the DOM lighter and there’s no waste. The JavaScript is incredibly fast in modern browsers so the functions won’t slow anything down, especially if using .filter(), map(), etc. The trick here is not to loop through and add the icons one at a time but to run through building the whole list and just doing the one insert or replace operation. This makes the DOM less readable as all the canComment data is in JavaScript.

So, is it better to use the DOM for data or keep it in JavaScript?