EmberJS Confuses Me

While I actually totally agree with the confusion in the router, I want to explain what I see in Ember's MVC:<p>As far as I attempted to implement it in my app (<a href="https://github.com/thomasboyt/noted-app" rel="nofollow">https://github.com/thomasboyt/noted-app</a>), it seemed simple enough. Models were data; all they contained was their properties and operations that controlled their properties.<p>I mainly used controllers as the "state" for parts of my app. In Ember, this doesn't even need to mean it's tied to a specific model type. For example, my Dropbox integration is handled within a controller that's bound to several separate views (in this case, those views included buttons that triggered syncing and modals that displayed the progress of syncing). There's no "Dropbox model," just other models that I'm using this controller to sync. Controllers are not simply an intermediary between models and views, they are an intermediary between <i>state</i> and views.<p>&#62; I'm trying my best to reconcile this with the notion that a controller (classically speaking) is supposed to ... well control the view. Here, it's not doing that.<p>I think what the author was looking for in controllers is what's actually handled by, well, views. The view handles any user interaction, and then uses the controller to change the state of various bits (whether calling methods in the controller or simply updating properties on it).<p>To sum up: model is data, controller is state (including instance(s) of models), and the view is user interaction. Templates can bind to properties on any of these. Routes are what hook these components together depending on the page.

&#62; When talking routes, urls, and resources - that's a RESTful consideration and involves stateless state "stuff" (sidestepping the REST debate here). What is this concept doing in a desktop app?.<p>Ember is explicitly not about "desktop apps". That's actually why Ember broke off from Sproutcore. Ember is very opinionatedly focused on building web applications that are native to the web and stick to web conventions.<p>The best web applications still behave like the web is supposed to behave: they have shareable, bookmarkable URLs that allow the application's state to be recreated. This is a big reason Ember's router is different than the other examples you mentioned -- in Ember the router automatically handles a lot more of the state reconstruction stuff.

I come from Backbonejs background with which I have worked for about 1.5 years. So I feel quite comfortable with it.<p>I decided to try Emberjs - not for any other reason than trying to pick up something else and see how other JS framework approaches.<p>I gave full two-days worth of time into it. Initially I thought - "How different can it get?" Plus, I believe even if it's very foreign I'll just keep reading, googling, stackoverflowin', youtube-tutorialin' to get my head around.<p>I gave up though. Here's my <i>hopefully constructive</i> rant, though my views are probably not as deep as the OP's.<p>* Many of the posts on the net are outdated. I followed a few tutorials here and there, and then things didn't work, so I asked on Stackoverflow, then the answer I got was "Dude, your code is outdated". Sure this is probably similar thing for other frameworks - but I'm just sayin'<p>* Models - So there is Ember Object, which you can use as models, but you can also use Ember-data.js which is more "glorified" data. Documentation wasn't clear on the difference. Plus, Ember-data.js was quite hard to get started with. It didn't work well with other versions of Emberjs. I really had to dig in to find the right one to start off with. I ended up cloning a github repo of a tutorial that worked, because nothing else did.<p>* Documentation on "convention over configuration" - OK, so convention over conf. is fine. But the official documentation and many of the tutorials didn't explain what all the conventions there were. I went through a tutorial app, which only had Controller, but things just "worked", because the Emberjs builds all other things for you. Well I didn't know that! THE BEST INTRO EMBERJS VIDEO I found was this.<p><a href="http://toranbillups.com/blog/" rel="nofollow">http://toranbillups.com/blog/</a><p>It finally made sense in the end for me.<p>* But in the end, among all other things I wanted to do, I gave up, because the frustration was mounting up. I guess I can still persist through it. But I just finished AngularJS tutorial demo and in 2 hours, it makes sense to me.

