Luke Melia


August 23, 2012

Architecting Ember.js Apps

This talk was delivered to the Ember.js NYC Meetup on Wednesday, August 22nd.

9 Responses to “Architecting Ember.js Apps”

  1. Sylvain MINA chimed in:

    I Luke, first of all, you did a very good job here, thank you :)

    With my co-workers we were looking for other quite large applications, in order to see if we were doing a good work at designing our app. I think here I’ve got an answer, and it is very usefull as we realize that we are missing some points (for example, too much logic in views, manipulating directly the models).

    By the way, I have little questions/comment around this speakerdeck:

    * in slide 24, the TodosController definition may confuse beginners, as you affect an empty array to the todos array at declaration time, which could be unsafe if there are multiple instances of this controller.

    * in slide 50, you tell that two-way bindings are often uncessary, so do you think the default behavior of binding definition in ember should be one-way ?

    * in slide 52 you advice to delegate to separate state managers where possible. I don’t understand exactly what that means. Would it be possible to have an example of this ?

  2. Séverine Darlot chimed in:


    Thank you for this presentation.
    I have questions about page 9.
    What do you want to tell by “MVC is not created equal” ?
    When you tell that “controller” has many different meanings, what are the different meanings ? a model proxy ?

    Could you give me more information ?

    Thank you

  3. lukemelia chimed in:

    @Sylvain: Thanks for you kind words and comments! re 24, agreed (although it is uncommon to have multiple instances of the same controller in Ember apps). re two-way bindings, I do personally think that a oneWay default would be better, but not sure how popular that opinion is. re: separate state managers, a simple example is a separate state manager to handle modal dialogs. We also use a separate one to manage a particular sidebar in our UI. The router delegates certain events to those state managers, which handle them and thereby keep the router simpler.

    @Severine: Here’s a good page to read to learn about how “controller” is used in software engineering:

  4. Sylvain chimed in:

    Hi Luke, thanks for your explanations. Concerning the state manager delegation, you create those separate state managers as children of the router, or simply as member of the application ? Or perhaps you create the state manager when you need them, at event handling time ?

  5. lukemelia chimed in:

    @Sylvain I make the other state managers a member of the application and inject them onto the router with a registered injection. However, the other approaches you listed may be perfectly good solutions depending on your app.

  6. Aras chimed in:

    Hi, I wanted to watch this presentation — specially since it happens in future — or maybe I am living in the past :). Anyway, I wanted to ask if you could put the video on youtube or viemo becuase the link on cloudee is not working for me. The page loads but the video does not start. I tried with Firefox and chromium. Cheers!

  7. lukemelia chimed in:

    @Aras, happy to do it if I can get the source material. A volunteer took the video and posted it, so I will need to see if I can track down the video. It plays fine for me at Cloudee, incidentally. I’m on Chrome OS X.

  8. kyle chimed in:

    Hi Luke

    Thanks for this – very helpful!

    Have a question – if controllers are used to proxy data from the model and add computed properties, then how do you handle arraycontrollers?

    E.g. When iterating through an arraycontroller in a template, for each item you only have access to the model, not the controller that adds all the additional computed properties.

    Whats your approach in this situation?

  9. lukemelia chimed in:

    @kyle in recent versions of Ember, you can specify an `itemController` when you use the #each helper.

Leave a Reply created 1999. ··· Luke Melia created 1976. ··· Live With Passion!