4 ms·

I actually just had this same experience this past weekend. Hours spent banging my head against the wall trying to figure out why Ember-Data wasn't working. I d

I actually just had this same experience this past weekend. Hours spent banging my head against the wall trying to figure out why Ember-Data wasn't working. I don't know what wasn't clicking but I decided to switch to backbone for this project. Literally minutes of work to get backbone going and have my data appear properly.

tbatterii 14y ago
we use ember at the day job, and historically i've been primarily the backend guy slowly getting familiar with what the front end guys are doing. I agree that the ember-data stuff is pretty thin on docs at the moment. IIRC, it wasn't part of the original stack, but obviously everyone wants a mvc with that persistence layer. So a -1 for that, not sure if it will be a part of ember by the time it reaches 1.0 or not. (oh yeah, it's still technically beta) But ember shines in other areas that people wont care about until they have to write single page web apps with a high enough complexity that warrants it. The reason we ditched gwt for ember was the 2 way bindings. Not having to write all that stuff(and test it(in every browser))has been a productivity boost, even though we had to plugin our own persistence layer.
samratjp 14y ago
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/ http://trek.github.com/ (though routing has come a long way since - http://emberjs.com/guides/routing/defining-your-routes/ http://emberjs.com/guides/routing/defining-your-routes/
- heyitsnick 14y ago
  > 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 14y ago
    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 14y ago
      ah yes, you're right - meant to say that handle the serialize/de-serialize yourself at first to get your feet wet.
- securingsincity 14y ago
  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.
catch23 14y ago
Ember-Data isn't easy, and I'm sure when your frustration is running high it's easy to just say screw it and jump to backbone, but you'll be paying for it later if your frontend has more than 5 deeply connected models.

tbatterii 14y ago

we use ember at the day job, and historically i've been primarily the backend guy slowly getting familiar with what the front end guys are doing. I agree that the ember-data stuff is pretty thin on docs at the moment. IIRC, it wasn't part of the original stack, but obviously everyone wants a mvc with that persistence layer. So a -1 for that, not sure if it will be a part of ember by the time it reaches 1.0 or not. (oh yeah, it's still technically beta) But ember shines in other areas that people wont care about until they have to write single page web apps with a high enough complexity that warrants it. The reason we ditched gwt for ember was the 2 way bindings. Not having to write all that stuff(and test it(in every browser))has been a productivity boost, even though we had to plugin our own persistence layer.

samratjp 14y ago

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/ http://trek.github.com/ (though routing has come a long way since - http://emberjs.com/guides/routing/defining-your-routes/ http://emberjs.com/guides/routing/defining-your-routes/

heyitsnick 14y ago
> 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 14y ago
  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 14y ago
    ah yes, you're right - meant to say that handle the serialize/de-serialize yourself at first to get your feet wet.
securingsincity 14y ago
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.

catch23 14y ago

Ember-Data isn't easy, and I'm sure when your frustration is running high it's easy to just say screw it and jump to backbone, but you'll be paying for it later if your frontend has more than 5 deeply connected models.