I've never used EmberJS and am not familiar with any of the front-end JavaScript frameworks, but I don't get what's confusing.<p>It looks like instead of the controller pushing data to the view, the view asks the controller for data (which it might proxy to the model).<p>This makes sense with a long-running controller, right? On the web both the controller and view are ephemeral -- they last for just that one request -- but if the controller is running continuously then it needs to reflect changes in the models as they happen. The model(s) the controller references can change without the view changing its reference to the controller.<p>Without something like this the view would render stale data. I'm assuming this is why we have a controller.model, to add that layer of indirection.<p>What am I missing? How is this more complicated making the controller&#60;-&#62;view relationship pull instead of push?

&#62; The downside to this approach is that your HTML is "compromised", if you will, and many developers don't like that. My thought is that it's already compromised using Handlebars so what's the difference here? Personally I have no issue using the ng-* directives. Some people do, and I respect that.<p>I'm a bit off-topic, but you don't <i>need</i> to "compromise" your HTML with AngularJS, you can place "data-" in front of your attributes and you're HTML-compliant again :).

Really nice constructive writeup (as always by Rob), and I think it should be addressed by some better EmberJS docs and tutorials. They do a good job explaining the "what", but it could probably use more "why".<p>It took me a while as well to figure out why controllers proxied to models. However it started to make a lot of sense in when building an app, since the controllers are there to stay around, and the models are swappable.<p>Having the option to easily swap out a model at the controller level is worth the extra layer abstraction. That and the ability to add additional UI specific properties on the controller that don't necessarily belong in the model (since they don't need to be persisted).

I think the problem is MVC itself is a confused mess. It means whatever each person wants it to mean, since it's too easy to make up a bunch of reasonable sounding argumentation for whatever you want to do if you use the words model, view, and controller a lot.

In the past I've been working on enterprise application suites for the desktop. The kind of monstrous applications that run on electronics manufacturing floors. Such a typical application has a shell, modules, inter-module communication, dynamic module loading, plugins, and much much more.<p>One can think of it as Eclipse with its ecosystem.<p>To build such a system on the Enterprise with its typical NIH (not invented here) paranoid attitude was VERY hard.<p>I had to reinvent a lot of wheels.<p>On the Web, I've used backbone for a long time now, since almost the time it was out. I saw the same problems building complex applications with it (that backbone-marionette amends to a great deal). For a larger project, I evaluated Angular. Had very strong negative feelings about it.<p>Then I tried Ember. It took me a long time to "get" it. The only thing that kept me motivated is knowing that Yehuda, Tom and Trek and other capable people are contributing on it. I kept fighting through the outdated tutorials, the outdated videos, and even the peepcode video was embarrassingly confusing to me at some point.<p>But then it hit me. Ember and its infrastructure, the way its MVC is rigged, was very similar to what I was building from scratch on the desktop many years ago. It truly IS the one framework that "gets" desktop, or client-side, applications.<p>The causer of my confusion was that I didn't completely let go of the "Web-think" for building application. I was stuck at either server-side MVC (MVP), or bare-bones frameworks such as Backbone.<p>It's been just too long out of the real complex desktop game for me, to realize what that I'm looking at is a proper MVC framework.<p>So for me, Ember ended up as being great - it still takes me back to the way I was building desktop applications, and I'm sure it will become even better and better. To understand it, you need to cold-boot your thoughts into that classic desktop MVC place; and if you were never in it, I think Ember is an excellent way to get into it as opposed to other frameworks.

Curious for yourself? Try following my simple starter app tutorial of Rails + Ember.js here: <a href="http://www.devmynd.com/blog/2013-3-rails-ember-js" rel="nofollow">http://www.devmynd.com/blog/2013-3-rails-ember-js</a><p>Though, I understand the pain of coming from a server-side MVC architecture, I found it refreshing that Ember.js takes the "desktop" MVC approach. Our web apps are now living on the client, acting like desktop apps. Most people struggle with this reverse at first, but can conceptually catch on if shown the way. I think what really needs to happen is a good screencast or two walking through these concepts. I'm interested in putting something together and will when I have the time.

