Web workers

JavaScript is known for its event loop. Usually, JavaScript programs are executed in a single thread and different events are scheduled by being pushed in a queue and processed sequentially in the order of their arrival. However, this computational strategy is not effective when one of the scheduled events requires a lot of computational time. In such cases, the event's handling will block the main thread, and all other events will not be handled until the time-consuming computation is complete and the execution passed to the next one in the queue. A simple example of this is a mouse click that triggers an event, in which the callback does some audio processing using the HTML5 audio API. If the processed audio track is big and the algorithm running over it is heavy; this will affect the user's experience by freezing the UI until the execution is complete.

The web workers API was introduced in order to prevent such pitfalls. It allows execution of heavy computations inside the context of a different thread, which leaves the main thread execution free, capable of handling user input and rendering the user interface.

How can we take advantage of this in Angular? In order to answer this question, let's think about how things work in AngularJS. What if we have an enterprise application, which processes a huge amount of data that needs to be rendered on the screen using data binding? For each binding, the framework will create a new watcher. Once the digest loop is run, it will loop over all the watchers, execute the expressions associated with them, and compare the returned results with the results gained from the previous iteration. We have a few slowdowns here:

• The iteration over a large number of watchers
• The evaluation of the expression in a given context
• The copy of the returned result
• The comparison between the current result of the expression's evaluation and the previous one

All these steps could be quite slow, depending on the size of the input. If the digest loop involves heavy computations, why not move it to a web worker? Why not run the digest loop inside the web worker, get the changed bindings, and then apply them to the DOM?

There were experiments by the community which aimed for this result. However, their integration into the framework wasn't trivial.

One of the main reasons behind the lack of satisfying results was the coupling of the framework with the DOM. Often, inside the callbacks of watchers, AngularJS directly manipulates the DOM, which makes it impossible to move the watchers inside a web worker since the web workers are executed in an isolated context, without access to the DOM. In AngularJS, we may have implicit or explicit dependencies between the different watchers, which require multiple iterations of the digest loop in order to get stable results. Combining the last two points, it is quite hard to achieve practical results in calculating the changes in threads other than the main thread of execution.

Fixing this in AngularJS introduces a great deal of complexity into the internal implementation. The framework simply was not built with this in mind. Since web workers were introduced before the Angular design process started, the core team took them into consideration from the beginning.