# Trying to understand the view-update loop better

**URL:** https://discourse.elm-lang.org/t/trying-to-understand-the-view-update-loop-better/7136
**Category:** Learn
**Created:** [March 21, 2021, 11:23am UTC](https://discourse.elm-lang.org/t/trying-to-understand-the-view-update-loop-better/7136 "2021-03-21T11:23:16Z")
**Posts on this page:** 1
**Showing post:** 4

<div class="post-metadata">

### Author: ![mattpiz](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/mattpiz/32/860_2.png) [@mattpiz](https://discourse.elm-lang.org/u/mattpiz)
#### Post date: [March 21, 2021, 1:16pm UTC](https://discourse.elm-lang.org/t/trying-to-understand-the-view-update-loop-better/7136/4 "2021-03-21T13:16:34Z")

</div>

> [@pdamoc](#):
>
> The first loop is capable of handling a high frequency of updates. The second one is bound to the animationFrame. This means no more than 60 updates per second.

To complement this, JavaScript is single threaded, so the next frame has to wait for any computation started before it was scheduled. That is why pages sometimes feel unresponsive. If you want to be really sure that the view was updated, you can wait for message from [`onAnimationFrame`](https://package.elm-lang.org/packages/elm/browser/latest/Browser-Events#onAnimationFrame) before starting computation, or run it in a different web worker.

You might also be interested in those discussions:

- [Long-running computations in Elm that won't freeze the page](https://discourse.elm-lang.org/t/long-running-computations-in-elm-that-wont-freeze-the-page/5836)
- [How to deal with blocking JS code (using ports)?](https://discourse.elm-lang.org/t/how-to-deal-with-blocking-js-code-using-ports/818) (it seems you already participated in that conversation but still relevant)

---

_[View the full topic](https://discourse.elm-lang.org/t/trying-to-understand-the-view-update-loop-better/7136)._