As I noted in my lunch talk at Carbon 5 the other day, Ember.js optimizes for developer productivity--which is not to say that you can't have multiple goals, but at the end of the day, one thing has to be your priority.

For the past few months, we've prioritized creating an API that is friendly, conceptually simple, and correct. Our view implementation, for example, handles many edge cases that other frameworks might punt on.

We believe that nailing the API first is important for a number of reasons. We can increase performance without you having to change your app; the same is not true if we spend time making it fast, then require you to change the API once we realize it is not a good one.

The cool thing about declarative systems is that once you express your intent in a way the framework understands, we can apply heuristics and optimizations that every app developer gets for free.

Some people pooh-pooh the idea that better abstractions require a "sufficiently advanced compiler," but I think the history of the field has proved that it's the case. V8 and LLVM are examples of projects where we continue to eke out performance increases well past what I think the average person would have expected. I saw the same thing in Handlebars-- a lot of people criticize Handlebars for being separated into multiple steps, as it increases the size of the library somewhat, but being able to reason about each of the steps in the compilation pipeline has given contributors the ability to reason about possible slowdowns and turned it into one of the fastest template libraries around.

So, all of that being said, I would never recommend using bindings for animation. I'm not aware of any framework or library that recommends this. Bindings were designed for infrequently changing values that need to be displayed to the user. Since the smoothness of animation is critical to the user experience, it's hard to argue that any optimization is premature optimization. All of the animation we've done in our Ember apps is done via either CSS transitions, or using requestAnimationFrame and modifying the DOM element directly.

While Ember.js will presumably always be technically slower than Backbone, slower doesn't have to mean slow. That being said, there are obvious performance gains to be made here, and I'm glad we've got Jeremy to keep us on our toes. :P