Stabilizing Ember Data | Hacker News Reader

Stabilizing Ember Data

emberjs.com

71 pointsduggieawesome19 comments

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

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

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

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.

Yes, possibly enough to fight off the bad press even. Without such an initiative, I was afraid their hard work would fade into obscurity.

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)

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.

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.

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

God no! Not another framework!

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.

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.

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

Why would anyone pick ember over backbone?

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.

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.

Ember data is built on top of REST.

That's good to know... though in my hasty research I didn't see anything that said so. That should be a big selling point.

https://github.com/emberjs/data

I've submitted a PR to em-data which should make the REST support a bit more clear. https://github.com/emberjs/data/pull/834

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

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

I don't understand the downvotes.

This is from the first paragraph on backbonejs.com.

API over a RESTful JSON interface.

Emberjs.com doesn't mention REST once, not on the homepage, guides page, or API page.

AM::S maintainer here!

Conventions are more than just HTTP verbs, and the REST you refer to is... a set of conventions!

If you look at the spec for, say, ATOMpub[1], you'll find a set of conventions on top of REST: "Here's how you retrieve a resource"[2], "here's how you edit a resource"[3], "here's how you delete a resource"[4], among other things. This is because (as I'm sure you know, since you care about REST so much) that HTTP verbs do not map directly to CRUD, and there are verbs that do other things as well, so it's important to say what we mean, exactly.

"Conventions" are just putting a little bit of formalism around communication, so that both parties know what's being discussed. That's _really important_, especially between back ends and front ends. When AM::S spits out conventions-based JSON (there isn't a good name for the format yet), I can be confident that Ember apps will understand what I'm talking about, and that relieves work I'd normally have to do.

1: http://tools.ietf.org/html/rfc5023

2: http://tools.ietf.org/html/rfc5023#section-5.4.1

3: http://tools.ietf.org/html/rfc5023#section-5.4.2

4: http://tools.ietf.org/html/rfc5023#section-5.4.3

Reply on news.ycombinator.com