I'm using it as my framework of choice for 5 years and have helped programmers become productive with it. I have used other frameworks and keep up to date with React.
I have not fulfilled the survey.
Ember was never very popular. It is sort of similar with how Rails is seen. I've found it very productive and great. I've had issues hiring people because they've heard of Ember, have not used it and don't want to move away from React because (my opinion) it's very popular on LinkedIn and the likes.
The chart mixes frameworks and it makes little sense.
Ember and Angular are big frameworks with a sort of standard response for everything.
React and Vue are view layers, you eventually build your own framework. I think Svelte also fits here.
Stimulus updates the browser with html from a Rails server.
Not sure where to put Alpine. They describe it as an updated jQuery-like development thing.
I just got a new job, mostly backend but with a bit of Ember thrown in, and I despise the framework. It's slow to work with, massive, and incredibly over-engineered and makes it so that creating the simplest of features is an absolute mess. Maintaining a sizeable Ember project is pure hell of traversing through 800 folders and files to find the one place the thing you're looking for is, since you can have a controller inherit from another, which inherits from another, which inherits from another ad infinitum, so good luck guessing where exactly that one attribute is coming from, or even what the hell it even is. The base controller might have a variable called `foo`, but then somewhere down along the chain that variable has been aliased/transformed into a completely different variable name with 0 bearing on what it originally maps to.
Handlebars templating is also *awful*, I cannot describe with words how much I despise Handlebars and everything surrounding it. To create a simple `if (foo && bar)` in a template, you have to do `{{#if (and foo bar)`. Okay, the `and` DSL is a bit weird, but not that bad. But then `if (foo && !bar)` becomes `{{#if (and foo (not bar))}}`. God forbid you want to do any kind of comparison though, because `if (foo < 0 || bar > 1)` becomes `{{#if (or (gt foo 0) (lt bar 1))}}`. You get the point, it quickly dissolves into an unreadable soup of brackets and DSL for very simple logical operands.
I could go on for a while about why I hate Ember, but I'll leave it at that.
</bigRant>
Handlebars extends on Mustache which considers itself "logic-less" templating language. I think `{{#if (and foo bar)` goes against that principle, so introducing ie `shouldShowX` property on component which then depends on foo && bar and just using `{{#if shouldShowX` really helps.
I do understand that reasoning, but that comes back to my annoyance with having to deal with a million files to do anything simple. I then need to create a backing controller if it wasn't there before, and if it is there, I need to add on an extra computed on top of the mess of other computeds already present. Why so complicated? JSX and Vue's flavor of templating is infinitely better, since it's basically just regular javascript in the template.
I've read your comments and it looks like a mess of a codebase, more than a "framework mess". It seems like a bad experience and I would not want to deal with deep inheritance and over-reliance on old/deprecated functionality (computed properties), so... hug.
Controllers are not required for anything except query params mapping.
It's perfectly fine, and I think very common, to load data in components. A rule of thumb is to load in the route only the minimum amount of data for your layout to work.
As for the million of files ... React co-locates template and logic code while ember-cli generates a js/ts file, a hbs file and a test file. It's either 2 to 3 (if you count a test file for the React component) or 1 to 2 (discard test files).
Finding the sweetspot between large components and multiple components is not easy.
For example, it was considered a best practice to apply the presentation-container pattern in React, which means 2 components.
I'm not going to say anything about your claim that JSX is regular javascript in the template.
Ember is in “SPA” space, so it is competing against other big js frameworks like angular and Aurelia. Angular is super famous and is backed by google,so it is more used, than ember.
On the other hand, react & vue are in “view layer” with ability to move to full SPA space with additional libraries. Hence, they have wider scope, and therefore are more used than large frameworks like angular.
This won’t change in future either. Large js framework will require more learning effort. So, newer devs would prefer smaller frameworks.
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.