I tried Emberjs and Angularjs recently, as both framework offered two-way binding between view &#38; model, at client side.<p>Angularjs was easy to pickup and I have completed what I wanted to do in about half a day, except one issue, angularjs template rendering is DOM driven. I wanted server-side templates, hence I have to boot phantomjs at server-side. I didn't quite like booting phantomjs for server-side templates.<p>Since Emberjs offered, handlebar based templates, I was happy that I could render my templates at server-side. So tried emberjs, it took about 3 days, to get it done. Many out dated tutorials &#38; documents spread across internet about older versions of Emberjs. Documentation at emberjs.com is minimal and not helpful. I started looking at source code of discourse.org and try to understand how they used ember. I felt the power of emberjs when I needed complete control of context and rendering of nested templates. It was real beauty.

I'm by no means an "expert" but I shared the same struggles and after 2 weeks of trying to build a complex app I gave up.<p>I switched to Angular (which I also had never used before) and got the same app up and running in a couple days with even more functionality because I was able to hash lots of the trickier "outside-the-box" functionality that I could not for the life of me get working in Ember.<p>That being said I really like Ember's syntax, Handlebars integration, core values (performance &#38; stability specifically) and have the utmost respect for its creators. I'm hoping since it hit 1.0 that lots of new sample apps, blog posts and SO-type Q&#38;A resources will start showing up and actually stay relevant for more than a month.

Think of Ember controllers as proxies, or pointers if you will.<p>The idea is you can have a commentsController instance, and when you switch to a different post, the view(s) bound to it will automatically pick up the new comments array that is swapped out on behind the controller.<p>Routing is just rewiring the pointers on your controllers and getting the right views up on the page.

Take a look at Yehuda's talk from Seattle: <a href="http://www.youtube.com/watch?v=4Ed_o3_59ME" rel="nofollow">http://www.youtube.com/watch?v=4Ed_o3_59ME</a> - I think it explains a few things very well, and helped me out a ton

Yes, I too agree EmberJS always a confusing library, Following are my resaons.<p>1)They say it follows MVC. Its actually MVC but MVP, if you look closely at the implementation.<p>2)Controller job is not precisely defined. Example: Even the data validations are done at controller level not a model level<p>So i switched to Backbone.js, which is very flexible library with tons of plugins that can be used when needed.<p>Since implementation of UI is different from requirement to another requirement. I feel EmberJS doesn't satisfy this, which leads to people using Backbone.js.<p>Regarding AngularJS, please use it only if you are new javascript and prefer learning Angular Javascript (which is not javascript by the way) :)

