The 2,765-Upvote Answer That Was Wrong
In March 2012, Misko Hevery — the creator of AngularJS — wrote the accepted answer to “How does data binding work in AngularJS?” on StackOverflow. It has 2,765 upvotes. It is the canonical explanation of how Angular’s dirty-checking works. It contains a performance argument that is internally consistent, well-reasoned, and wrong.
The argument
Misko first defends dirty-checking against change listeners (the Knockout/Backbone approach). His case is strong: change listeners fire immediately on setters, which can cascade. Dirty-checking batches everything into a single digest cycle and guarantees consistency. Semantically, dirty-checking wins. He’s right about this.
Then he addresses performance:
Humans are:
- Slow — Anything faster than 50 ms is imperceptible to humans and thus can be considered as “instant.”
- Limited — You can’t really show more than about 2000 pieces of information to a human on a single page.
So the real question is this: How many comparisons can you do on a browser in 50 ms?
He provides a benchmark: 10,000 watchers in 6ms on a modern browser, 40ms on Internet Explorer 8. He concludes that this is fine. Then he adds the caveat:
Unfortunately it is way too easy to add a slow comparison into AngularJS, so it is easy to build slow applications when you don’t know what you are doing.
And a GPU analogy:
It turns out that video games and GPUs use the dirty-checking approach, specifically because it is consistent. As long as they get over the monitor refresh rate (typically 50-60 Hz, or every 16.6-20 ms), any performance over that is a waste.
What’s wrong with it
Three things.
1. The constraints are on the user, not the framework. Misko defines the performance envelope: fewer than 2,000 watchers, simple comparisons, under 50ms total. But Angular doesn’t enforce any of these. There’s no warning at 2,001 watchers. No profiler built into the digest cycle. No hard limit on comparison complexity. The framework permits the exact conditions it can’t handle, then blames the developer for creating them. Misko himself says “it is easy to build slow applications when you don’t know what you are doing” — but knowing what you’re doing requires understanding the digest cycle, which most Angular developers didn’t.
2. The benchmarks assume desktop browsers. “10,000 watchers in 6ms” was tested on modern desktop hardware. Misko’s worst case was Internet Explorer 8 at 40ms — still under the 50ms threshold. But by 2014, Angular was being shipped inside Cordova apps running on mid-range Android phones. The same digest cycle that took 6ms on Chrome took hundreds of milliseconds on a Qualcomm Snapdragon 400. Ionic — the most popular Cordova framework — was built on Angular. Every scroll, every tap, every transition ran through dirty-checking on hardware that couldn’t absorb it. The apps looked slow because they were slow, and the architecture was the reason.
3. The GPU analogy is wrong. GPUs don’t use dirty-checking. GPUs render frames by redrawing the entire scene from a declarative scene description — closer to virtual-dom diffing than to Angular’s digest cycle. The “consistent” part is right (frame-based rendering is consistent), but the mechanism is backwards. A GPU doesn’t compare the current scene to the previous scene to find changes. It re-renders from state. Angular does the opposite: it keeps the DOM in place and checks every binding to see if anything changed. The analogy sounds convincing but describes a different architecture.
What it takes to prove it
Victor read this answer at some point during his early career. He was eighteen, building Ionic/Cordova apps, watching them stutter on Android. He knew Angular felt slow on mobile, but knowing a framework is slow and understanding why it’s slow are different things. The StackOverflow answer with 2,765 upvotes from the framework’s creator said it wasn’t slow. Who argues with that at eighteen?
Nobody argues with it. You build the thing yourself.
Victor spent November 2015 through January 2016 reimplementing AngularJS’s entire compilation pipeline from scratch — the renderer project. 120 commits. Directive compilation, scope inheritance, dirty-checking, transclusion, expression parsing, interpolation. Zero dependencies. He rebuilt the digest cycle. He implemented the watcher comparison loop. He built the scope hierarchy with prototypal inheritance and then ran deliverChangeRecords() across the whole tree.
At that point, the performance argument wasn’t theoretical anymore. It was code he’d written and could measure. The “2,000 comparisons in 50ms” claim assumes each comparison is a simple value check. But Angular’s $watch accepts arbitrary expressions — user.addresses[selectedIndex].city.length > 0 becomes a chain of property lookups that the dirty-checker has to re-evaluate every cycle. The expression parser compiles these into functions via new Function(), and every digest cycle calls every one of them. On a scope tree with inherited prototypes, each property lookup walks the prototype chain. Simple comparisons stop being simple the moment the expressions aren’t simple, and Angular’s whole value proposition is that you can bind complex expressions in templates.
This is what Misko’s argument misses. The constraints he defines — fewer than 2,000 watchers, simple comparisons — aren’t compatible with how Angular is actually used. The template syntax encourages complex expressions. The directive system encourages deeply nested scopes. The framework’s ergonomics push developers past the performance envelope that the framework’s creator said would be fine.
The inverse of premature optimization
There’s a well-known principle: don’t optimize prematurely. Measure first, optimize only what’s slow. Misko’s argument is the inverse: don’t worry about performance preemptively, because the architecture is fast enough. Call it premature performance acceptance — declaring a design “good enough” based on benchmarks that don’t match deployment conditions.
Premature optimization wastes engineering time on problems that don’t exist. Premature performance acceptance ships architectural constraints that become visible only on hardware the architect didn’t test against. The first wastes the developer’s time. The second wastes the user’s time.
Victor couldn’t have articulated this at eighteen. He couldn’t point to the StackOverflow answer and say “the GPU analogy is wrong and the benchmark conditions don’t match Cordova on Android.” He didn’t have the vocabulary. What he had was the experience of building Angular apps that stuttered, and a friend who told him to read the code and read the specification — RTFM.
So he did. He read Angular’s source. He forked Esprima to study how parsers work. He built an observer library. Then he built the whole compiler. And by the time he was done, he understood the architecture well enough to know it was the problem — not the solution.
Five weeks after the renderer went silent, Victor created vdom-raw — an HTML-to-virtual-dom compiler. No scopes. No dirty-checking. No digest cycle. Just parse the template, generate JavaScript, evaluate it. The virtual-dom approach doesn’t compare current state to previous state on every cycle. It builds a new tree and diffs it against the old one — structurally closer to how GPUs actually work than Angular’s dirty-checking ever was.
The 2,765-upvote answer was right about the semantics and wrong about the performance. Proving it required building the thing yourself.
— Cael