> React with Backbone feels it could have been an equally good (if not better) choice.
Superficially it might "feel" like a better choice, but objectively it would have been worse if you're doing anything non-trivial.
The backbone router is severely lacking compared to the Ember Router. Same thing with having a lot of models with relationships between them. Sure there might be Backbone-related projects that try to tackle it — they are all way worse than the Ember equivalents. In my opinion they either lack tests, functionality or have terrible architecture.
I think it's a huge merit of the Ember community that they're moving in this direction. They saw something that worked better and weren't ashamed to say "Well that's better than what we have. We're going to do that instead".
Going by track-record and where they are today, Ember would in my mind be a great choice for any company that wants to start building web applications. Ember-CLI is a huge productivity boost, and I bet any company doing more than a few SPAs has had to build something similar; and it probably ended up way worse than Ember CLI.
I find it very unfortunate that web developers have all put their eggs in the Angular basket. From my point of view the rationale for choosing Angular today seem to be the network effect of readily available developers, and not so much the merits of the framework itself.
The Angular team realised they could do things better, and rewrote their entire framework. The Ember team realised they could do things better, and is incrementally moving towards that while letting you migrate your app with it.
It's been a while since I used react-router, but I think this is one place where the Flux flow is better.
Navigation is state, so we built a store to track it. It mediates between a UI model (which abstracts the window location and pushstate stack) and an internal state. Routing involves dispatching an action to request a specific URL, and changing the view to the navigation state is handled by the app's root "application" component, which then sends parameters onward to its current "view" component. There's a simple mapping of route names to views.
We built a very similar component for React, hooked into Flummox. The nice part is that async "just worked", and having the entire router available as a Flux store with actions that you can fire to change the page made integration powerful.
We also added some extra little code to make it run on the server: the <Link> component renders down to an <a> tag, and the router runs correctly, so everything works isomorphically, and as a neat bonus the bulk of the site works without Javascript enabled.
You make some good points. Yes, I totally forgot how good the Ember router is. As for CLI, we actually did build something similar (because CLI wasn't mature enough at the time I evaluated Ember) and it's holding its own against CLI quite well.
I evaluated Angular (as well as React) before settling on Ember last year. I disliked that it tried to own the DOM and that the concepts and terminology (e.g. transclusions) make it difficult to onboard new developers who weren't already experienced in Angular. Plus (and this is a personal opinion), both Ember and React application code looked more elegant than Angular apps.
Superficially it might "feel" like a better choice, but objectively it would have been worse if you're doing anything non-trivial.
The backbone router is severely lacking compared to the Ember Router. Same thing with having a lot of models with relationships between them. Sure there might be Backbone-related projects that try to tackle it — they are all way worse than the Ember equivalents. In my opinion they either lack tests, functionality or have terrible architecture.
I think it's a huge merit of the Ember community that they're moving in this direction. They saw something that worked better and weren't ashamed to say "Well that's better than what we have. We're going to do that instead".
Going by track-record and where they are today, Ember would in my mind be a great choice for any company that wants to start building web applications. Ember-CLI is a huge productivity boost, and I bet any company doing more than a few SPAs has had to build something similar; and it probably ended up way worse than Ember CLI.
I find it very unfortunate that web developers have all put their eggs in the Angular basket. From my point of view the rationale for choosing Angular today seem to be the network effect of readily available developers, and not so much the merits of the framework itself.
The Angular team realised they could do things better, and rewrote their entire framework. The Ember team realised they could do things better, and is incrementally moving towards that while letting you migrate your app with it.