[kerkeslager]

Ember.js is the highest-cognitive-load framework I've ever used. Not only do you have to understand all the bundling of JS, but you have to understand Ember's naming conventions and project structure, which has a lot of corners and edge cases. The basic problem is that they give you a bunch of configuration points and if you don't know what configuration point to insert your code at, you're either going to be writing a terrible hack, or you're just plain unable to do what you need to do. There are similar issues with React, Angular, Django, etc., but Ember is the worst one I've ever used. It's been a while so maybe the situation has improved, but I'm simply not willing to go back to something that has burned me that badly.

[ravenstine]

I'm curious, when was the last time you used it? The Ember of today is a lot different from the Ember of 2015, and even the Ember of 2018. As of a week ago, it's now fully switched to a component library that can be used independently of the framework, and they're now template-only by default. It'd certainly be a shame if you completely gave up on it because of a version still using Ember.View.

EDIT: Forgot to mention component template co-location, which is pretty great, too.

[kerkeslager]

The last time I used it was early 2017.

However, I also remember that the rapid breaking of reverse-compatibility was also a problem. The fact that Ember is very different over time is a bug, not a feature.

To Ember's credit, their documentation is superb, and that includes detailed migration plans with each release. All the problems I ran into over time were solvable with the "RTFM" strategy. But I would rather use tools that I can keep a fairly-accurate model of the tool in my head, rather than ones that require deep dives into documentation for updates and trivial changes.

[ravenstine]

That's funny, because my perspective is the opposite on both points. I actually appreciate that they've been able to move forward with new ideas without worrying too much about backward compatibility. (though usually both new and deprecated features are moved into modules that can be imported separately) As far as documentation goes, well, I think it leaves something to be desired. If you like dozens of broken links, the Ember guides are for you. hahaha

Your criticism is totally fair, though. Part of the reason why I asked is because I'm going to be giving a talk at an Ember meetup I'll be hosting in a few weeks and part of it might be about why people are choosing not to use Ember and how we can make it better. So thanks for providing your perspective.

[kerkeslager]

> If you like dozens of broken links, the Ember guides are for you.

I suspect this happens when you fall behind their rapid release cycle, but I always kept my dependencies fairly current when I was using Ember. It's painful, but it's far less painful than falling behind and being forced to make updates all at once later (and with broken docs, apparently).

> Part of the reason why I asked is because I'm going to be giving a talk at an Ember meetup I'll be hosting in a few weeks and part of it might be about why people are choosing not to use Ember and how we can make it better.

My suggestion would be to find a way to make Ember more of a library and less of a framework, if that makes any sense.

I think what React does really well is that it's not weird or difficult to use a few React components in a completely non-React codebase, and it's not weird or difficult to use completely non-React code in a React-heavy codebase. React components are just that: components--there isn't a pervasive MVC structure that makes it difficult or weird to do stuff outside of it. If you have component A and component B, it's easy to have A on one page, B on another page, and A and B on a third page, or two A's, or two B's on the same page. Components are composable and isolated.

With Ember you have a few options to achieve this result: 1) duplicating code to allow the "components", 2) spinning up multiple MVCs in a page to isolate them from interactions, 3) writing some hairy conditional logic inside the "components", so that at least one of the components has to be concerned about the rest of the page.

2 isn't a bad option from a high level, but Ember assumes you'll only be running one MVC per page, and does a bunch of things which makes this nontrivial.

React Components aren't entirely unlike a little MVC, but the assumption from the beginning is that a React component may never have to interact with any other React component. Isolation is the assumption, rather than a single-page app full of entangled components.

But I completely realize that my suggestion is basically, "Make Ember more like React" and as someone with no investment in Ember at this point, there's not really a reason I'd choose Ember over React, which is supported and used by a bunch of much bigger and more mature codebases than Ember is, even if Ember were to switch to a more React-like model.

[cogman10]

They burned me with the "rails" problem. Ember and RoR are two projects that have really turned me against overarching frameworks. Both have gone through periods of crazy backwards breaking and paradigm shifts that have left me burnt out.

[kerkeslager]

Agreed.

I work in Django, and have a love-hate relationship with it. The main selling point is the Django ORM, which keeps me coming back, but even that is just the best of a lot of bad options. And a lot of Django patterns (class-based views, template tags, middleware, signals) are just obfuscating features that are handled much more simply with raw Python features. They let you write 80% of your behavior with 20% of the effort, but drastically impede your progress on the other 20%, and create debugging nightmares.

Beware projects with impressive quickstart guides.

[cogman10]

Yeah, The big problem with these frameworks is that, by their very nature, they punish you severally if you ever step outside of the framework. This can cause a whole bunch of headaches if you decide you want to pull in new functionality perhaps not supported by the framework.

An example of that is when you want to mix things like Jquery or React elements in with Angular. It is (or at least was) far to easy to step outside of what react expects you to do. The end result is a break on minor updates. So, instead, you'll often end up with these janky half maintained library like "Jquery-ui-datepicker-angular" (made up) Or whatever that try to bridge the gap as best they can.