Personally, I feel Ember is best suited for the enterprise world. It's a slower moving framework focused on backwards compatibility that remains relatively similar over the years. I feel slightly insulated from the rapid changes in the front end world which allows me and my team the ability to focus on the business. Of course, I push my team to understand what's going on outside of Ember. I've definitely taken things away from React and Redux.

But having to maintain dozens of apps (and growing), I couldn't imagine the technical debt we'd have if we chose a different framework. Our repos would be scattered with the latest and hottest fad and changing standards.

- It is a fully considered (if not well-considered) framework which is great for large teams

- It keeps up with other libraries and best practices by adapting

Unfortunately, the best thing about Ember is also the worst thing -- changes can happen so fast that it becomes necessarily hard to update if you stop keeping up with it.

Ember's only competitor in my mind is Angular in the current landscape -- assuming people do not want to bolt together a vue+vuex+vue-router setup.

https://en.wikipedia.org/wiki/Hype_cycle

Ember is firmly in the "Plateau of Productivity". It's stable, supported, but no longer the "new thing" so you don't hear much about it.

There's value in using tools you're already proficient in. And that's the thing that rubs me about framework debates: it's like we're all debating what screw head is best (Robertson, btw).

It's... fine. If you know Ember, you can build a reasonable app pretty quickly. If you have a team that knows Ember and likes it, there's not going to be giant gains to switching to something newer. Certainly not enough to justify a rewrite. The integration between the framework and Ember Data is nice if you have an API that natively works by the JSON API standard that Ember Data expects. It's big selling point is it's more of a one stop shop than something like React and Vue where you have to bring your own data layer and router etc.

However... if it was up to me, I wouldn't use it again:

If your API doesn't emit JSON API, expect to write a lot of serializer/adapter code.

The Ember object model breaks browser debugging (and no, the Ember Inspector doesn't make up for it, you can't dig down into objects there, the best you can do is send it to $E, then manually issue $E.get() calls). You end up looking in foo._internalModel._data to get a decent look at what the data actually is.

The build tools are slow. Broccoli still cannot output sourcemaps which map back to real source.

The framework has strong opinions about app layout, based on Rails. It groups by concept. So you have folders for models, controllers, components etc. While you can nest within it (so you can have controllers/my-feature/{a,b}.js and components/my-feature/{c,d}.js), it still ends up with your code for a feature all over the place. I'd much rather have my-feature/{controllers/{a,b},components/{c,d}}.js and have all code for a feature in one place. Pods were supposed to fix this, but have been abandoned.

The public API is too prone to spitting out objects that only have private APIs. e.g. look at adapter.createRecord (https://emberjs.com/api/ember-data/3.7/classes/DS.Adapter/me...) . You get based the data in a DS.Snapshot. What public supported actions are available with a Snapshot? (None: https://emberjs.com/api/ember-data/3.7/classes/DS.Snapshot). RecordArray in the past was similar, as were the factory and transition APIs.

Because of the above point, many popular addons are tied to APIs that are considered internal and prone to breakage. This means while the Ember team advertise "Just follow the deprecations, you can update with ease", you really can't. Your addons will break and will need to be updated in parallel and if they've updated their APIs at the same time, you're kind of SOL.