Ember is not a Rails killer
Over the last few days, I’ve been working with Ember.js in order to make a JS and HTML5 app to wrap with phoneGap. Though it’s a very powerful little framework, I’m already coming up against its limitations, so I thought I’d put some initial impressions down here. If you’re creating a relatively static site with some dynamic elements, Ember is a joy to use. I re-built the label site in an afternoon, including the time spent to populate fixture data, and it was a breeze. Things like implicit controller creation meant that all I had to do was define my routes and models, and then I could dynamically populate the data into handlebars templates. Sweet.
In theory, it should then be trivial to swap out the app adaptor from the FixturesAdapter to the RESTAdapter using the ember-data library; I suspect it is. The problem is more that at present, the documentation is somewhat scarce. To be fair, the docs are better than they’ve ever been, but a cursory glance at SO searches suggests that plenty of veteran web devs are pretty befuddled by some aspects of the framework. Even if you’re used to using a lot of AJAX, Ember is a little different. AJAX is allowing you to not reload the page, but you’re still doing a roundtrip to the server. In trying to cache and serve content from the store object, Ember is introducing an extra level of abstraction. This is good, but it’s also confusing if you’re trying to hook it up to a REST API. Ember routes roughly follow the same conventions as Rails (which shouldn’t be surprising given the presence of heads like Yehuda Katz on Ember core), but when it comes to doing complex tasks that aren’t simple GET requests (authentication, dynamic routing against the API), quickly you start wondering whether you’re getting it wrong.
Even creating a form to post back to the API isn’t straightforward. One post from pivotal takes what appears to be a more canonical Ember approach, while a more recent Openshift blog takes a completely different approach, handing off the data binding entirely to jQuery scripting in the controller. To be sure, this is the Wild West compared to Rails; dynamic data binding results in this fantastic SO question where, much to the horror of us server-side app engineers, we are reminded that because the app is purely client-side, the models are being continually updated, meaning that form entries persist even if the ‘back’ button is hit.
So, if you’re already within a Rails app, frankly it probably makes more sense to use standard AJAX calls or UJS to accomplish most of the user-interactive things that you might want to use a JS framework for. That said, if you’re planning on moving to a SOA approach, or you have several high-use areas of your application, then Ember might be what you’re looking for. In our case, despite its quite steep learning curve, it is definitely the tool for the job, and I look forward to deploying several mini apps in our main Rails application. As for the hyperbole surrounding the framework? It’s fantastic, yes, but it’s also clear that many tasks will still be better served by a server submit/page reload in most cases… at least for now.
Alex Lynham
Notes on working for a startup in Manchester and various other projects.
alex@lynh.am
