[samratjp]

Ember Data is a heavy hard-hat area and no wonder you were frustrated. Really, just start with your own data layer and get used to Ember first. Ember has a very Rails-ish philosophy and just like in the Rails world - magic happens (but ya should know how it happens anyways). This blog post is a good intro to how Ember works - http://trek.github.com/ (though routing has come a long way since - http://emberjs.com/guides/routing/defining-your-routes/

[heyitsnick]

> Ember Data is a heavy hard-hat area and no wonder you were frustrated. Really, just start with your own data layer and get used to Ember first

So why is that? This was my big head-scratcher with Ember; surely the access to a data layer is the whole point of these javascript frameworks? I mean all backbone is really is a layer between REST and client-side javascript. I guess i'm missing a whole class of JS applications that don't need access to a server-side data layer, but for me that's the fundamental reason to be looking for a JS framework in the first place. So to come across one so highly regarded which doesn't have it baked in was very jarring.

[steveklabnik]

The idea with Ember-Data and Ember in general is the same as Rails: Conventions give you power. Conventions and a happy path are good. That said, until you _learn_ the happy path, it's harder going.

It's not 'baked in' because Ember is modular: Ember-data has all of that layer in it, so the rest of Ember doesn't have to care. That said, I disagree with your parent: you shouldn't be writing your own data layer.

[samratjp]

ah yes, you're right - meant to say that handle the serialize/de-serialize yourself at first to get your feet wet.

[securingsincity]

Thanks for the direction, I'll definitely check that out. Hopefully they have some of these baked soon, I did like a lot of the other features as advertised.