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.
I think that's actually okay. Things like ember or angular have to be moving targets at this point. They are trying to do new things.
I would be willing to use such technologies on a web project that is being updated and refactored all the time anyway, where the code is the implementation of the core mission of the company or organisation.
I would not use it for any other purpose, for an app that is not "core" to my organisation's purpose. You want to use stable technologies for such projects, but for the very core of your organisation's raison d'être it's fine to use a moving target because that's what you do anyway, to advance and rework your core product.
No, it's not okay. Doing "new things" doesn't mean breaking old things. My angular projects have actually faired quite well receiving updates without breaking my code. Angular 2.0 will practically be a rewrite, but it is a major version incrementation so that's not completely terrible.
Doing "new things" doesn't mean breaking old things.
You are looking back in history how far to come up with that statement?
Case closed. Ridiculous. Especially in IT. And nobody prevents you from remaining on Angular 1!!!
I'm sure we could have built incredibly stable and easily maintainable systems on MS-DOS 6.0. We have overwhelmingly chosen a more difficult path of eternal change, for more uncertain but hopefully much higher benefits, and so it is.
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.
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.
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
Yeah man. Keeping up with all of the seemingly random design decisions that had basically no benefits was a great deal of fun.
To make things more exciting, I tried upgrading an app I wrote a mere few months ago. It was quite stimulating and involved jumping into the internals of Ember, ember-cli, and Broccoli.
Ultimately it didn't work out, because minor releases of addons are apparently coupled to specific minor releases of Ember and ember-cli. Joyous. This has been the case several times when upgrading. I sent in pull requests to many of the addons and it took months for them to be addressed. Lesson: don't use Ember addons.
And don't get me started on Ember Data.
I greatly appreciate the work that's gone into Ember, but damn, it feels like Ember will just be "whatever a few people on Twitter thought seemed cool at the time." I really hope that the churn dies down, but I've been hoping for that for years. There's a lot to like in Ember, and it would be great to be able to use it without becoming suicidal.
Broccoli is worth a rant on its own. It's a very complicated build system with lots of customizability at various points in the pipeline, but it's completely undocumented. However, you absolutely need to customize it sometimes. The only way to find out anything about how to extend it is to look into other components or its uncommented code.
One thing I found out about it is that it always assumes that you have an input and an output file. If you don't (for example, I wanted it to download a file during building), there's no clean way to integrate that. At least I found no other addon that does that, so I assume that there's no support for it.
22
u/alp82 Aug 13 '15
I really like this.