ember.js core-team person here: This article nicely summarizes not only why I recommend ember to others, but also why I have chosen to invest my time an energy into the framework and evolving ecosystem. It makes me productive, it makes my team-mates productive, it makes new-hires or members from other teams productive in my app and awesomely, it makes entirely random community members productive when they help other entirely random community members.<p>Software is complicated, copious amounts flexibility comes at a pretty hefty cost.<p>Although ember is considered an opinionated framework, the opinion really is only an optimized veneer + glue, peel it away and you have a maximally flexible experience, with typically clear adapter concerns between components.<p>As we discover and derive new best practices, we don't just aim to share it via literature, or a big bang release and let users discover it as they go. We actively evolve the framework to encourage these best-practices.<p>Although we are evolving rapidly, we spend copious amounts of effort ensuring the upgrade paths are incremental and digestible.<p>As a example of this, we have many users with massive applications that began their lives in the days of Sproutcore (5 years ago) but exist today as idiomatic ember 1.1x+ (and soon 2.0) apps. Although the earlier years compatibility and upgrades were shaky at best, we have been spiraling in on a good cadence.<p>I am working at Yahoo now, we have several large production apps, that are surfing near master of ember, we follow the deprecations to align ourselves with best practices and typically this means deleting a lot of code (liability) and letting the framework do more and more of the heavy lifting.
As a bonus, each time we hit issues, we close the feedback loop, report the issue, fix the bug and move on.<p>I believe all the frameworks are spiraling in on this value proposition, and that is wonderful. Ultimately good evolving best practices tech and idioms benefits the end users, and this is the only thing that actually matters.
I've also found the convention over configuration feature to help when I'm a lone developer working multiple projects. I often work on something (perhaps a side project) and then abandon it for a couple months. When I return I just run `ember serve` and dive in. In the past with my homegrown or invent-your-own-structure frameworks I first had to figure out what I had done on this particular project before I could be productive.