官术网_书友最值得收藏!

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.

主站蜘蛛池模板: 武夷山市| 林口县| 新绛县| 迭部县| 台山市| 仙居县| 台南县| 长垣县| 金湖县| 宕昌县| 华安县| 温泉县| 句容市| 健康| 荣昌县| 麻阳| 微山县| 昭苏县| 赤城县| 南康市| 汉中市| 宜都市| 涞水县| 拜泉县| 贵阳市| 沧州市| 绥棱县| 高邑县| 望江县| 牡丹江市| 四会市| 永善县| 横山县| 拉萨市| 芦山县| 中江县| 卫辉市| 温州市| 改则县| 荔波县| 罗定市|