5 ms·

Getting Started with Ember.js

75 points by mahmoudimus 13y ago

ulisesrmzroche 13y ago
In Ember.js, templates get their properties from controllers, which decorate a model. On Controllers: Controllers are used to decorate your models with display logic, not to handle business logic. Models have properties that are saved to the server, so they should be responsible for that. On Views: Views should be used to create reusable components or for sophisticated handling of user events. For the most part, Handlebars should get you 90% of the way. You shouldn't be making too many views in Ember.
- kleinsch 13y ago
  All good points. I think one of the toughest parts with Ember is that there are a lot of places to put things, so it's sometimes hard to figure out the _right_ place to put things. I'm always looking to learn from people that know more. :) We're putting as much business logic in models as possible, but are finding there are times when we need something more similar to a traditional MVC controller to coordinate actions. Handling things like form validation and coordinating multiple models doesn't seem to fit nicely in the models. How have you handled those type of situations?
  - ulisesrmzroche 13y ago
    When someone submits a form with invalid data, and the server marked it as such, the record in the transaction will have the isValid flag set to false . Your controller then acts as a proxy between the model and the template. Because controllers are long-lived, the content of that controller will contain the invalid record. Now your template can have a {{#unless isValid}} and you display whatever error message there. The user keeps interacting with the form, and every time the submit button is pressed, the cycle repeats again until the record is valid, for example. The thing is that it is the model that has the to be responsible for persistence, so it is the one that marks the record as invalid. The controller would handle decorating the template, (show the error message). Now if you want to do client-side validation, you'd write a view (which really should be called component in my opinion) which would handle that logic. Notice that for the last example, all we used were templates. The view only came into play when more complicated handling of events is made (client side validation). To coordinate multiple models, you can use controller.needs (which calls another controller into play, letting you access its model and use stuff like nested resources much cleaner). http://emberjs.com/guides/controllers/dependencies-between-controllers/ http://emberjs.com/guides/controllers/dependencies-between-c...
- mahmoudimus 13y ago
  Hey ulisesrmzroche, You seem to possess good knowledge with Ember and its inner workings, how can I get in touch? You can get in touch with me through my profile.
  - ulisesrmzroche 13y ago
    My email is ulisesrmzroche@gmail.com. I'll shoot you an email. Thanks!
thatmarvin 13y ago
Why Ember.js, and what other frameworks did you guys evaluate?
- mjallday 13y ago
  We primarily looked at Backbone, Angular, and Ember. It was hard to choose but Ember has a great community and is reasonably straight forward so it got our vote.
- mahmoudimus 13y ago
  Happy to go into more details about the choices between Backbone, Angular, and Ember. It ultimately boiled down to the community and readability (I personally thought Angular templates were a bit harder to read). Regarding Backbone, I had used it before and I felt that I had to write a lot of boilerplate as the application grew, which is exactly what something like Ember was designed to prevent.
  - natmaster 13y ago
    Did you look into the frameworks built on top of Backbone like Marionette?
    - slap_shot 13y ago
      Or Chaplin: https://github.com/chaplinjs/chaplin https://github.com/chaplinjs/chaplin I honestly don't think either of them do a good job of promoting their absolutely awesome work. I tell everyone I can about them, but they really need some presence at conferences or some big companies releasing case studies.
mjallday 13y ago
To give Ember some criticism, we're struggling with debugging at the moment: The main issue https://github.com/emberjs/ember.js/issues/2817 https://github.com/emberjs/ember.js/issues/2817 is that the run loop in Ember disassociates the invoking action from the event handler which makes figuring out what fired what a PITA. That and the stacktraces are useless makes hunting down bugs often more difficult than it should be. I don't know how this contrasts with other JS frameworks but we definitely feel the pain with this issue.
- ulisesrmzroche 13y ago
  Oh god yeah. It really sucks. This is going to be a pain with anything async right now though.
  - mjallday 13y ago
    I assume there's a way to add context information into the run loop when firing events for debugging purposes. This would largely solve the first half of the issue (who fired the event). The second half, where the error happened, seems like it's just a bug in the way Ember is recording errors.
    - ulisesrmzroche 13y ago
      This I'm not too sure about. I know they're moving this to https://github.com/ebryn/backburner.js https://github.com/ebryn/backburner.js. I'll read through the code sometime tonight and figure out what's going on.
- MetaCosm 13y ago
  I really wish more articles about frameworks were about the ugly bits. If you do exactly what the framework expects and never go off the reservation, they all are fairly decent. What I want to always know about is what happens in the framework when stuff goes bad. "When frameworks go bad, your guide to life after the honeymoon period"... I would read that.
Kiro 13y ago
"We wanted to build our dashboard in JavaScript to separate the both front-end and back-end development as well as leverage the power of Balanced’s RESTful API." Does this mean they have a back-end layer before the REST API or is the front-end communicating with the API directly?
- mjallday 13y ago
  Hi Kiro, We wrote a simple Python back-end service that stores authentication information -- if you think of the dashboard as a rich client, it needs some way to persist some items that are unrelated to the API such as email address and password login credentials, so that's what this simple service does. However, Balanced's API has CORS-support enabled, so we can make API calls to the API from the Ember app directly (no need to proxy through a back-end service). This will reduce latency to the user to give a perceived feeling of responsiveness once implemented. Interestingly, simply implementing the dashboard as an AJAX app and having the requests fire in parallel as opposed to serially with our existing dashboard has already given a massive performance boost.
endemic 13y ago
I ran into the same issue the author describes, RE: getting Ember to work with a non-Rails-style REST API. After spending quite a bit of time trying to figure out Ember Data, I reverted to Backbone, since it's dead simple to link a model with any API endpoint. All in all, a pretty frustrating experience.
- mjallday 13y ago
  Absolutely, there's a nice looking project for Ember called ember-model (https://github.com/ebryn/ember-model https://github.com/ebryn/ember-model) which looks promising for addressing this shortcoming.
  - ulisesrmzroche 13y ago
    The main goal in that project is to provide primitives on top of $.ajax that are required by ember. Key thing to keep in mind is that it's just $.ajax under the covers.
    - mjallday 13y ago
      It looks like most of the complexity in ember-data is to do with transaction management and references. We decided to forgo both of those and haven't really lost anything because of that. It's opinionated way of dictating your JSON payload etc was also a factor in the decision to drop it. If you use RoR as a backend it's a perfect tho I assume.
      - ulisesrmzroche 13y ago
        Yup. It's about making sure that the data layer and the view layer are in sync. That's where it gets hard. Other than that, it's just $.ajax. ebryn's project is the wrapper so you can plug into that stuff. What you're losing is responsiveness in the UI. You're going to have to dictate when the call is made, and some may even be blocking. For stuff like submitting a form, or navigating to a new page, that's not a big deal, right? The user has to press a submit button, or the url changes, so then you handle the event. But once you're requirements are real-time, and data-intensive, (DIRTy) then handling all these events is really going to be a nightmare and that's where ember-data is great. Lots of folks knock ember-data, but it's pretty great if you're using it for real-time data intensive applications, which is really what this is made for.

75 points by mahmoudimus 13y ago

In Ember.js, templates get their properties from controllers, which decorate a model. On Controllers: Controllers are used to decorate your models with display logic, not to handle business logic. Models have properties that are saved to the server, so they should be responsible for that. On Views: Views should be used to create reusable components or for sophisticated handling of user events. For the most part, Handlebars should get you 90% of the way. You shouldn't be making too many views in Ember.

kleinsch 13y ago
All good points. I think one of the toughest parts with Ember is that there are a lot of places to put things, so it's sometimes hard to figure out the _right_ place to put things. I'm always looking to learn from people that know more. :) We're putting as much business logic in models as possible, but are finding there are times when we need something more similar to a traditional MVC controller to coordinate actions. Handling things like form validation and coordinating multiple models doesn't seem to fit nicely in the models. How have you handled those type of situations?
- ulisesrmzroche 13y ago
  When someone submits a form with invalid data, and the server marked it as such, the record in the transaction will have the isValid flag set to false . Your controller then acts as a proxy between the model and the template. Because controllers are long-lived, the content of that controller will contain the invalid record. Now your template can have a {{#unless isValid}} and you display whatever error message there. The user keeps interacting with the form, and every time the submit button is pressed, the cycle repeats again until the record is valid, for example. The thing is that it is the model that has the to be responsible for persistence, so it is the one that marks the record as invalid. The controller would handle decorating the template, (show the error message). Now if you want to do client-side validation, you'd write a view (which really should be called component in my opinion) which would handle that logic. Notice that for the last example, all we used were templates. The view only came into play when more complicated handling of events is made (client side validation). To coordinate multiple models, you can use controller.needs (which calls another controller into play, letting you access its model and use stuff like nested resources much cleaner). http://emberjs.com/guides/controllers/dependencies-between-controllers/ http://emberjs.com/guides/controllers/dependencies-between-c...
mahmoudimus 13y ago
Hey ulisesrmzroche, You seem to possess good knowledge with Ember and its inner workings, how can I get in touch? You can get in touch with me through my profile.
- ulisesrmzroche 13y ago
  My email is ulisesrmzroche@gmail.com. I'll shoot you an email. Thanks!

thatmarvin 13y ago

Why Ember.js, and what other frameworks did you guys evaluate?

mjallday 13y ago
We primarily looked at Backbone, Angular, and Ember. It was hard to choose but Ember has a great community and is reasonably straight forward so it got our vote.
mahmoudimus 13y ago
Happy to go into more details about the choices between Backbone, Angular, and Ember. It ultimately boiled down to the community and readability (I personally thought Angular templates were a bit harder to read). Regarding Backbone, I had used it before and I felt that I had to write a lot of boilerplate as the application grew, which is exactly what something like Ember was designed to prevent.
- natmaster 13y ago
  Did you look into the frameworks built on top of Backbone like Marionette?
  - slap_shot 13y ago
    Or Chaplin: https://github.com/chaplinjs/chaplin https://github.com/chaplinjs/chaplin I honestly don't think either of them do a good job of promoting their absolutely awesome work. I tell everyone I can about them, but they really need some presence at conferences or some big companies releasing case studies.

mjallday 13y ago

To give Ember some criticism, we're struggling with debugging at the moment: The main issue https://github.com/emberjs/ember.js/issues/2817 https://github.com/emberjs/ember.js/issues/2817 is that the run loop in Ember disassociates the invoking action from the event handler which makes figuring out what fired what a PITA. That and the stacktraces are useless makes hunting down bugs often more difficult than it should be. I don't know how this contrasts with other JS frameworks but we definitely feel the pain with this issue.

ulisesrmzroche 13y ago
Oh god yeah. It really sucks. This is going to be a pain with anything async right now though.
- mjallday 13y ago
  I assume there's a way to add context information into the run loop when firing events for debugging purposes. This would largely solve the first half of the issue (who fired the event). The second half, where the error happened, seems like it's just a bug in the way Ember is recording errors.
  - ulisesrmzroche 13y ago
    This I'm not too sure about. I know they're moving this to https://github.com/ebryn/backburner.js https://github.com/ebryn/backburner.js. I'll read through the code sometime tonight and figure out what's going on.
MetaCosm 13y ago
I really wish more articles about frameworks were about the ugly bits. If you do exactly what the framework expects and never go off the reservation, they all are fairly decent. What I want to always know about is what happens in the framework when stuff goes bad. "When frameworks go bad, your guide to life after the honeymoon period"... I would read that.

Kiro 13y ago

"We wanted to build our dashboard in JavaScript to separate the both front-end and back-end development as well as leverage the power of Balanced’s RESTful API." Does this mean they have a back-end layer before the REST API or is the front-end communicating with the API directly?

mjallday 13y ago
Hi Kiro, We wrote a simple Python back-end service that stores authentication information -- if you think of the dashboard as a rich client, it needs some way to persist some items that are unrelated to the API such as email address and password login credentials, so that's what this simple service does. However, Balanced's API has CORS-support enabled, so we can make API calls to the API from the Ember app directly (no need to proxy through a back-end service). This will reduce latency to the user to give a perceived feeling of responsiveness once implemented. Interestingly, simply implementing the dashboard as an AJAX app and having the requests fire in parallel as opposed to serially with our existing dashboard has already given a massive performance boost.

endemic 13y ago

I ran into the same issue the author describes, RE: getting Ember to work with a non-Rails-style REST API. After spending quite a bit of time trying to figure out Ember Data, I reverted to Backbone, since it's dead simple to link a model with any API endpoint. All in all, a pretty frustrating experience.

mjallday 13y ago
Absolutely, there's a nice looking project for Ember called ember-model (https://github.com/ebryn/ember-model https://github.com/ebryn/ember-model) which looks promising for addressing this shortcoming.
- ulisesrmzroche 13y ago
  The main goal in that project is to provide primitives on top of $.ajax that are required by ember. Key thing to keep in mind is that it's just $.ajax under the covers.
  - mjallday 13y ago
    It looks like most of the complexity in ember-data is to do with transaction management and references. We decided to forgo both of those and haven't really lost anything because of that. It's opinionated way of dictating your JSON payload etc was also a factor in the decision to drop it. If you use RoR as a backend it's a perfect tho I assume.
    - ulisesrmzroche 13y ago
      Yup. It's about making sure that the data layer and the view layer are in sync. That's where it gets hard. Other than that, it's just $.ajax. ebryn's project is the wrapper so you can plug into that stuff. What you're losing is responsiveness in the UI. You're going to have to dictate when the call is made, and some may even be blocking. For stuff like submitting a form, or navigating to a new page, that's not a big deal, right? The user has to press a submit button, or the url changes, so then you handle the event. But once you're requirements are real-time, and data-intensive, (DIRTy) then handling all these events is really going to be a nightmare and that's where ember-data is great. Lots of folks knock ember-data, but it's pretty great if you're using it for real-time data intensive applications, which is really what this is made for.