The DOM Is NOT Slow, Your Abstraction Is

follow up something you shouldn't miss after reading this: Is Anyone Testing On Mobile? and more benchmark details in React + Performance blog post from @aerotwist

---

TL;DR this post shows that good Web performance is easy to reach with zero dependencies, totally cross browser, and using just the good old DOM. This post is *not* against the usage of any mentioned framework in particular, it's rather a voice out of the crowd that's trying to tell you frameworks are not always necessary and, if performance is really that cryptic, you don't need to adopt a new framework in order to solve that cryptic case.
Abstraction is good and it usually helps but it might have costs ... let's be free and choose when we don't need that abstraction by learning native DOM potentials: it's already an abstraction anyway, and it's also quite fast!

---

In 2007, the Dojo team created a benchmark called TaskSpeed in order to compare most common libaries capability and speed.
It's only in 2009, after about 2 years of boring "look mum, my lib is faster than everything else" competitions all over the web, that I've tried to put an end to the discussion showing that native DOM was better than every framework.
Unfortunately, younger developers don't have memories about those days, so this time we're virtually back in 2007 but it's rather "look mum, my DOM abstraction is faster than everything else".
There's so much FUD around this topic, that I hope I can help here clarifying, with the support of a live benchmark, one particular point: the DOM works and performs just fine, and it does a pretty goddamn good job that we should probably stop trying to replace it, replace its role, or the role of any browser engine on the Web.

The JS DBMonster Performance Comparison

Before going any further, I'd like to give you some background.
Parashuram N wrote a blogpost, explaining and open sourcing a presentation he gave about React and its Virtual DOM.
He was able to compare the same app written for react, ember, underscore/backbone, ractive and paperclip and grab results.
I'm actually happy somebody gave me a "TaskSpeed" like playground to implement a pure DOM and JS, zero-dependencies, version of this benchmark.
It's all in one page, I've put some comment, it works in every browser and it would work even in IE8 and lower if I put es5-shim and dom4 in it works even on IE8 thanks to ie8 and es5-shim via conditional comments!
Please note the code has been rushed literally in minutes, and it wasn't meant to be a team friendly code, but I've reasoned in reddit few chosen patterns.

The Benchmark Challenge

I'd like to say that the logic behind this benchmark is deadly simple: basically we have a static list of N clusters that never changes if not for some of their data and per each row.
The analysis of the data is basically absent, that is why it is possible to define static templates per row, and per top 5 queries per each row.
Since we are talking about an application that will never possibly work without JavaScript, having static html templates to consume is basically the exact equivalent of having static templates generated via JS, except we can address directly nodes so that changes will be instantly ready to be made.
Please note that I could have used a similar HTML template approach and address those nodes later on, just to make it slightly more readable. However, it was already easy and simple enough, I thought bringing in that would have been simply out of this post scope.

Am I cheating? Actually not at all: I've tried to understand what problem I had to solve and I've found a simple solution I would have used in the real-world too.
Sorting the table means simply changing the first name as well per each update, which is not a big deal.
That's a data table, the limit of rows displayed per time is static too and the amount of data a human being would be able to read and interact with is arbitrary but never that fast.
If you need unreadable tables that update at speed light then maybe you don't need a browser but a machine able to catch all those updates.

Quite Possibly Pointless

The TL;DR is that this benchmark doesn't represent any concrete real-world scenario.
If we use any framework in that list I'd say we have already decent performance, but if we consider diffed changes then of course if we do something like I've done through the DOM, which is similar to what a Virtual DOM engine would do, it will perform better than any abstraction on top brought in by your framework of choice ... If I add a listener to every cell and dispatch updates, of course it will be slower.
But then again, it would be me doing it wrong, because I need a single updated notification only after the entire table has been refreshed, not for every single cell.
Please note modern Object.observe and Custom Elements work in a similar way indeed, many changes in one update, not one update per each single change.

Compatibility and Loading Speed

What if my zero dependencies DOM version is also the lightest and the most compatible? Yes, that comes for free! The DOM has been stable for years and we should use it without fear instead of keeping avoiding it.
All JS based frameworks have target browsers. Using the native DOM, patching only few browsers, which is again in this case the IE <= 8 family that is easily fixable via unobtrusive conditional comments, grants us compatibility and no memory leaks or greedy memory operations problems.
I have this shit running locally on a Blackberry 7, palm WebOS, and Android 2 devices after simply patching this on top:

var requestAnimationFrame = requestAnimationFrame || setTimeout;

There's nothing else and it works!!! I have no idea about other frameworks, but I'd like to bet here:


Please note I've actually tested all benchmark pages on Android 2 and webOS, there's another video later on, please keep readin...

The DOM Is Just Fine

It puzzles me that developers seem to create themselves a problem and then they point the finger around to search and blame the cause: no, the DOM is not your problem, the fact you brought an over-engineered abstraction on top of a deadly simple task, like a table that needs some quick update, is the real problem you don't want to see.
It scares me that developers behind frameworks seem to be often incapable of getting some fresh air and think out of the cell they put themselves in: learning and using only that framework, ignoring everything else ... sometimes forgetting even common sense, probably shadowed by the framework approach.
Let's do ourselves a favor, let's stop being religious about any sort of framework and learn what the native world has to offer, what other frameworks have to offer too, and what's the best solution for that specific problem, which is never every problem we have!
Every framework was born to solve a very specific problem ... have you asked yourself if that is really the same problem you have and the one you need to solve?
Moreover, there will always be a faster, ad-hoc, way to do this or that and your framework cannot cover all the cases ... it's actually the opposite: the more cases it will cover, the slower it will be. So let's please stop moaning about the DOM and start doing things in a different way ... shall we?
We'll be those with most benefits, after all, so please think about it.

See Through Your Eyes

There has been some very active and passionate discussion within comments, I've finally decided to test all the links in the competition for real.
If the choice of a framework should be based on how much performance we need, then older Hardware and older devices are those struggling the most, those needing performance.
Well, it turned out that React here at least worked (not on Android 2.3, only on webOS), but it delivers the worst performance compared with underscore, paperclip, or my DOM version.
I let you judge who is the winner between these 4, and I tell you also that while ember and reactive didn't show up at all in both devices, React, as well as paperclip didn't work on my Android 2.3 smartphone.


I've also tested many other devices in the following "Is Anyone Testing On Mobile?" post, don't miss it!

Quick Recap

We've got videos, live links, comments and everything else to nail down at least some fact out of this post.
What has the DOM to offer, if we ditch a framework?

• wider granted compatibility, it does not cost extra time or money to support more devices
• zero overhead, if not for essential DOM normalizer polyfills. Usually dom4 is all I need, and it always worked so far.
• decent, if not optimal, performance. If a framework based on DOM can be fast, we can be similarly fast too, if not faster in some case
• we are using Web standards, not some in-house or ad-hoc solution, meaning we are granting ourselves free maintenance, performance boost, and updates in the future

The Web is all about non breaking, and the DOM has been there long time. It's there to stay, and learning it has been my survival kit and antidote for all these years of changes.
If you want my advice: know what the DOM is and what it does, and always be free to choose the right tool, including frameworks, and all their handy abstractions, for the right job.
Don't choose blindly after a shiny benchmark, even my DOM one can mislead if you are looking for better ease, and predefined patterns ;-)

Thanks for reading!