The Ember Run Loop is one of the most interesting mechanisms in the Ember framework. Unfortunately, it is not well documented in official guides. Here I’d like to share a summary of an Ember Run Loop webinar that I held for the Netguru team. That's the first part out of 4, so stay tuned for more!

Are you excited about learning Ember Run Loop and want to get an all-in-one guide? Download our Ember Run Loop ebook by Kuba, a Ruby on Rails developer and great Ember.JS enthusiast!

The Ember Run Loop is one of the most interesting mechanisms in the Ember framework. Unfortunately, it is not well documented in official guides. It might seem like a well hidden abstraction, but, when working on complex Ember projects, you’ll notice it when you bump into strange cases where:

data is synchronized in a weird order,

actions are executed in unexpected ways,

most importantly: your vanilla JS or jQuery plugins are not working.

While working with Ember, I found myself frequently searching the web for Ember Run Loop content. There are some interesting posts out there, but here I’d like to share a summary of an Ember Run Loop webinar that I held for the Netguru team.

In this guide, I will cover why the run loop exists and how it actually works. Then, I will share a couple of interesting examples, all of which are available in JSBin so you can work with them yourself. We will also see how to use the Ember Run Loop while wrapping external JS libraries and explore the auto run mechanism. In the end, I’ve also included some other interesting resources that helped me understand the run loop.

How do JavaScript frameworks work?

To answer this question, you must understand more deeply how every JS framework works at the low level, without all the abstractions. First of all, when you load the website with its JS code, the whole code, every line, is executed only once - right after the download finishes. For this reason, basically all the code that works in the browsers is event-driven - it works by responding to some events that happen in the environment. These events are fired by the browser and handled by handlers provided by our scripts. Crucially, browsers execute at most one event per one millisecond. This limitation may be considered as both an advantage and a disadvantage. We’ll talk about this again later.

The Ember framework consists of a very short setup phase in which it registers handlers for multiple events, including keyUp , keyDown , mouseMove , and others. The full list is here. This setup phase is executed as a handler for the DOMContentLoaded event to make sure that the full content of a page is ready. After this setup phase, everything that happens in our single page application is a response to a user behaviour: a click, a mouse move, etc.

Why does the Ember Run Loop exist?

Before we find out how the run loop works, let’s stop for a while and talk about why it’s necessary. If you understand why it exists, the underlying mechanism should become much clearer.

The main reason for creating the Ember Run Loop is to improve the performance of applications. The run loop reduces the number of expensive actions, such as rendering, by batching them in queues. Moreover, it organizes the execution of code in logical blocks, so it’s easier to maintain and we can have more control over the order of execution.

However, to achieve this we need to know how the run loop works and how to use it properly. And this is the hard part.

Let's look at the following example from the Ember Guides.

In this very academic example, we set the height of the DIV elements and calculate their offset one after another. It demands three very quick operations of setting, and three more expensive operations of calculating layouts and offsets. If you could batch them by similarity, you would get a huge performance gain, due to caching the values of offsets and only having one layout recalculation.

This example is pretty rare in day-to-day work. Let’s take a look at a more relevant Ember-style example that consists of one computed property based on two attributes - firstName and lastName . Somewhere in the code, potentially in some action, you set these two one after another.

Without any batching mechanism, you would end up recalculating a computed property twice during one action. This is an obvious waste of time. Indeed, if you had a scenario where the rendering mechanism had a higher priority than computed properties, but lower than setting attributes, you would end up rerendering the layout four times! The run loop lets you avoid such horrible messes.

Today you learned why the Ember Run Loop is an important thing in Ember environment. It’s fundamental to understand the limitations that are imposed by the browsers. However, we still don’t know much about the Ember Run Loop mechanism itself and how it works. The next part will guide you through some basics and show you a glimpse of the Ember Run Loop guts. In the meantime, you can ask questions about the Ember Run Loop in the comments. See you soon!

If you're looking for more resources on learning Ember.JS, check out our must-read list and enjoy your Ember journey!