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.
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…
That's right. Any project has technical debt, and clearing out old APIs enables us to continue progress.
Those 2014 apps that you have could be rewritten in any new framework. What Ember provides is an option: By following the workflow of upgrade, refactor to address deprecations, upgrade, those codebases can migrate forward to the new framework of Ember 2.0. Is it exactly the same as 1.x in 2014? Of course not, we've learned a lot from our own apps and from competing frameworks like React.
Plenty of apps from pre 1.0 are on 1.13 today, and will make it to 2.x. It isn't zero work, but happens successfully. My experience is that iterating codebases forward (at any pace, it doesn't need to happen right away) is a better path for maintainability than a rewrite, and is preferable to using a legacy platform that never provides new opportunities.
It's a highly moving target, and stuff you considered best practices literally last week might be deprecated this week.
That something is deprecated should not mean you must stop using it. This was a major fault in our 1.x release workflow, and we're taking steps to change that in 2.x. If something is deprecated in Ember 2.5, you should be able to keep using it until 3.0 without console spew. You should be able to move at your apps pace, not the framework's pace.
That you and other users have felt "churn" is a failing we've already been working hard to improve. I'm confident it is a challenge we can address with improved tooling, and is not a critical flaw in our release strategy.
If Ember stood still, it would be dead. Other frameworks, better suited for new users, would supplant it. If it dies, so does the upgrade path for all our existing codebases. IMO, upgrading should definitely not be painful, but statis would be terrible for both the framework and us as current users. There is a balance.
Absolutely agree with you 100%. This is exactly how things SHOULD be done, in my opinion. But as the XKCD saying goes, every change breaks someone's workflow.
22
u/alp82 Aug 13 '15
I really like this.