4 ms·

I definitely hear your concern. But on the flip side, I decided to take the plunge with Ember rc2, and I've had to deal with very few breaking changes. And of t

I definitely hear your concern. But on the flip side, I decided to take the plunge with Ember rc2, and I've had to deal with very few breaking changes. And of the breaking changes, they were very minor. I didn't have to re-architect anything. It's been very pleasant, and the amount of value I've been able to extract out of Ember has been tremendous. So much so, that I've held off being a huge advocate since I consider it to be a competitive advantage. Ember Data, on the other hand, hasn't been ready. I also took the plunge with Ember Data with 0.12, and it turned out to be a mistake that's still looming over my head. (I think I would have been better off with Ember Model, or EPF which didn't exist at the time. Yes, I understand when you're new to the ecosystem, they all sound the same.) I think this has been a big part of where the confusion stems from. People who are new to Ember don't realize that Ember Data is a completely separate project with its own status. Please correct me if I'm wrong, but as far as I understand, there's no equivalent of Ember Data in Angular. Am I right? If that's right, then of the little bit you've said, it seems like you've run out of excuses not to use Ember :)

eknkc 13y ago
Haha yes I'm aware that it's a seperate project but it also seems like a tightly bound seperate project. I'd not be surprised to see some changes in Ember for the sake of ED's convenience for example. Ember Data is destined to be the dominant solution when it goes stable. That makes me want to use Ember Data, you know, it feels like "the whole stack". But I can't now :) Angular has nothing like ED. There is $resource, which is basically a wrapper around $http to provide some sugar. Not really extensible. But it works. The thing with angular is that the change tracking is transparent, so any simple javascript object / array is fine as a model. That makes it bearable to work with an inferior data library.
- jonnytran 13y ago
  I do that too. Extending Ember.Object also makes a perfectly fine model. You can mix in things like Ember.Evented to use it as an event target. You can work with Ember where it expects promises simply by implementing a `.then()` method. This is why I'm saying I think a lot of people fall for the same trap/gotcha as you. Ember Data is totally not necessary to be productive with Ember.

eknkc 13y ago

Haha yes I'm aware that it's a seperate project but it also seems like a tightly bound seperate project. I'd not be surprised to see some changes in Ember for the sake of ED's convenience for example. Ember Data is destined to be the dominant solution when it goes stable. That makes me want to use Ember Data, you know, it feels like "the whole stack". But I can't now :) Angular has nothing like ED. There is $resource, which is basically a wrapper around $http to provide some sugar. Not really extensible. But it works. The thing with angular is that the change tracking is transparent, so any simple javascript object / array is fine as a model. That makes it bearable to work with an inferior data library.

jonnytran 13y ago
I do that too. Extending Ember.Object also makes a perfectly fine model. You can mix in things like Ember.Evented to use it as an event target. You can work with Ember where it expects promises simply by implementing a `.then()` method. This is why I'm saying I think a lot of people fall for the same trap/gotcha as you. Ember Data is totally not necessary to be productive with Ember.