EmberJS and Confusion, Part 2

Since writing my “EmberJS Confuses Me" post (on my blog) I’ve had some interesting feedback. Many are confused, as I am. Others think I’m a troll. Either way I’ve kept on looking at Ember and here’s where I’m at with it now…


MVC has many different flavors. FrontController vs. PageController for one, server/web approach vs. desktop, Smalltalk-80 style vs. Cocoa etc. 

Ember has adopted a Cocoa/iPhone way of doing things (according to Trek) so I decided to have a deeper look at this to see if it makes me feel less confused and I have to say, I think it helped.


Having read over the Cocoa docs that Trek linked to - I begin to understand the Ember team’s approach. Knowing what little I do of Objective-C and iPhone development (I’ve dabbled)… the terminology of the project and the way of doing things resolved a bit.

Reading the Ember guides after reading the Cocoa stuff also helped:

We want developers to be able to build ambitiously large web applications that are competitive with native apps. To do that, they need both sophisticated tools and the right vocabulary of concepts to help them communicate and collaborate.

Inspired by Cocoa, competing with native apps. Basically porting the iPhone development experience to Javascript:

Interesting choice.

Conceptual Banquet

Javascript programming is … an interesting affair. There’s definitely a hill to climb before you figure out ways to not hurt yourself (and even then…).

Layering in Client MVC/Single Page Apps can increase the difficulty 10-fold. Anyone who’s tried to pick up Backbone can attest to this - it’s such a simple framework but the abstraction is so little that you still fall into the traps presented by the DOM/Javascript/Evented Programming.

Angular, from what I’ve learned, abstracts much of this away (but not all) and the main concepts you need to know are Dependency Injection and UI binding a la Windows Forms.

Ember’s use of the Cocoa/iOS/Xcode is an interesting one. I can see the similarities now - right down to the term “outlet” which I assume is a reference to Interface Builder’s IBOutlet

If we have outlets and Cocoa-inspired Controllers - are we also using the UIView concept?

In reading Ember’s documentation on the matter - it seems to be quite similar to the UIView. Here’s Ember’s description:

The role of the view in an Ember.js application is to translate primitive browser events into events that have meaning to your application.

The UIView in Cocoa does a bit more:

The UIView class defines a rectangular area on the screen and the interfaces for managing the content in that area. At runtime, a view object handles the rendering of any content in its area and also handles any interactions with that content.

This clears things up quite a bit for me… but I’m not sure I feel any less confused (if that makes any sense).

Does The Abstraction Fit?

Conceptually I can see why this is an interesting approach - do what’s been done before and adapt it to JS/HTML.

Pragmatically I’m left wondering if the abstraction fits. MVVM/MVP (used with Silverlight/WPF apps) has been reused with Knockout and Angular to reasonable effect - but the abstraction doesn’t fit in either of those frameworks.

Backbone developers will tell you that Backbone is not an MVC frameworkAngular developers will also squirm a bit when discussing the differences in MVC/MVVM with Angular. Knockout creator Steven Sanderson said to me once:

Perhaps we should call Knockout an VVM framework as we don’t really have a model involved, do we?

It’s Javascript, the DOM, and evented programming at the end of the day and no matter which framework you use, you’ll need to know the bits that underly it.

Which is the very definition of Leaky Abstraction. Which is OK - no abstraction is perfect and given that I have to ask: how much should these frameworks try to fit a conceptual model that has nothing to do with the web?

I can’t answer that. I haven’t tried building something with Ember but now that I have the conceptual approach a bit more resolved, I feel like I know now how to use the framework.

The big question to me is how much do I need to understand Cocoa/iOS to be effective with Ember? Moreover will using this approach even make sense to me when working with the web?

I guess we’ll find out.