The Ember teams has been planning for a sweep of all outdated information about Ember. We'll be updating SO questions and asking blog authors to add a disclaimer.

Ember Data is a completely optional component of Ember that seeks to bring ORM-like abilities to the client side. It's not as far along or as stable as core Ember. For what it's worth, you can easily just use jQuery.ajax and create Ember.Objects from the response. We probably do need better documentation in this area to make this clear. That said, it's not fair to count Ember Data as a point against Ember since no other framework has anything at all similar in scope.

Our overview documentation is lacking. This is something that we're actively working on improving. The hardest part for new developers coming to Ember is that the paradigms are very different than what they're used to. We believe that the paradigms are the correct ones, but we need to do a better job explaining them.

Without meaning to offend, I'm afraid I have to take issue with your points about Ember-Data.

Yes it's optional, and yes you can use jQuery.ajax or whatever, but in reality, it's not quite that simple.

The official guides in Ember default to assuming you're using Ember-Data (though they do at least mention it explicitly). This despite Ember-Data being far from production ready (as stated on the Github page) and far too slow for dealing with large quantities of data. At the same time, the conventions that are found in Ember-Data appear to be built in to core Ember (it says as much in the guides).

As far as Ember-Data not counting against Ember - it may be larger in scope than other client side data libraries (or the M part of other MVC frameworks or whatever) but the fact is that they are most definitely comparable, as it's the way that Ember gets stuff off the server, and saves it back to the server. Without Ember-Data, Ember has no built in way of doing that, which counts against it. With Ember-Data, well, it's not really ready yet, which also counts against it.

Ember is built to work with Ember Data out of the box, but it's trivial to make your own methods that fit with the conventions. I assume you're referring to the default `find` support in the router. All that Ember does is attempt to infer a class name and call `find(id)` on it if the `find` method exists. You can implement this method however you want, or even change your routes to call an entirely different method.

I also highly recommend watching one of the follow talks about Ember Data: http://www.youtube.com/watch?v=_6yMxU-_ARs or http://www.youtube.com/watch?v=V8nnE948zxk. Both talks make it very clear that Ember Data is not at all comparable to what is offerred by other frameworks.

I totally get that it's different to what's in other frameworks (the router is similarly different), it's just that, for the most part, on the surface, it pretty much serves the same purpose (other than some relationship stuff that half works). That is, it's the same the same part of the framework, just with extra features. Oh, and with a whole load of undocumented coventions in it.

Btw, is there a diagram or something that shows how it's put together internally (I'm pretty comfortable with how to use it from an API perspective, but find myself having to dive into the source code fairly regularly)?

Unfortunately, no such diagram exists though it would certainly be useful. The lack of documentation is tied a lot to the instability of the Ember Data API, both of which are reasons why it hasn't had a formal release yet.

Cool, thanks for explaining.

But, I really really think for a newbie (like me) to even find out that I can use jQuery.ajax to create Ember.Objects is confusing. The immediate questions following that would be

* How do I do that? Can I see an example? And where do I find a counter-example? * Then why Ember Object (ok fine they provide cool ORM features, but when I'm starting, I just want to understand what/where things are)

I know a lot of people are raving about Emberjs, and personally it looks good and I really want to get into it, but really really really, I found it not-newbie friendly.

Creating an Ember Object is very simple: `Ember.Object.create(properties)`. If you want, you can subclass `Ember.Object` and then `create` an instance of your subclass. The main benefit to using `Ember.Object` is that you get convenience methods like `get` and `set` (instead of having to use `Ember.get` and `Ember.set`). You can also add computed properties and the like to subclasses. I think this is actually covered fairly well in the guides: http://emberjs.com/guides/object-model/classes-and-instances....

Creating an object instance with AJAX is as simple as just calling `create` with the data provided in the callback. However, you may want to create the object first, then update the object's properties in the AJAX callback. This is similar to how Ember Data handles things.

Also, `Ember.Object` has nothing to do with ORM. Ember Data addresses this with `DS.Model`.

If there's a specific case you feel like we've missed in the guides, we'd love to have you file an issue about it at https://github.com/emberjs/website/issues.

Since Ember 1.0 isn't compatible with Ember x.0 you could save yourself a lot of that work by sticking to semantic versioning and just calling it 'Ember2'

I went through the same thing grandparent post did - a lot of old tutorials. I think it would be a good idea for Ember to make a complete break and to call this 1.0 release something else.

Semantic versioning states everything inthe public API should be considered unstable and changing until the major version is 1.

So whatever code samples are out there on blogs and SO were from the initial days of the API when it was changing a lot. I am with you and have been going through the pain of weeding out examples from the web that works with the latest version on GitHub. There were many methods that weren't even available in the current API.

Given the paradigm shifts with Router and the Controller, maybe what the Ember team needs to do now is to stop doing everything else and finish up on the documentation for their 1.0.0-rc.1 release before it is finalized to 1.0.0

That's exactly what is happening.