As client-side frameworks go, Ember.js already has quite a history. It originated within the Sproutcore project as a lean and modern successor to Sproutcore 1.x, the heavyweight and component-laden framework that Apple used to build MobileMe and then iCloud. When it became apparent that Sproutcore 2 would never be a complete replacement for Sproutcore 1.x, it was renamed Amber.js as a clean break for the two projects. Shortly thereafter it was renamed again to Ember.js to avoid confusion with the Amber Smalltalk project.
I'm just glad this round of musical names didn't end on SproutcoreCore.js.
We're not here for a history lesson...
Ok, ok. So, what's so great about Ember? In a word: synchronization.
Objects can observe and update each other. Computed properties can be bound to one or more other properties. Element attributes in views can be bound to objects' properties. Views can manage the creation and removal of other views. Events can be bound to actions contained in views. Et cetera.
In other words, Ember keeps the components of your application in sync. You can focus on defining your application's objects and views and the relationships between them, rather than the plumbing required to maintain those relationships.
Does this lead to slow performance?
There's no doubt that Ember's synchronization code has a performance cost. But then again, so does any code you've strung together to watch events and then update data and HTML. The difference is that Ember allows you to write less code and provides a nice MVC architecture in which to write it.
Sounds good, but is it Production ReadyTM?
Yehuda Katz of the Ember core team wrote that they have worked with "several large companies, including ZenDesk, BazaarVoice and LivingSocial". Ember is also in use by the wonderful open source Travis CI project (and the code is on Github).
At Cerebris we are integrating Ember into the next generation of Syncd.
But make no mistake that Ember, not quite at its 1.0 release, is under steady development and certain parts are in flux. The documentation is coming along, but does not touch upon many useful parts of the framework. I've found it helpful to review the code and issues on Github as well as questions on StackOverflow.
What about features X, Y and Z?
I'll address these issues and more in an upcoming series of posts on Ember. While I'm cooking up my next post, please take some time to read the Ember.js home page to familiarize yourself with features such as bindings, computed properties and auto-updating templates. I'll pull these pieces together into a simple single page Rails-backed CRUD app and share the code on Github.
1/21 update: removed general use of the word "bindings", which has a specific meaning in Ember.
1/24: My next post is now available... Beginning Ember.js on Rails: Part 1.