Hi @Mervin_Vrolijk, I can give you an answer from my own experience, hopefully it will be helpful. For context, I work on an Ember app which started with Ember 1.3, over 3 years ago, and that we’ve upgraded to the newest stable version. It has grown in size and complexity over the last 3 years but I would contend that as time has gone on it’s actually become much easier to maintain than it was when we started.
I think maintainability is one of the chief strengths of Ember, for a couple different reasons:
Convention over configuration
Because Ember uses the Ember CLI and each project uses (at least by default) the same build tools and the same project layout, Ember by default promotes good practice and standard project setups, which greatly eases upgradeability and configuration. Updating the CLI is the most painful part of an Ember upgrade and it’s still a very straightforward process usually pretty headache free.
This also pays dividends in how the projects are organized. Whether you use standard or pods layout, there is a convention for what code to put where, and it makes it really easy to find the code that you need when debugging/making changes/reading someone else’s code.
Community support
One of Ember’s chiefest strengths lies in the strong community and broad core team. The core team represents a variety of different companies (rather than one, like Google or Facebook). There is a rich and varied ecosystem of powerful addons that allow you to add functionality to your app with a few keystrokes. There’s also a commitment and longevity to the technology. I can’t overstate how important the Ember community is and, while I don’t have tons of experience with some of the other frameworks, I’d say Ember has them beat in this regard.
Upgradability and developer ergnomics
As a corollary to the community point above, the core team has been committed to maintaining a steady and reasonable approach to deprecations, new features, breaking changes, and tooling/framework upgrades which makes upgrading and staying current as pain-free as possible. There were some rough patches in the upgrade path early on but the core team learned from some of those experiences and has really streamlined the development lifecycle.
There are LTS releases for those who wish to upgrade less frequently, which is nice if that’s not a high priority for you. On our team we like to be close to the cutting edge features so we upgrade pretty regularly. Thanks to the hard work the core team has done with deprecation guides, release notes, and a clear development roadmap, upgrading has been very smooth and low-friction even with a ton of addons and a fairly complex app.
One of the best examples, I think, is the Ember 2.10 release, where the core team committed to making the new rendering engine, Glimmer 2, a drop-in addon that was fully backwards compatible and required no breaking changes. Sure enough, when we upgraded we didn’t have to update our code at all and we got a 2-3x increase in render performance. As far as I’m aware that is a completely unprecedented feat in a SPA framework and it really hammers home how committed the developers are to making Ember developer friendly and easy to maintain and upgrade.
Conclusion
I’m sure there’s much more you could say on the subject, this is all off the top of my head. Our experience building and maintaining an Ember app (several in fact) has been very positive. I don’t like to be a fanboy about any particular framework or technology either. No technology is perfect. There are definitely some annoyances here and there with Ember. Overall though we feel like we’ve made a good choice in framework knowing that there is longevity, commitment to maintainability and sustainable development practices, lots of documentation and good community support, but also a sense of experimentation and innovation. We also don’t need to worry that the framework will introduce huge breaking changes in a new version (I’m looking at you Angular 2) and any upgrade paths we need to traverse in the future will generally be smooth and well documented.