Skip to content

Why NoDOM?

John O'Sullivan edited this page Nov 2, 2026 · 19 revisions

You may well ask, why another Web GUI architecture, surely React is the final word?

The answer is simple: no, because SPA Web architectures are too slow for the most demanding applications. Nolan Lawson's excellent blog on benchmarking SPA frameworks provides hard data to prove the point.

Why are they too slow? Because the browser main thread is doing all the work: CSS and HTML rendering as well as executing JavaScript. The result is sluggish and unresponsive websites. So it's hardly surprising that Google’s own Web UI standards define three key benchmarks…

First Contentful Paint How long for first page render? Google: ideally under 1.8s

Largest Contentful Paint How long for most complex page render? Google: under 2.5s is good, over 4s is poor

Interaction to Next Paint Click response time. Google: aim for below 200ms

The simple fact that Google’s own benchmarks rate an LCP of under 2.5s as good tells us all we need to know. I know from long experience that it’s not good enough for the trading floor. Hence the success of specialist companies like AG Grid focused on making 2D grids of numbers update faster in JS. Take a look at the roundtrips in section 3 of the diagram below; these are the expensive paints and interactions that Google's standards highlight. Typical_Web_SPA_Architecture

Take a look at the diagram of Chrome internals below: the top box showing "Renderer Process" is the expensive paint and interaction work. NoDOM is faster because it eliminates all this work and replaces it with a custom WASM render engine designed for trading applications.

chrome_internals

Clone this wiki locally