Run Loop Queues


Background Info

I recently saw a tweet asking the same question that I had when I started diving in:

Where can I find a complete list of Ember RunLoop queues and their descriptions?

I have wondered the same thing so I took some time to track down as much of the details as I could. I have tried to indicate where I obtained the information about each queue (in case I am incorrect).

Ember Run Loop

The run loop is managed by an external micro-library named backburner.js (ebryn/backburner.js) which handles most (possibly all) of the actual queueing and scheduling of the run loop. This micro-lib is not Ember specific (although it was written with Ember in mind), and can be used from Backbone or even a standalone JS app.

Ember starts off by configuring Backburner with three queues (sync, actions, destroy) which are setup here, two additional queues (render and afterRender) are added by the ember-views package here, and finally the ember-routing package also adds routerTransitions here.

Listing Available Queues and their Order

You can see the list of run loop queues in your application along with their ordering by running in the console:
["sync", "actions", "routerTransitions", "render", "afterRender", "destroy"]

Queue Breakdown

  • sync - Bindings use this queue so this method is a useful way to immediately force all bindings in the application to sync. Use this queue anytime you need any changed state to propagate throughout the app immediately without repainting the UI (which happens in the later ‘render’ queue added by the ember-views package). (See here for details.)
  • actions - This is the default queue and is used the most throughout the Ember codebase.
    • Used for and by default.
    • RSVP promises resolve in this queue.
  • routerTransitions - Used in router transitions to prevent unnecessary loading state if all promises resolve on the actions queue first. (See here.)
  • render - Used for rendering views after bindings have synced. All DOM element operations happen in this queue.
  • afterRender - Used for scheduling actions that occur after all view rendering (DOM operations) has occurred.
  • destroy - Used by Ember.Core.Object within the destroy function (see here) to schedule destruction to happen at the end of the run loop.

Ember run loop guide

I will be working over the next few days on combining this information along with the general run loop info from @tarasm’s async testing guide, and some of @machty’s work on visualizing the run loop.

The ultimate goal is to add a new guide on the site to aid newcomers (and old-hands) in learning about the Run Loop.

Feedback is definitely encouraged…


Looks good @rwjblue. This will help a lot of people who are learning the run loop.



is It possible integrate window.requestAnimFrame when aviable to fast DOM update instead of setTimer ? the performance of window.requestAnimFrame are incredible !!!



#5'sync', function() { console.log('syncing'); }); { console.log('running'); });

Unless I am misunderstanding, which I may well be, this should log “syncing” followed by “running” if the following is true of the actions queue:

But it seems to be “running” first (paste into interactive run loop). What exactly is meant by those functions, and also Ember.RSVP.Promises, resolving in this queue?

#6 runs immediately, spinning up the run loop (in case additional thins are queued based on what was run)


Hi there,

I have just finished writing a blogpost about the Ember Run Loop, Backburner the micro-lib that powers it. It is quite long but I guess I have covered quite a lot.

If you’re looking to understand how it does some of it’s magic I guess reading this blogpost could help you.

Here is the link:

Antonio Nalesso



FWIW I wrote a long thing about the runloop a while back ( where I tried to walk somebody through it from the very beginning.