Thanks for an interesting writeup. Something I'm curious about for devs who've used ember on projects that had a maintenance period of 1-2 years: how do you feel about it as your app grows and changes over time?
With most kitchen-sink or CoC frameworks, this is kind of the achilles' heel. patterns get codified because they're easy and "good enough" but they DO NOT age well. How does Ember deal with this? Also, what about the ecosystem? Is Ember work driven almost entirely by the core framework, or is there a plugin ecosystem that attempts to have an answer for every problem? (yes Rails, I'm looking at you.)
I'm developing and maintaining an Ember app which is nearly 5 years old. Some of our app code dates back to 2011 (when Ember was still Amber.js).
Remember how much the Javascript ecosystem changed in 5 years? There is no way we could have maintained the same code base without Ember; we would have needed to rewrite the app once or twice by now. And with each rewrite small features, little subtleties would have been lost, replaced by some bike-shedding about how we should hand-compose an entirely new stack.
Instead, we upgraded quietly from time to time, and kept all our carefully tuned code and beloved UI tweaks with us. To be honest, the maintenance and version bumps took quite some work, and some early upgrades required heavy refactoring. Ember paradigms changed frequently during the pre-1.0 era, and later React clearly influenced the best practices recommended for Ember 2 (like Data-Down Actions-Up, etc).
But boy is it worth it. Ember-Data is neat, the testing tools are great, the Ember-Inspector add-on is a joy, and the CLI tools gets us so many free features. And we never could have maintained this product without a stable framework across all these years, and the friendly developers community.
Also, to answer your question about add-ons: they're great. Among the core team there is a nice commitment to make many new features available as add-ons (rather than baking them into the framework). And the community solves many common problems for you indeed.
I started on Ember around the 1.12 timeframe and left that job about a month ago and we were on 2.6. There were a couple hiccups going to 2.x but nothing more extreme than I've experienced with any other major version update. The Ember team also does a stellar job providing useful deprecation notices and not breaking any minor version update, i.e. if you're on 2.1, you can upgrade directly to 2.6 and be reasonably confident it'll still work. Your console might get flooded with deprecation warnings, but they helpfully link to the release docs for the change.
The only thing I'm not a huge fan of is their JSON-API as a default data adapter, since there's a ton of immature JSON-API server-side libraries with varying levels of spec compliance and completeness. If you're backed by Rails, you're in good shape. If you're backed by Java, you're fairly fucked.
Have used Ember since early 2012 (just when it transitioned from SproutCore). Fairly large application (~80 routes, ~60 models).
## Stability
Overall very well, we've never done any rewrite (apart from a coffee-script -> JS conversion, but that had nothing to do with Ember).
## Updates
Upgrades has been easily, except for the early days. But since 1.5 or so it's worked really well.
## Addons
There is a lot of power in the Ember ecosystem, but it also stays away from some things (widgets etc) which I think is great. For, say, a date-picker you'd use an addon (https://www.emberaddons.com/?query=date) or build something yourself.
## Progress
Despite having used the framework for several years it's still very modern. Ember has done a good job of keeping up with new technologies without causing unnecessary pain for developers. ES6 modules, good alignment with web-components, ES6 classes, modern tooling etc. None of this wasn't in place in 2012, but Ember has managed to bring it all on board without causing upgrade issues or painful breaking changes.
> how do you feel about it as your app grows and changes over time?
There was a lot of breaking changes in Ember going from 1.x to 2.x but now api is stable mostly.
You need to remember that Ember is very opinionated, that's why maintainability is a lot easier over the time. There is only "Ember way" in most of the things (routes,templates,components etc). I have now around 130-150 files in my Ember app and what is a little iritatin is that routes, controllers and templates are in different files by default if you use ember-cli (you should with ember, it's great, really great tool, one of strengths of ember).
> Also, what about the ecosystem? Is Ember work driven almost entirely by the core framework, or is there a plugin ecosystem that attempts to have an answer for every problem?
You can build full app (with routing etc) without using any plugins at all. But there are a lot of plugins on github that you can use if you need something special.
I've been running a large ember app since the pre-1.0 days (2013). We made a few bad choices early on in how we structured our data models that were not the "ember way" and took a while to sort out, but overall it has been smooth sailing. The 1.13 -> 2.0 upgrade wasn't too bad, and the 2.x updates have been painless.
At this point they're pretty good about issuing deprecations a version before they make breaking changes, so upgrading just involves bumping the version and fixing any deprecations that come up, to prepare you for the next version.
They have been pretty aggressive about ensuring addons work with the latest version; you may have issues with newer addons if you're stuck on a very old ember for some reason. `ember-try` is great for running CI against all ember versions.
With most kitchen-sink or CoC frameworks, this is kind of the achilles' heel. patterns get codified because they're easy and "good enough" but they DO NOT age well. How does Ember deal with this? Also, what about the ecosystem? Is Ember work driven almost entirely by the core framework, or is there a plugin ecosystem that attempts to have an answer for every problem? (yes Rails, I'm looking at you.)