#dirty checking

We will be taking a very concise look into digest cycles, and their use in Javascript single page applications.

Accompanying Slides

This is a diagram from the official AngularJS documentation that explains what a digest cycle is. If this goes over the top of your head, don't worry, it did for me too. It is more complicated than it needs to be.

A digest cycle is, simply put, code that runs at an interval. This interval may be sometimes simply as fast as possible after the previous one, and sometimes the interval is set.

They are typically used to aggregate expensive tasks such that they do not have to run multiple times when there is no need to do so. For example, DOM rendering.

While we are here to talk about digest cycles in the context of Javascript SPAs, a discussion of this will not be complete without talking about where the idea for this originated from.

The Game Loop is a term familiar to most games developers. When writing a game, one would typically set the interval of the game loop, such that each cycle runs as soon as possible after the previous one completes. As such a variable frame rate is inevitable, and techniques such as linear interpolation of time elapsed is used to calculate the rendered position of a moving object, for example.

An introduction, and an in-depth explanation.

In single page apps, digest cycles are also used. Their intent here is quite different, because maxing out frames per second is not usually a goal for web apps. When using dirty checking to observe for model state changes, SPAs have taken two different approaches - dirty checking and accessors, which you can read about on my blog. In fact this presentation is a derivative work of that post.

AngularJS' $digest, EmberJS' Ember.run+runLoop

When using dirty checking, as AngularJS does, a digest cycle is necessary. When using the alternative to dirty checking - accessors - as BackboneJS and EmberJS do, a digest cycle is not necessary. In fact, BackboneJS does not have one, but EmberJS does.

So why are digest cycles important in SPA frameworks? As mentioned earlier, it is where you would put your code that dirty checks your models for differences to previous state. Secondly - and this is why EmberJS uses it despite using accessors - is that it improves efficiency.

Each change on each model sets off a DOM update, and thus a re-render, and a reflow. The latter two are expensive operations. Instead of doing this once per model change, we instead aggregate the changes until the point where the digest cycle executes - updating a purely in-memory buffer with the new DOM with all the changes. When the it is time for the digest cycle to execute, this buffer replaces the relevant parts of the DOM; which then re-renders and reflows just once per digest cycle.

Changes listeners that are triggered are aggregated in a similar manner, and all of them are fired at once during the digest cycle.

App.Person = Ember.Object.extend({ bmi: function() { var height = this.get('height'); return this.get('weight') / height / height; }.property('weight', 'height') });

Here is an example of a computed property in an EmberJS app. What this says is "whenever the weight or height properties of a Person model change, its bmi property could change too."

Computed properties rely on the framework maintaining a directed acyclic graph (per model class) between properties, and needs to traverse them (per model instance). These traversals can be expensive, so we defer them to - you guessed it - the digest cycle.

Now that we know more about digest cycles - what is the main takeaway from it? The number one thing to avoid, is doing too much in each digest cycle. Once the time taken to perform the work needed in each digest cycle approaches or exceeds the duration of the interval between each one, the app will become noticeably laggy.

Here I have linked Misko Hevery's Stackoverflow post on dirty checking, where he works out some numbers for what these thresholds are. If you are developing a SPA, especially one that is intended to run on a mobile device, you should check out his numbers. I have discussed performance metrics in a previous post.

