rxcfc

I agree that Trek's response here is not very helpful. However he has spent countless hours working on Ember's documentation and the fact that it's where it is now is due to his dedication. There's clearly more work to be done and we're all very well aware of that. We've been working on a getting started tutorial but it's been slow going since all of us on the Core Team are very busy with our day jobs. We hope to get something out for everyone as soon as possible.

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.

It's not quite a shorthand as the controller can have properties of its own as well. However, the general understanding is correct, the controller proxies to the content. The controller is not the data, but it acts like it.

Are you implying that Ember doesn't deliver on this desire to build desktop class applications in the browser? If so, can you explain where it falls short?

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.

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.

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.

I understand how that would add a bit of overhead, but it doesn't seem all that crazy. Certainly a well architected client app wouldn't have any issue with this. Maybe I'm missing something?

This is actually something I think can be solved. There have been some experiments in Ember with building Ember model definitions from the server model definitions. However, in practice I haven't found this to be much of an issue in my development.

That's a good point. We probably should add a section on helping users decide whether Ember is a good fit for their goals. While there's obviously some disagreement in this area, we can at least make it clear what sort of apps we intend Ember to be used for.

If it's double the work, you're doing it wrong. Possibly it's not a good fit for your specific case, or you haven't fully understood the best way to use it.

"we did live (email) thread locking and all kinds of crazy stuff" - Can you say more about what this entails?

If you're building the kind of app that Ember is designed for, all of the above will be true. But we never anywhere claim that Ember is the right solution for every webapp. There's a definite type of app that doesn't benefit from Ember and I'll happily tell people that. There are also other simple widget based apps where I think Backbone is a good option.

This talk I gave last year describes some of the problems that Ember attempts to address that libraries like Backbone don't: http://vimeo.com/49434697

We were in the middle of the release yesterday. If anything is still not matching, please let us know so we can correct it.

a) Are you proposing that Ember should have stayed SproutCore? To date, Ember has been far more successful than SproutCore and the split has enabled us to make progress that could not have been made otherwise.

b) The Ember developers also have influence over those who work with web standards too. Yehuda Katz, of the Ember Core Team, is a member of TC39 and also W3C TAG. We regularly meet and converse with developers both for Chrome and Firefox. Furthermore, Chrome is not going to implement features that are only useful for Angular. Anything they implement that benefits Angular is also provided to be useful to a broader audience. In many cases, those improvements are also useful to Ember.

c) As announced at EmberCamp yesterday, there is also an Ember Chrome extension in development.

It all depends on what kind of app you're writing. If you're happy with whatever solution you're using then it's foolish to change just for the sake of change. However, I've known multiple developers who started with Backbone and then found that it wasn't able to meet their needs and then switched to Ember. Zendesk is one such example. The goals of Ember are actually very different from Backbone. Furthermore, living on the bleeding edge with others is better than living on your own bleeding edge by yourself with a ton of code that you rolled on your own.

We know that a getting started guide is essential. It's a high priority for us and we actually worked on it today.

The docs are actually quite good now. As we've just released 1.0 RC, the API is also frozen which will help the docs improve even further.

This was only true briefly. The guides on emberjs.com reflect the currently released version, 1.0 RC. Since we've hit RC the APIs are now frozen.

Prior to the 1.0 RC, Ember's API changed a lot because we were seeking for the best abstractions. We didn't want to lock ourselves in when there was a better way to do things. Now that we've hit 1.0 RC, the API is generally frozen. We'll only break existing APIs in exceptional cases. Once 1.0 Final is release we'll be sticking to SemVer.

Ember has changed quite a bit from its SC roots. I would probably use Angular over SC myself, but if given the choice to use Ember would much rather use it.

This is a good post on why Discourse chose Ember: http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.h...

This is a great post on why one project chose Ember: http://eviltrout.com/2013/02/10/why-discourse-uses-emberjs.h...

Things like this make me extremely wary of Angular's DI: http://www.alexrothenberg.com/2013/02/11/the-magic-behind-an...

I think if we're going to start this debate that we need to substantiate the claims on both sides. This is probably not the ideal place for that debate, however.

I'm pretty confident in Yehuda and Tom's ability to figure things out. It's a very difficult problem to solve, as evidenced by the slow pace of progress, but I think it is a solvable one.

Certainly unfinished. Unlike Ember, Data hasn't had any releases. There's a reason for this. We don't think it's stable enough to recommend to anyone unwilling to do some hacking.

Sorry about this, we're going to be cutting a new release soon so that should resolve this discrepancy.

More guides are in progress.