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.
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.
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 framework. Angular 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?
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.