As someone else said, Ember was never that popular, and the community doesn't really strive to be popular. This is, however, a dilemma, because you need some popularity for your framework to have people interested in working on it.
Ember was cool initially because, if you knew Rails, then you could get what Ember was about even if it was confusing at times.
There were some choices made early on that even the Ember core team implicitly admits weren't so good, and they spent a lot of time moving away from those choices. As time went on, more developers became interested in other libraries like React because it's simpler and obscures much less of what it's doing under the hood. Ember decided to sit on the sidelines and take the time to figure out what to do next. This was both a good and a bad thing for Ember in the long run.
The long road to "modern" Ember got us the Glimmer component system, which is much nicer than the classic reactivity system, and it also gave us an improved templating system to classic Handlebars. Usability in the space of the runtime code was much improved, but this seemed to be at the cost of the build step being up to snuff with every other emerging JavaScript toolchain. Broccoli does some interesting things, but literally no one outside of Ember uses it because not only is it poorly documented but it's inferior to Webpack in a lot of ways. If an add-on that integrates Ember builds with Webpack wasn't made, Ember would be totally dead by now. Because Broccoli is niche and kind of hard to understand, even the developers who managed to figure out how to create add-ons for Ember didn't seem to understand the potential performance penalties of making a library into an Ember add-on as opposed to finding some other way to include code. Somehow a lot of Ember apps become really slow to build in Ember CLI, and that's partly because so many apps import a bunch of Ember-specific add-ons that are all doing something with the Broccoli tree.
Now there's Embroider, but we've been hearing about Embroider forever now, and it's neither reached v1.0 or the compatibility level it's advertised (in my experience). Not only is it too little way too late but it's still too complicated a way to simply bundle and share code between Ember projects. Trying to be compatible with Broccoli was a complete mistake and it should have been an opportunity to completely leave behind the cruft of v1 add-ons.
There's also some failed promises along the way. This thing called "module unification" which was going to greatly change but also improve the directory structure of Ember apps was sold as being something to look forward to in "Ember Octane", only to be dropped long into the process because for some reason it became infeasible. What does that tell you about Ember when the developers of Ember can't even change their own directory structure? Eventually they introduced template co-location, which was a good enough improvement over having a separate directory for templates, but that's another example of too-little-too-late. How is anyone supposed to be excited for template co-location when we were promised something better and every other framework is already more flexible to start with?
No matter how hard it tries, Ember is stuck in the past. Everyone has seen better at this point.
Yes, you can build ambitious web applications with Ember, but at least in other frameworks you can more easily figure out how to do something without getting stuck somewhere deep in the endless stack of framework code and being baffled. Yeah, Ember Data will "just work" for you until you want to do something like also fetch nested resources (example: /users/123/posts/456), which I'm pretty sure is still hard to do without some workarounds. Yes, the router is pretty great until you realize you need a wildcard segment in your URL.
But why would you do that when you could have used that time to just write your own solutions or swap out different libraries if you were using most other frameworks?
In Ember, you hardly get that choice because you have to use Ember CLI, you have to use Broccoli, you have to use the Ember router, you have to use the Ember/Glimmer reactivity model, and so on, and so on. With Ember, you're either all in or you're all out, more or less. Yes, technically you can write your way out of these things, but like I said, at that point you might as well just write your own framework using any number of other tools out there.
All in all, Ember isn't bad. It's just another tool like anything else. I've worked with it on apps with millions of users worldwide. There are still things I like about it. That said, I don't find it surprising that Ember is declining in relevance. With React and Svelte on two ends of the frontend continuum and Vue somewhere in the middle, there just isn't a big demand for what Ember provides. In order to do that, it would need to accept that it's lost and do things to entice new users, which would mean completely abandoning
- Agree with Ember Data and nested resources, that's still needlessly complicated. Same with lack of wildcard in the router/URL.
There are still things Ember needs to fix, for example removing controllers and improve Ember Data. But overall I think there is a good future ahead for Ember.
As someone else said, Ember was never that popular, and the community doesn't really strive to be popular. This is, however, a dilemma, because you need some popularity for your framework to have people interested in working on it.
Ember was cool initially because, if you knew Rails, then you could get what Ember was about even if it was confusing at times.
There were some choices made early on that even the Ember core team implicitly admits weren't so good, and they spent a lot of time moving away from those choices. As time went on, more developers became interested in other libraries like React because it's simpler and obscures much less of what it's doing under the hood. Ember decided to sit on the sidelines and take the time to figure out what to do next. This was both a good and a bad thing for Ember in the long run.
The long road to "modern" Ember got us the Glimmer component system, which is much nicer than the classic reactivity system, and it also gave us an improved templating system to classic Handlebars. Usability in the space of the runtime code was much improved, but this seemed to be at the cost of the build step being up to snuff with every other emerging JavaScript toolchain. Broccoli does some interesting things, but literally no one outside of Ember uses it because not only is it poorly documented but it's inferior to Webpack in a lot of ways. If an add-on that integrates Ember builds with Webpack wasn't made, Ember would be totally dead by now. Because Broccoli is niche and kind of hard to understand, even the developers who managed to figure out how to create add-ons for Ember didn't seem to understand the potential performance penalties of making a library into an Ember add-on as opposed to finding some other way to include code. Somehow a lot of Ember apps become really slow to build in Ember CLI, and that's partly because so many apps import a bunch of Ember-specific add-ons that are all doing something with the Broccoli tree.
Now there's Embroider, but we've been hearing about Embroider forever now, and it's neither reached v1.0 or the compatibility level it's advertised (in my experience). Not only is it too little way too late but it's still too complicated a way to simply bundle and share code between Ember projects. Trying to be compatible with Broccoli was a complete mistake and it should have been an opportunity to completely leave behind the cruft of v1 add-ons.
There's also some failed promises along the way. This thing called "module unification" which was going to greatly change but also improve the directory structure of Ember apps was sold as being something to look forward to in "Ember Octane", only to be dropped long into the process because for some reason it became infeasible. What does that tell you about Ember when the developers of Ember can't even change their own directory structure? Eventually they introduced template co-location, which was a good enough improvement over having a separate directory for templates, but that's another example of too-little-too-late. How is anyone supposed to be excited for template co-location when we were promised something better and every other framework is already more flexible to start with?
No matter how hard it tries, Ember is stuck in the past. Everyone has seen better at this point.
Yes, you can build ambitious web applications with Ember, but at least in other frameworks you can more easily figure out how to do something without getting stuck somewhere deep in the endless stack of framework code and being baffled. Yeah, Ember Data will "just work" for you until you want to do something like also fetch nested resources (example: /users/123/posts/456), which I'm pretty sure is still hard to do without some workarounds. Yes, the router is pretty great until you realize you need a wildcard segment in your URL.
But why would you do that when you could have used that time to just write your own solutions or swap out different libraries if you were using most other frameworks?
In Ember, you hardly get that choice because you have to use Ember CLI, you have to use Broccoli, you have to use the Ember router, you have to use the Ember/Glimmer reactivity model, and so on, and so on. With Ember, you're either all in or you're all out, more or less. Yes, technically you can write your way out of these things, but like I said, at that point you might as well just write your own framework using any number of other tools out there.
All in all, Ember isn't bad. It's just another tool like anything else. I've worked with it on apps with millions of users worldwide. There are still things I like about it. That said, I don't find it surprising that Ember is declining in relevance. With React and Svelte on two ends of the frontend continuum and Vue somewhere in the middle, there just isn't a big demand for what Ember provides. In order to do that, it would need to accept that it's lost and do things to entice new users, which would mean completely abandoning