

Getting Started with Ember.js - mahmoudimus
http://blog.balancedpayments.com/getting-started-with-ember.js/

======
mjallday
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
Oh god yeah. It really sucks. This is going to be a pain with anything async
right now though.

~~~
mjallday
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
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.

------
ulisesrmzroche
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
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
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-c...](http://emberjs.com/guides/controllers/dependencies-between-
controllers/)

------
endemic
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
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
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
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
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.

~~~
mark_l_watson
I have experimented a lot with Ember.js but not used it for any serious
projects. It took a while getting a grip on Ember-data. I don't know if this
will help anyone but I took the example (front end only) code from "The Source
for the Ember Get Excited Video", forked it on github, and added a trivial
Ruby Sinatra REST service. It seems to work, but if you see any errors please
let me know: [https://github.com/mark-watson/bloggr-
client](https://github.com/mark-watson/bloggr-client)

~~~
ulisesrmzroche
I can give this a code-review later tonight. I'll contact you on github.

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

~~~
mahmoudimus
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
Did you look into the frameworks built on top of Backbone like Marionette?

~~~
slap_shot
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.

------
Kiro
"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
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.

