Animation support in Ember 1.1

I’m a little confused what problem is being solved by this proposal. I agree there is a problem, but this solution attempts to dictate too much to the developer. I don’t want Ember touching (or caring about) my styles. Ever.

Truthfully, it seems like the problem proposed is a marketing problem. I love Ember because it has very carefully regulated which problems it attempts to solve. Sometimes that makes it less flashy than other libraries from a very high level…but that’s entirely beside the point.

I use animations / transitions very liberally in my applications and the only real problem I have is that I don’t get to tell Ember when it’s okay to remove a view from the DOM. Some nice to haves would include built in handling for transition and animation events in the view (animationEnd and transitionEnd, for example).

If I’m understanding it correctly, @tchak 's solution seems create the tools I need to do this and doesn’t seem terribly complicated.

It seems that people are eager to discuss internal view lifecycle hooks as well. Awesome! Let’s move this part of the discussion here: Internal view lifecycle hooks for animation purposes

The original purpose of this thread was to talk about how route animations should be supported. Let’s continue with that here.

Great input. I just had a chat with @krisselden. We talked about letting the router keep its own internal history stack, which should store the animation effects it has performed to get to the current state. When user hits the browser’s back button, we will know which animation to perform by taking the “opposite” effect. Example: Look at Imagine that the up arrow in the lower right was constructed like `{{linkTo “page” upPage transition=“slideDown”}}. When user clicks the up arrow the next page slides down from the top. When the user hits the back button we know that we performed a slideDown to get there, so we will perform a slideUp to go back.

Thanks a lot for your input. You don’t have to use animated route transitions. You can hook into the upcoming view lifecycle hooks and do it however you want. That’s where we want to go: Giving us the power to manually customize when it’s okay to remove a view.

1 Like

Can you elaborate a bit more on your usecase? Thanks

Offhand, I think that the back-transition should be queued and executed as soon as the running animation has completed. Just like if the user clicks a {{linkTo}} or something.

It would be very nice to know when something is animating so we can disable sensitive items that might be accidentally clicked.

Apparently, I am in the vast minority, but I’ve been doing heavy animation in web apps, mobile web apps and with Ember for years. Here’s an example Ember app with heavy animation:

Animations should be controlled by Javascript and backed by requestAnimationFrame for maximum control and performance. I’ve written more of my strategy online (

I believe Ember.js should adapt an existing Tween engine, such as Tween.js to be promises based. Tween & timelines (sequences of tweens) should be treated similarly to ajax and be able to delay route & state transitions until they have completed.

The limitations of a system where you cannot sequence transitions is huge. We should develop a robust system, not the lowest-common-denominator of “crossfading views”. If animation were baked into Ember in a robust way, it could be used to control image sequences, run illustrated animations, respond to touch/mouse events and respond to scrolling for ye olde parallax.

Thanks for reading.


In touch environments, I used an ApplciationGestureManager instance to manage this scenario.


Sure. A very simplified example:

{{#each model}}
  {{list-item transitionIn="fade"}}

Just a thought…


It may be useful to understand how native frameworks do this, like CoreAnimation in iOS. I personally have no experience using it but it may provide some inspiration?

1 Like

Random thought: it’d also be nice to have support for something like this:

{{#if content animate="fade"}}
  I gracefully fade in and out!

I guess if with animation params set would make the bound if view be a normal view vs a metamorphs view and apply some default (but overridable) classes while the element is animating in and out of existence.

Not sure how much overlap there is with the animated outlet stuff though.


Yes, we should definitely have this. else should also work. Also this:

{{#each things animate="effect"}}

I’m working on some ideas on how all this could work.

Is it still planned to Ember 1.1?

1 Like

Not 1.1, but the work is slowly still in progress.

Hey all - I just finished adding animations to an ember app I’m working on and wrote up my thoughts here.

I think the router promise system works really well with animations, and it would be great to see promise hooks on views so that people can build their own animated views, and then we can work out some best practices from there.


Is there plans for adding this as a feature flag in the canary build anytime in the near future? I am working on a new application that needs transition animations and is probably a few months away from being feature-complete, and I am just trying to gauge whether or not I should wait on this built-in animation support, or roll my own implementation.

1 Like

Give some help back at You’ll save time from changing your implementation in the future and increase your reputation/credibility.

I need to implement some animations. I’d be happy to contribute some help to this effort if there’s an open PR I can look at (or even a fork to clone). Where is this work currently happening?

I have implemented a route animation API which I would like to share to be considered, I think is simple and could be used on multiple cases:

My main requisites are:

  • Be able to animate with CSS or JS.

  • A transition should be a step in my route transition process.


      animation: function(transition) {
        var applicationController = this.controllerFor('application'); 
        return this.animationPromise(transition, function() {
            applicationController.set('position', -1);



      animation: function(transition) {
        return new Ember.Promise(function(resolve, reject) {
               $('#view-element').animate(xxxx, function() {


animation hook supports returning a promise object on the same way than ‘model’, ‘beforeModel’ and ‘afterModel’ hooks.

I think, that having integrated animation in the chained promise of the route transition solves some of the @machty considerations.

We could test right now this approach if we rewrite HandlerInfo.resolve method (router.js) like this example.

.then(animation, null, this.promiseLabel("Animation"))

I am sharing a working gist making animation with CSS classes bound to object properties which is the way I prefer. This examples requires to disable the renderTemplate default convention to have loaded all the route templates to have immediate animations.


I just found out about Velocity.js, might be a good option.

Velocity outperforms jQuery at all levels of stress, and Transit beginning at medium levels of stress.


If there’s anything I can do to make Velocity.js ( seamlessly integrate into the Ember.js workflow, please let me know by opening an issue on GitHub:

I am a huge Ember.js fan and user.