var socket = io.connect(); return { on: function (eventName, callback) { socket.on(eventName, _.throttle(function () { var args = arguments; $rootScope.$apply(function () { callback.apply(socket, args); }); }, 500)); // limit to once every 500ms } // ... };

This snippet by Brian Ford is from his post on building huge AngularJS apps. To avoid executing this expensive function every digest cycle, he wraps it using underscore's throttle function, thereby ensuring that it only runs twice per second instead.

To round up:

Digest cycles are quite similar to the Game Loop programming pattern

They are used in SPAs to execute code at a set interval

They are where dirty checking is done

They are where DOM updates, listeners, and other expensive tasks are aggregated for performance gains

Measure & curb the execution time of the work done in each digest cycle

One of the many ways in which EmberJS, AngularJS, and BackboneJS differ is in how they treat their models. AngularJS uses dirty checking on Plain Old Javascript Objects (POJSO); whereas EmberJS and BackboneJS both use accessors (getters and setters) on wrapped objects.

We will be exploring the ways in which these two approaches differ, and the implications these differences have when it comes to choosing which Javascript framework we we should write our single page apps in.

The Basics

Models are one of the fundamental tenets of an MV* architecture. They are the basic building blocks where information about various object states get stored and retrieved form. Most Javascript frameworks for front end user interfaces used to build single page applications (SPAs) use MV* architectures, and a feature that most of them have in common is the ability for the View to update the Model, and for the Model to update the View.

For this to happen, there needs to be to be a means to "listen" for these changes, and then trigger some code to respond to that change. Depending on which flavour of MV* architecture the framework uses, these may use a Controller, ViewModel, or Presenter as a conduit. Leaving the middleman out, we have:

When a change occurs in an input field in a form, the object modelling that form should be updated.

a change in the View --> response triggered in the Model

When a change occurs in the object modelling that form (perhaps as a result of a sync via AJAX), the corresponding fields in the form should be updated.

a change in the Model --> response triggered in the View

With MV* frameworks like EmberJS and AngularJS, you get this out of the box - you only need to declaratively specify which models are linked to which views - and they call this "Two-way Data Binding".

With other MV* frameworks like BackboneJS, you get this too, but a significant amount of manual "wiring" is required - you have to set up the listeners in both directions yourself.

In order for this to work under the hood, the framework will need a way to "observe" for changes of Models. This post will explore two methods that Javascript MV* frameworks use to listen for changes on Models.

Note that we will not be exploring how Javascript MV* frameworks listen for changes in Views in this post, as essentially. They are for the most part wrappers around EventTarget.addEventListener, and are thus not quite as interesting.

Listeners and Digest Cycles

Implementations of listeners and of digest cycles are separate, but closely related. When a listener on any change gets fired, the code that it triggers is by default run immediately.

However, for a number of reasons, performance being the main one, the framework may instead queue these listeners. This framework would also perform digest cycles, which are, simply put, code that runs at a set time interval. In each of these digest cycles, the triggers of the listeners in the queue are all run at once.

Using POJSO

Using Plain Old Javascript Objects makes for code that has very simple syntax, and thus is easier to write. With dirty checking, no special syntax is required - simply change the properties of an object, and it "magically" triggers the required listeners.

(Behind the scenes, the framework runs a digest cycle, and during each one, it performs a dirty check, which is a deep comparison on all the Models that are presently displayed within the View. If a difference is detected, and a listener is attached to that difference, it is triggered.)

Using accessors, on the other hand, implies two additional things, which add to, and thus complicate the syntax.

Firstly, you would need to make all of your objects within the Model wrapper classes provided by the framework, e.g.:

var Book = Backbone.Model.extend({ /* ... */ }); var myBook = new Book( /* ... */ );

Secondly, in order to trigger the listeners correctly, you would need to remember to use gets and sets whenever using its properties, e.g.:

myBook.set({title: 'Qryq - Stop RESTing and use queues instead'}); //triggers listeners myBook.attributes.title = 'Qryq - Stop RESTing and use queues instead'; //does NOT trigger listeners

Computed properties

Being able to define a property as being computed from a number of others is a particularly nifty feature of EmbersJS, and made possible because of its use of accessors. 2

App.Person = Ember.Object.extend({ bmi: function() { var height = this.get('height'); return this.get('weight') / height / height; }.property('weight', 'height') });

In the above code, we are creating a model which has a property named bmi. This property is bound to the weight and height properties of the object - and we do not need to cache it, or recompute it each time we use it.

Betrand Meyer's Uniform Access Principle states that "all services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation." Computed properties, implemented in the manner that EmberJS has, are one way of implementing properties observing this principle. Bertrand goes on to name a number of benefits this yields. The main benefit, in my opinion, is that it gives the developer one less thing to have to manage, and thus have to worry about.

Performance

Performance is a particularly tricky issue to tackle.

On the surface, it would appear that dirty checking would consume more memory and processor cycles than event listeners. The reason for this is straight forward: There is no need to check for differences in each cycle. When you are doing this at a very high frequency, which happens if you have a large number of objects, responsiveness starts to take a hit.

However, this issue not so straightforward - Misko Hevery, creator of AngularJS, makes some good points on this, in his S/O answer on AngularJS data binding. Essentially, dirty checking is "fast enough" for most user interfaces:

"So the real question is this: can you do 2000 comparisons in 50 ms even on slow browsers? That means that you have 25 µs per comparison. I believe this is not an issue even on slow browsers these days. There is a caveat: the comparisons need to be simple to fit into 25 µs."

-- Misko Hevery

Thus we need to ensure that all comparisons are not slower than this threshold. In practice, more complex models with computed properties are an eventuality, and a comparison during a dirty check of such computed properties is likely to exceed this threshold. When enough of these objects are present, the lag during digest cycles (occurring between each render) will bring down the frame rate, and at some point begin to become noticeable to the human eye - so be prepared to cache these more complex model states, and to handle their state changes manually.

Digest cycles with accessors

I disagree with Misko, however, on his other points that change coalescence cannot happen using accessors; and that change listeners need to fire immediately using accessors. Indeed, these are features that would be lacking in basic implementations of non-dirty checking based change listeners.

However, do note my earlier point about the implementations of change listeners, and the implementations of digest cycles being separate, but related. When using dirty checking, a digest cycle implementation is compulsory - you have to poll for changes at an interval. When using accessors, a digest cycle is optional; however, digest cycles are certainly not mutually exclusive to dirty checking.

A good real world example of a Javascript framework that combines accessors with digest cycles is EmberJS. EmberJS uses accessors to aggregate change listeners, and trigger them only once per digest cycle. It does not, however, implement change coalescence - and this is genuinely much trickier to achieve using accessors compared to using dirty checking, but it should be possible 3.

Adding some metrics

The issue of performance is very much still an open debate. It is likely that using accessors will outperform dirty checking in some apps, but observe a reversal in performance in other apps. Ideally, one should try both out, and see which works better. If you do not have the time to implement your app using multiple frameworks to test this hypothesis for your particular app - and I suspect that this will be the case for most of us - then you could make an educated guess as to which approach will yield the better performance based on answers to the following questions:

Will you be using many computed properties?

If so, will you be willing to cache model states and handle state changes manually?

Threshold: ~25 µs per "piece of information"

Will you have many models bound to views?

If so, will you have many views rendered on the screen at once?

Threshold: ~2000 "pieces of information"

Are you targeting mobile devices for your app?

If so, adjust the thresholds above as appropriate

Misko does not define what he means by a piece of information. So here is one possible method:

Each Javascript primitive (i.e. a String, a Number, or a Boolean) would count as one piece of information.

For Objects and Arrays, one simply counts the total number of primitives contained within, plus one for itself.

This is necessary because not all model states take an equal amount of time to compare; some may even take an order of magnitiude longer than others.

e.g. {name:'Bob', weight:80, height:200, foo:[true, false]} --> 1 Object, 1 Array, 5 primitives --> 7 pieces of information

Of course, this metric is only intended to be a rough gauge. Different measures or definitions of what constitutes pieces of information, are valid, as long as the same one is consistently applied to all models. What is more important here, is to anticipate and plan for for future increases in model complexity.

If it is not possible to estimate or anticipate the (future) complexity of your models at this stage, you could treat the point on performance as a case of something where the verdict is still out, and instead base your decision on the other points of difference.

Future proofing

Future editions of ECMAScript may potentially allow listeners to be set directly on POJSO. This is already in the works with w3c's object binding proposal, and TC39's Object.observe/video. In fact Google Chrome has already implemented the latter.

That will remove the necessity for both accessors and dirty checking, as frameworks will most likely be reimplemented to use this to take advantage of native execution over interpreted execution for listening to changes on Models. This will mean that if you have written your app using a Javascript framework that uses dirty checking like AngularJS, your code will not need to change at all. However, if you have written your app using a Javascript framework that uses accessors like EmberJS or BackboneJS, you will need to refactor your code1 in order to gain the extra performance.

(Of course, it is the other way around for the authors of the Javascript frameworks. A dirty checking framework will need to do a more complex refactor to switch to using listeners on POJSOs instead of dirty checks in each digest cycle, compared to an accessor based framework.)

Conclusion

Yehuda Katz spoke recently about EmberJS at MelbJS 4. At the end of his talk, he mentioned that he was on the board of ecmascript.org, stating that one of the proposals that he was passionate about and was promoting, was being able to set listeners natively on POJSO objects. (proposal linked above, under the "Future Proofing" section).

These are nifty and would allow Javascript frameworks to leverage the best of both worlds with regards to the main points of differentiation between accessors and dirty checking that we have explored in this post.

Unfortunately, ES6 is not coming out for a while yet. The proposal to implement these features has yet to be accepted for inclusion into ES6, so it may take even longer.

Thus I began to think about how the Javascript frameworks that are out there today have tackled this problem - in particular BackboneJS, AngularJS, and EmberJS. How have these issues been addressed here and now?

There has not been much written about this, so I have put this this rather small, and often overlooked, aspect of Javascript frameworks under a magnifying glass.

Picking a Javascript single page application framework is difficult, and hopefully I have given you one more set of considerations to mull over in picking one.

tl;dr

Dirty checking

Pros

Easier syntax when using POJSO

Code refactor not required with next ECMAScript

Cons

Need to set up own cache & listeners

Unsuitable for high frequency callbacks/ large number of models

Accessors

Pros

Allows computed properties

Avoid excessive null/undefined checks on models

Cons

More verbose syntax

Performance: ?

Footnotes:

1 Not a very complicated one. Should be accomplishable using some nifty greps and seds

2 I do not see any reason why it cannot also be accomplished using dirty checking, however, I have yet to see this combination implemented in a SPA framework.

3 Personal conjecture only here. Again, I have yet to come across an implementation of this in a SPA framework. Someone would have to do it first, before we make a judgment as to whether this is more efficient than dirty checking. Change coalescence over POJSOs based upon Object.observe has already been done, so it could just be a matter of time.