Warming up to Ember.js
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.
It's important to remember that any client-side framework is simply constructing javascript and HTML, and that abstractions should be used judiciously. That's why I really appreciate Ember's default use of Handlebars templates, which allow you to mix in as much straight HTML as you like. Ember's magic can be used only where needed.
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?
We initially had reservations about using Ember because it lacked several features included in other Javascript MVC frameworks, like a RESTful persistence layer and client-side routing. However, there are now solutions for these and other problems being developed both within and outside the official Ember project.
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.