

Stabilizing Ember Data  - duggieawesome
http://emberjs.com/blog/2013/03/22/stabilizing-ember-data.html

======
pdog
The Ember team has been remarkably responsive to what's trending[1][2].

[1]: [http://discuss.emberjs.com/t/getting-started-with-ember-
js-i...](http://discuss.emberjs.com/t/getting-started-with-ember-js-is-easy-
no-it-isn-t/559)

[2]: [https://errplane.com/blog/why-we-are-moving-away-from-
emberj...](https://errplane.com/blog/why-we-are-moving-away-from-emberjs)

[3]: <http://emberjs.com/blog/2013/03/21/making-ember-easier.html>

~~~
jeffpersonified
Agreed. I think it says a lot about Tom Dale and co., and have been really
impressed with their responses in aggregate – it's probably been a long week
for the Ember team.

------
avolcano
Ember Data can be really powerful, but is even far worse in the "black box of
magic" department than Ember itself. There's a lot of crazy internal state and
logic being fired off in all directions, and it can lead to very strange state
errors and race conditions.

I'm really glad to hear that they're adding an adapter type that can be more
powerful than just an $.ajax call while not being quite as complex. It was by
far my biggest complaint with Ember.

(of course, I hope this doesn't stifle development of more full-featured
adapters - I think half my problems with Ember Data come from the LocalStorage
adapter I'm using having some major issues ;p)

~~~
1qaz2wsx3edc
I think a big chunk of magic in Ember is its state machines. I think without
explaining this core-mechanics and how it's used by ember and ember data.
Beginners will have a terrible time learning the framework. Not only this, but
you're exactly right you end up in weird unresolved states, due to bugs, race
conditions and a like. Not fun.

Also ember should try and move away from calling itself an MVC, it's much more
complex then that. I think this mis-categorization confused new users as well.

I feel ember has a lot of broken promises, but I will continue to hold
judgement until a solid 1.0 release.

------
calgaryeng
People really need to stop ragging on the Ember team... "Too hard to learn",
"I'm abandoning it for now", etc. etc. etc.

These guys are making a (potentially) awesome framework in the spirit of open
source, for you, for free. If you want to complain, start your own framework!
I honestly admire their patience for putting something amazing out there, and
then having to continuously write these almost apologetic blog posts talking
about how they are going to work hard to make things better.

~~~
kaoD
> If you want to complain, start your own framework!

God no! Not another framework!

------
zaius
I think this is a great idea. Ember-data is powerful, but it's still very
unpolished, and there are a lot of hard problems left to solve. I don't think
it should be rushed just because ember is now close to v1.

------
adamnemecek
For what's it's worth, I've had a very similar experience to what most people
described (tried Ember in August '12 and after struggling with it for some
time, gave up). But the Ember team's recent efforts have made consider giving
it another look. Keep it up.

------
jjellyy
I have alot of experience with backbone, and I would highly recommend it to
anyone.

Why would anyone pick ember over backbone?

~~~
jeffpersonified
I've really loved using Backbone myself, and have very limited (simple, sample
apps) with Ember. Ember comes with stronger conventions than backbone, giving
one a fuller out-of-the-box application, which for some people and projects is
more preferable.

I think, like many people have said, they're each intended for different use
cases.

------
anonfunction
Strong conventions you say? Stop reinventing the wheel and build on top of
REST. That would allow developers to define a resource and then have access to
GET, POST, PUT, DELETE through an easy to use API.

~~~
tomdale
Thanks for the suggestion! In fact, you've just described exactly what we're
building. We are big fans of REST, and if you read the documentation, you'll
see that the default behavior of Ember Data is to transmit RESTful JSON[1].

In addition, we've been working with a bunch of really smart Rails people like
Steve Klabnik and Santiago Pastorino on projects like
ActiveModel::Serializers[2] and rails-api[3].

That being said, we know that there are a lot of different ways to serialize
and transmit records, so we've designed the architecture of Ember Data such
that those decisions are encapsulated in specific objects which we call
adapters. You can think of it like the adapters for different databases for
ORMs like ActiveRecord.

The default adapter, though, is RESTful JSON, and is what we use in all of our
applications. You can see the implementation on GitHub[4].

1: <http://emberjs.com/guides/models/the-rest-adapter/>

2: <https://github.com/rails-api/active_model_serializers>

3: <https://github.com/rails-api/rails-api>

4:
[https://github.com/emberjs/data/blob/master/packages/ember-d...](https://github.com/emberjs/data/blob/master/packages/ember-
data/lib/adapters/rest_adapter.js)

~~~
anonfunction
Thanks for the response! Only reason I mentioned it was that I didn't see REST
anywhere in the linked article or here: <https://github.com/emberjs/data>

