Repository navigation
Why NoDOM?
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.

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.