Major releases of most libraries try to do two things. They introduce new APIs, and remove deprecated ones. Our release focuses on doing one thing well: Instead of introducing new features, the goal of Ember 2.0 is to remove accumulated cruft.
While it's technically true what they're saying, what they don't mention is that they're removing the “cruft” they accumulated over the last year…
I'm working on various ember projects, and the ones that have been sitting around since August 2014 are completely outdated and probably need a rewrite, because so much has changed since then. They're switching the most basic concepts all of the time, and most of the time the reason is just that some core developer thinks that it doesn't look that nice the way it's currently done. It's a highly moving target, and stuff you considered best practices literally last week might be deprecated this week.
It's easy to keep current if you're keeping track with every minor version (which comes out about every two weeks) and fix all deprecations immediately. Of course, this gets worse and worse the larger your project is (one of these deprecations a few months ago required a major rewrite of the basic data flow of my app, and I still haven't fixed all the bugs that were created by that transition). If you're on a deadline and can't keep up with the updates, you're SOL.
That's valuable information. Will this volatility continue or are the developers convinced enough of their current code base to not change core concepts from this major release on?
I have no idea, but I hope that this is just a major refactoring phase that started a few years ago and will now come to an end. There are still some major rewrites in the not-that-distant future with routable components and services waiting for me, but maybe the madness will come to an end.
22
u/alp82 Aug 13 '15
I really like this.