Writing Robust AngularJS Web Applications
Any DOM operation is slow and computed properties are extra slow.
The real problem is that DOM is implemented in C++. It turns out that
it is very expensive to call a C++ function from JS. So any DOM access
is magnitudes slower than JavaScript object access.The second problem is a conceptual one. The entire AngularJS philosophy is based
on the fact that the source of truth is the model. It is the model that drives declarative
UI. But by observing DOM properties, we are turning things upside-down! All of a
sudden it is DOM that starts to drive the model that in turn, drives the UI. We are
getting into a circular dependencies problem here.
It might be tempting to watch for DOM property changes, especially
when integrating third party JavaScript components into AngularJS
application. Be aware that it might have a dramatic impact on the
$digest loop performance. Avoid watching for DOM property
changes or at least measure performance after introducing such a watch.Limit the number of watches to be evaluated
If you've fine-tuned existing watches and removed all the bottlenecks, but your
application still needs a performance boost, it is time to take more radical steps.
Remove unnecessary watches
AngularJS two-way data binding is so powerful and easy to play with that you
might fall into a trap of abusing it in places where a static value would do.
In Chapter 10, Building AngularJS Web Applications for an International Audience, we
were discussing one example of such a situation using data binding for translations.
Translations data change very infrequently (if ever!). Yet, by adding AngularJS
expressions for each translated string, we are adding a lot of calculations to each
turn of the $digest loop.
When adding a new interpolation expression to templates, try
to assess if it will really benefit from the two-way data binding.
Maybe a value in a template could be generated on the server side,
for example.