i've been using ember for the past three months in a fairly complex project and i'm very happy with it ; a platform that builds business web apps dynamically for devices (20+ pages,250+ fields per app with validations, calculated fields, conditional flows etc , rendering/theming in jqm -&#62; packaged with phonegap) and client web browsers (render/theme in bootstrap),the backend is in java. So, i certainly don't feel the same way for emberjs as the writer.<p>I had decided to build the frontend in a js mvc framework and the candidates were backbone, emberjs (pre version), angularjs. Read about them and gave backbone a try, however from the documentation only emberjs approach felt better maybe because of a similar in-house development java framework that we work on. So i tried to give emberjs a try at the same time, due to the tight deadlines. I dropped backbone, and spent more time on emberjs because everything simply worked and fitted together nicely. All these binding mechanisms are great and actually work :) . Haven't tried angularjs.<p>The system now works with emberjs (pre and rc) with a nice layered architecture and separate independent business logic modules.<p>My advice is to read the documentation carefully and choose what fits better to your needs and coding styles.

Your examples are incorrect. The Route's model is set as the content of the controller, so all you need to say is #each item in content. Your model is set as the "content" of your controller, so your model is not "nowhere to be found"

The examples provided to describe the difference between controllers in Ember and Angular do not appear to be different to me at all. In fact I'd argue that they are identical. It feels to me as though the author is wanting them to be different because maybe it's a style preference from the templating perspective?

Here's the Google cache: <a href="http://webcache.googleusercontent.com/search?hl=en&#38;biw=1256&#38;bih=787&#38;sclient=psy-ab&#38;q=cache%3Ahttp%3A%2F%2Fwekeroad.com%2F2013%2F03%2F06%2Fember-confuses-me&#38;oq=cache%3Ahttp%3A%2F%2Fwekeroad.com%2F2013%2F03%2F06%2Fember-confuses-me&#38;gs_l=hp.3...9193.10065.1.10319.6.6.0.0.0.0.70.287.5.5.0.les%3B..0.1...1c.1.5.psy-ab.Z1SKTeDnL-M&#38;pbx=1" rel="nofollow">http://webcache.googleusercontent.com/search?hl=en&#38;biw=1...</a><p>text-only: <a href="http://webcache.googleusercontent.com/search?q=cache:http://wekeroad.com/2013/03/06/ember-confuses-me&#38;hl=en&#38;biw=1256&#38;bih=787&#38;strip=1" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:http://...</a>

Seems like the big confusion about the controller is that it is closer to a ViewModel (think MVVM) than to a Controller itself.<p>Potatos, Potahtos.

Watching the peep code screen cast helped a lot

We have applied EmberJS to a fairly complex application backed by Rails backend. We had to deal with complex JSONs delivered by backend which were schemaless MongoDB documents. At lot many places we had non RESTful Rails controllers. So when we started with EmberJS we had a worry the documentation was not proper, there were very few reference projects. After a few weeks of thrill and steep learning we settled on with things. We have applied a lot of functionalities offered by Ember to our code. Migrated from router from old to new api of pre 4. But we feel in our team it was right thing to apply Ember. The way overall MVC imposes structured programming, the way HTML is seperated from JS, the way ember data can have serializer and adapter customized, two way bindings all of it had been useful. We struggled at few places with deep nested JSONs in hasMany/belongsTo relation in embedded JSONs. But doing workarounds were easy. We used fixtures to hasten development while backend was not yet ready. All in all we believe that we made a good choice to stick with Ember, though it looks difficult to comprehend on the start but thats also getting better with time.

I'm confused by all of these MVetc... libraries. We had routing behavior to content/views covered already. How is anything that does more than help isolate/manage data more than cruft in regards to having some sort of MVC-but-not-really-style-app on the client-side-web? IMO, it's all just pointless abstraction of the type that JS devs should have learned to avoid from observing server-side fail over the years. What really blows my mind is the number of these frameworks that embed pointless behavior dependencies directly in the HTML and act like they're doing us a favor. That's awesome, now we're back to changing things in multiple places to make adjustments to our apps that used to happen in one place following basic "duh" best practices that the authors of these frameworks don't appear to have ever understood properly. HTML is the router you saps! Hell, how about we add pointless-in-a-language-with-first-class-function IOC fail, config files and pointless dependency management as well? Wait WHAT!? ARE YOU !@#$ING SERIOUS!?

I think the way controllers work here is similar to Ruby on Rails? It confused me in Rails at first (coming from the Java world), but I think it is essentially just a hack to allow for "easier" passing of data to the view (the controller gets exposed to the view). So instead of scope.whatever = "hello world" you can write this.whatever = "hello world" (OK not really shorter, but something like that).<p>That usage of Controllers is not part of the MVC pattern, I'd say. It's just a recycling of the controller instance - not forbidden, just confusing if you wonder what it has to do with MVC.<p>Actually it's also the RoR way to have short lived controllers (a controller is instantiated for every request), other frameworks use one static controller instance instead.

The Angular example is a bit incorrect... when you do an ng-repeat, you're going to do like ng-repeat="person in people" and then each template item will be like {{person.name}} as opposed to just {{name}}.<p>Just a little clarity in the code. Thanks for the writeup!

&#62; Ember is explicitly not about "desktop apps". That's actually why Ember broke off from Sproutcore. Ember is very opinionatedly focused on building web applications that are native to the web and stick to web conventions.<p>This may be the issue. I think most of us never really wanted to build web applications, but we were forced to do so due to browser and framework limitations.<p>We really just wanted to build the best damn desktop app possible that just happened to be deployed in a browser via the Web. This might explain our confusion and disappointment when client side frameworks don't deliver on that desire.

Instead of controlling the view directly from the controller, the view uses the controller object (proxy to model) in any way it wants allowing you to change the view without changing the controller and same with the controller. I think the issue you are facing is thinking that you are tightly coupled to the controller by using the controller object, depending on what you think about how much coupling is too much coupling you can argue that just using one object might really be decoupling. I'm not sure if I was able to get my point across.

Well, I don't know EmberJS but for the handlebars code you showed, seems like the controller is somewhat more like a ViewModel (MVVM pattern), maybe learning KnockoutJS first would help a bit?

Although really old (and outdated) I found this Sprout Core introduction useful. The first 3-4 minutes was enlightening for me.<p><a href="http://vimeo.com/24487742" rel="nofollow">http://vimeo.com/24487742</a>

I have been into MVC frameworks for 4-5 months now...mostly used BackBoneJS before switching to EmberJS..conceptually I did felt EmberJS very tough in the beginning..i was worried whether i made the right choice in using EmberJS for my product..but now with the latest 1.0rc2, its so easy in development..routing has been improved very much..Binding is the awesome feature i liked and helps me thgh..an added advantage over BackBone...i cant say about angular..but am quiet happy with EmberJS...

Until tomorrow there is a 37% discount on the MEAP <a href="http://www.manning.com/skeie/" rel="nofollow">http://www.manning.com/skeie/</a> The discount code is m137

Ember confuses me too. I've worked with many server and desktop MVC frameworks for almost 20 years. I'm familiar with MVC, it plays simple and easy, like rock-paper-scissors. My problem with Ember is that it seems to be more like "rock-paper-scissors-lizard-spock but for us the rock punches through the paper and the scissors cut the rock like butter. And you can play without actually showing your hand". Confusing.

At first read, I thought your point about routing was really good - why not have route('about').template('aboutTemplate').controller('aboutController') - and then I realized this is all reapeating the same mumbo jumbo. This is all automatically matched up by the naming convention (which frustrates me too, but until I figure out a better way...)

The only reason is you are in love with AngularJS. I will find someone who really hates angularJS because if we have a lot of validation, it will become a messy of ng-*.<p>So no matter which framework we use, we should talk about real world project. Not simple usage that only exists in trying and testing.<p>Use the framework, you love and you will make it beautiful no matter what :D

Wonder how many iOS developers feel home with Ember? I don't. I also do Rails, and I feel more at home with Batman than Ember.

Don't give up! Ember has a steep learning curve but once you've got a bunch of it memorized development gets much easier.

I have not used Ember, but you mention MVC, which immediately brings to mind Sencha. I have used Sencha a lot, and although I think it is mostly great, I do not like how they try to pidgeon-hole you into the MVC methodology, which just does not make sense in many contexts.

&#62; I think Yehuda is a very nice and smart person<p>I always get confused by this. I don't understand how being nice factors into technical decisions?<p>(For the record, I also think wycats is nice, but I don't really care when I'm trying to decide whether or not what he's saying makes sense)

I just think the basic idea is to keep things as separate as possible, to keep complexity down. Just encapsulate things OOP-like, hide the guts, and provide a clean access API to them. That makes it manageable.

+1. you hit the nail on the head and articulated what I was feeling when I played with ember.

Thanks for sharing this Rob, it was actually very informative about Ember to a newbie!

You are not alone.

The whole point of EmberJS confuses me.