[hardwaresofton]

In my mind, if you need a large framework that a whole team can use day in and day out, Ember is the go-to choice. It's got a lot of batteries included and the learning curve is pretty steep, but it has patterns and a way to do things for just about everything. It's also been rapidly absorbing the best parts of other frameworks and approaches -- fastboot, glimmer, etc.

- Angular had the spot, then bumbled the transition from 1->2->5.

- Durandal died/was transformed into Aurelia, whose hype never materialized.

- Backbone +/- Marionette seems to be in super slow decline, but doesn't update as fast as Ember.

- I don't know much about Polymer but it just seems like an interesting project, not something I'd suggest an org to use (I'm probably wrong).

Ember shouldn't be compared to tools like React/Vue because it's almost never just React/Vue, and Ember itself has lots of plugins that come into play. "React" =~ React + React-Router + Redux/Reflux/Fluxxor/Flux/whatever, and roughly the same with Vue -- though you can choose to extend Ember with plugins, by default everything you need is baked in, with ONE set of well-written if not long documentation. I can certainly say that Ember is more coherently put together than react/vue + react-router/vue-router + redux/vuex.

One of the biggest problems with ember of course, is the breakneck pace of change. I think it's slowed down somewhat recently, but keeping up with it can feel like a full time job sometimes, if you get stuck behind for too long, it gets harder and harder to update your codebase.

As far as I'm concerned, Ember should keep doing what it's doing, it's basically the only worthwhile competitor these days in the most-batteries-included (aka frontend framework rather than frontend library) space. If anything these days, Angular (5?) is looking like it's pivoted it's way to essentially emulating Ember, so I'd place it second.

[megaman22]

> One of the biggest problems with ember of course, is the breakneck pace of change. I think it's slowed down somewhat recently, but keeping up with it can feel like a full time job sometimes, if you get stuck behind for too long, it gets harder and harder to update your codebase.

If there's somewhere in the front-end world where this is not the case, short of going back to jQuery spaghetti, I'd love to find it. We're largely settled in with AngularJS, having caught it after the crest, so that is largely settled, but everything around it is moving and breaking and deprecating things left and right. I always feel like we're standing on quicksand, just waiting for some bower or npm package to get yanked out from under our feet.

Compared to the back-end, where things move at a much, much slower rate of change, it is a little maddening to see the churn in JS-land. I have NuGet packages that I use all the time that haven't seen more than minor-minor version updates in three years - and that's fine, they work, they're stable, there's no reason to burn it down and flex it all around every three months. But that's also a benefit of being in the Microsoft ecosystem, where backwards-compatibility is prized.

[hardwaresofton]

I actually made that statement with the pace of the front-end world taken into account -- ember actually churns additionally :( . Part of Ember's openness to doing things better often involves deprecating/removing parts of their API that they're convinced was wrong before -- it's not a bad thing, but it means that if you get stuck on some version, and the next version has gone a different way on some concept/part of the framework, you're going to have a bad time, even if the landscape hasn't moved much yet.

I spend a lot in frontend land and I've grown somewhat accustomed to it's insanity. I actually even like it at this point -- Let everyone go insane in all the different directions, watch how they fare, then let the good stuff rise to the top, and pull out the interesting paradigm shifts if there are any. Platforms like C# often have a lot more enterprise weight behind them and "stable" takes on a completely different meaning.

I might even say that churn in .NET is happening too, it's just way way more localized. For example the .NET core/standard move is happening right now, but I can only assume that the vast majority of codebases on .NET 4.x don't care at all, and are letting it work itself out maybe over the next year before they even consider moving (if they ever move at all). As a person who's struggled with porting a .NET 4.x package to .NET core/standard, and with some associated libraries (EF, mostly), it was not a pleasant experience, but by the time it gets to everyone else, it probably will be.