I hope it works out for you but that's just about exactly how I felt immediately before I realized it was not going to work for a very large project, switched to Angular and haven't looked back since. There was no comparison at all for me between Ember and Angular but everyone's needs are different.
What's weird is that I constantly hear the opposite. Angular's free flowing structure allows for spaghetti code in scale, while Ember might be overkill for smaller projects.
Ember's examples on their site are always the simplest use-case. For example, find me an example on their site of saving a complex relationship that was newly created by your application. Let's take the example of an invoice. Let's say you have an Invoice model, and an InvoiceLineItem model in a one-to-many relationship.
How do I save the creation of a new invoice (with line items) as a single transaction? As far as I can tell, you can't without breaking from Ember Data's very strict 'this is the way things should be done' model.
You have to create a new Invoice, then create the InvoiceLineItems doing something like this:
Note that this isn't even taking into account how to rollback INSERTs if, for instance a single invoiceLineItem fails to be created.
The 'other' way to do it is to create just an Invoice model, and have a lineItems attribute of type 'raw' and just create a RawTransform that's just as pass-through of whatever the JSON has for that attribute. It works, but at the same time, feels like it's going against the Ember Data Way, especially if you have a need for an InvoiceLineItem to be its own model (i.e. to be able to maintain relationships to other things and look one up by ID via the API).
Then you might have something like:
- Invoice and InvoiceLineItem models
- A RawTransform:
App.RawTransform = DS.Transform.extend({
deserialize: function (data) { return data; },
serialize: function (data) { return data; },
});
I really wish there was some thorough examples of using Ember + Ember-Data. Ideally it would be backend agnostic (mocked client side xmlhttprequest) and go from doing simple things like saving a model all the way to doing more complex things like you showed.
Drupal for instance has a /really/ great project that maintains a bunch of thorough examples (https://drupal.org/project/examples) which were indispensable when I did Drupal a while back.
It's kind of funny, but I don't even remember simple things being spelled out. For example, in their use cases all of the models and routes are single words like: post, comment, todo, etc.
In some places, you see 'Post' and others 'post', but there is nothing explicitly spelling out how that works for multi-word items (e.g. MultiWord => multiWord). Same with underscores in route names (e.g. route name 'multi_word.item.index' => MultiWordItemIndexRoute).
Yeah, the magic rejiggering of names everywhere with no clear documentation of what mapped to what† killed my interest in Ember the first time I tried to actually use it for even a fairly simple app.
† Plus the enforced snakeCase/CamelCase everywhere, but that's more to do with me far preferring names_with_underscores in general.
This is one of the reasons that Ember.js + Rails seems like the preferred setup. Ember.js + Python gets you into converting underscored names to camelcase names.
I'm not talking about transitioning from 'old' Ember Data to 'new' Ember Data. I'm talking about someone completely new to Ember looking through the examples and documentation. Even if they were looking through the repository, it would be easy to overload a file called "TRANSITION.md" if you don't need to transition from an older Ember Data version.
> Ember's examples on their site are always the simplest use-case.
This is really key. Even extremely common patterns that will be present in virtually every web app have no examples that I can find anywhere on the web. A great example is simple nested resources, where the URL is something like `/tv_shows/555/seasons/3/episodes/2`. Obviously, this is the page that displays info about episode 2 of season 3 of the TV show with id 555. So how do I reference the tv_show model (which I will almost certainly need to do) from the `EpisodesIndexController` or the `episodes/index` template? Do I really have to specify `needs` [0] on every controller nested under `TvShowsController`, and perhaps add a `setupController` hook to make the property easily accessible like in this tutorial [1]?
Granted, I'm pretty new to this, so maybe I'm just missing the obvious way to do this sort of thing clearly.
> Even extremely common patterns that will be present in virtually every web app have no examples that I can find anywhere on the web. A great example is simple nested resources, where the URL is something like `/tv_shows/555/seasons/3/episodes/2`.
I have a large, complex Ember.js + Ember-Data + Flask API app, and I don't think that I use `needs` anywhere in the codebase, so I don't think it's absolutely necessary. IIRC, the documentation says that `needs` only applies to singleton controllers. If you have a controller associated with a model (vs. a view + controller + route combo), I would assume that it's not a singleton (i.e. controllers associated with a view are singletons in that Controller.init() is only called once, even when switching away and back to a view).
To use my example of an app with URLs like "/tv_shows/555/seasons/3/episodes/2", if you're in the episodes/index controller (or template or view), how do you reference the particular season and tv_show that episode is part of?
If your API supports it you can use the EmbeddedRecordsMixin[0]. In general though, what would be a sane default for handling multiple REST API calls to single-model endpoints?
