Saturday, May 5, 2012

A Philosophical Distinction Between Backbone And Ember

Backbone supplies a minimal set of highly effective tools which you can use in a variety of ways. Ember.js is a much larger framework.

Rails provides a very strong argument in favor of opinionated frameworks; but Rails came after more than a decade of web development, and many of its opinions evolved from streamlining extremely repetitive, extremely well-defined tasks. For instance, ActiveRecord the ORM was named after Active Record the design pattern, as defined in Martin Fowler's book on enterprise architecture.

DHH might seem like a lone genius, but he's actually extremely well-read. I picked up an obscure book on code generation (now out of print) after he recommended it on his blog and found half the ideas that make Rails great laid out in the first 20 pages.

In short, Rails was not just opinionated; its opinions were battle-tested, and not just by 37Signals, because many of these opinions came from a wide reading of some of the best literature which emerged after more than a decade of web development.

Ember.js has its own definition of Object, similar in some ways to Rails with its many extensions of core Ruby classes. Where Backbone is lightweight, Ember seems imposing.

Backbone's minimalism implies to me an opinion that single-page, complex JavaScript apps are an immature field and should be addressed with a minimal toolkit. I think people like to say Ember is more opinionated than Backbone, but I think it's important to consider this top-level opinion. Although I have no doubt at all that the Ember team is very well-read, like DHH, I believe that Ember is not streamlining battle-tested, proven techniques following after a decade of single-page, complex JS MVC apps.

Gmail debuted in 2004, so a decade of such experience will soon exist (for a relatively small number of groundbreaking engineers), but does not currently. Also, I don't think the literature has the same maturity as the literature DHH drew from when designing Rails, because it was only relatively recently that "real programmers" started taking JavaScript seriously at all.

In this regard, Backbone makes an interesting contrast to CoffeeScript. CoffeeScript clearly represents the same kind of opinionated process which shaped Rails -- picking and choosing only the best ideas, streamlining common tasks, etc. I think this is actually excellent judgement on the part of Jeremy Ashkenas, who created both CoffeeScript and Backbone. There are times when you streamline processes based on existing knowledge, and there are times when you use lightweight, highly flexible tools.

A good guideline is to only streamline processes based on existing knowledge when such knowledge exists. I strongly suspect Ember of skipping a crucial step here. However, to be fair, I have not played with Ember, and do not plan to until late May, when I'll be at Fluent Conf, and I'll have a chance to catch some sessions on Ember before jumping in. I could be surprised, and I certainly hope to be surprised.