Every framework should take note: that's how you avoid creating another framework and fragmenting community!
It's is great to see this in action :). Amazing work.
As great as Angular 2 seems to be, by breaking compatibility to the point they did, they've essentially created another framework.
For someone looking to upgrade from Angular 1.x, this shifts their thought process from "should I upgrade to Angular 2?" to "which new framework should I upgrade to?".
And for many people, that new framework isn't going to be Angular 2.
That is an evolving story, which has changed several times before reaching that point.
That said, Angular 2's performance is already looking phenomenal, and assuming some of the stats I have seen out in the wild are to be believed, it can run over 30x as fast as some of the existing frameworks for large datasets, including angular 1. If I had to choose a library to use now, it'd be React, but if I had the opportunity to hold off upgrading, I would absolutely wait for Angular 2.
You can even apply the flux pattern to good effect within the directive while still making use of your existing Angular service infrastructure. Per Evans this would be an Evolving Order over a pair of Bounded Contexts.
Even though the Angular part wasn't very big at the time and the rewrite would not have been too costly, it would not have been wise to move to Angular 2 just to have them pull the same thing again for Angular 3.
Given how fast the frontend ecosystem is moving, we've tried to strike the right balance between delivering new features and taking care to ensure that we don't leave the existing ecosystem of apps behind.
I think you'll agree that if we did nothing, our community would slowly die off as people moved to competing libraries and frameworks that made them more productive. So total stability would feel good in the short term, but long term, having to do a wholesale rewrite of your app because the framework stagnated would be much more painful, right? (You can approximate this effect by locking yourself into an older version of Ember, which sucks! People rightfully want the new features.)
The goal of Ember's additive-only strategy is to deprecate features, rather than remove them. This is more work for the maintainers, but we think it's worth it because users can "refactor towards the future" at their own pace, amortized over the year and a half between major releases. Development teams have a natural ebb and flow, and that amortization of deprecations over the year means you can use lulls/downtimes to refactor the deprecations out when it's most convenient to you.
We made a mistake and rushed in a bunch of deprecations in 1.13 because it was our last chance to remove features for the next year or so. In retrospect, we got overzealous, and for that I am sincerely sorry. Users like you rightfully felt overwhelmed, and that is something the entire system is designed to avoid.
If there's a bright side, it's that your app should continue to work as you upgrade, and when you're ready to make the jump, you can upgrade to Ember 1.13 and refactor away all of the deprecations. Once that's done (whenever you decide to do it), you will be able to upgrade to the latest version of Ember 2.x, because Ember's SemVer guarantees means that a deprecation-free 1.13 app is compatible with any 2.x version (2.7, for example).
Sorry again that it's been a slog for you. Once you're through it though, we hope you enjoy all the new features, and we certainly hope the simplifications we've made to the framework over the last year make it easier for new developers to join your team and get productive.
Lots of marketing though. It's not really backwards compatible, they just like to claim things like that. If you say it doesn't work, well you must be doing it wrong. Very typical of Emberjs.
I really trust Yehuda and Tom's approach with Ember. Yeah there will be pain and breakage, but that's better than making a long-term commitment to the wrong thing. Over time it will converge (and I think it is already to a significant degree) on the right abstractions and then stability will come, but to do so prematurely leads to an inferior framework. If you need stability in your front-end then Ember (or god help you Angular) is probably not the wisest choice—I would even consider your options of just going server-rendered for current projects to give a bit more time for the ecosystem to mature.
This is a problem of platform maturity. The Web is moving too quickly for monolithic framework solutions to keep up. ES6, web components, shadow dom etc were not part of the landscape 12 months ago. Ember and Angular are both doing admirable work in all of these spaces, but they're leaving their users in their wake.
I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't, accepting that the web site is just a skin over your api, that needs to move with the fashion, so expect to replace it every 12 months, minimum... that doesn't go over very well with executives.
The jump to Ember.js 2.0 involves API changes, but I see no reason why the majority of application will not move forward.
Your experience sounds very painful, but many Ember applications, even ones that are over two years old, have already made it onto 2.0. That is not meant to trivialize your pains, but just to challenge the idea that we're leaving people behind.
Ember's 2.0 strategy is specifically designed to ensure as many people get to 2.x as possible. That is our goal. I'm rather proud of the number of mature, long-living codebases build with Ember that continue to progress with us.
> I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't
That is an option. The web, and single-page applications, offer unique advantages but like any platform also come with limitations. Companies like Yahoo, LinkedIn, Zendesk, Twitch, Bustle, and many others have placed big bets on this architecture though, and use it successfully.
Why is that obvious? I can think of several other frameworks that this would apply to. Drupal for instance, Yii is another and there are quite a few more.
According to some conversations I've had with folks, Drupal 8 seems to be even worse than Drupal 7, and Drupal 7 is literally the worst upgrade experience I've ever had. Piles of new jargon and new APIs get introduced in every new release, and often replaces or subsumes entire swaths of similar functionality in previous releases (e.g. nodes -> entities), and Drupal was already ridiculously jargon-heavy to the point of documentation making no sense to someone without extensive experience with the specific ways they use terminology, and googling generic terms like "node" and "entity" is a laughably unhelpful process.
I have, at many points in this process, thought: "Fuck everything about this, I'm migrating to WordPress." I probably should have done so the first time I thought that, as it would be done by now. But, every time I made it over another hump in the upgrade, I thought, "Surely that was the worst of it." and kept slogging along. Upgrading WordPress is literally a no-brainer, now...you just get emails every week or two saying, "Your website has been updated to the latest version of WordPress." Sometimes, you click the "upgrade database" button.
Sorry to rant. But, I happen to be working on my Drupal upgrade again today, so I'm grumpy.
So some folks were caught not being able to upgrade due to a crucial module being abandoned at 6.
But, the biggest problem I have is that even when there was a pledge to do so and when they actually eventually produced a D7 module (Drupal 7 is several years old...I spent most of this time waiting for the modules we rely on to become stable on Drupal 7), there wasn't a pledge to provide an upgrade path...so, you've got data in some module in Drupal 6, and no way to get that data into the same module in Drupal 7. Often there are bizarre workarounds, like using the Migrate module, which is designed to handle all sorts of migration tasks and is thus endlessly complex, and requires custom migration code (and comprehension of a huge swath of even more new jargon and convoluted, baroque, APIs).
It begins to remind me of Zope/Plone from many years ago, which had many of the same problems. Lots of jargon, lots of new ideas in each version before the old ideas were stable or fully implemented, painful upgrades, tight coupling of interfaces making changes in one part of the system require changes in every part of the system. A modular system is nearly meaningless, if every module has to be rewritten with every new release.
(now if I can get this damned rails gem to work properly....)
The issues with Yii and Drupal are a bit different. Yii is a serverside framework. And Drupal a CMS. I'd say the case with Drupal is way more problematic than Yii's though.
Properly handling deprecations and providing a clear and reasonable migration path for your users will keep them happy and will keep them upgrading instead of either sticking to old versions or jumping ship.
These are not concerns that apply only to front-end frameworks.
The "that's how you avoid creating another framework and fragmenting community" comment is pretty clearly about the angular mess last year, and rightly so. I have a love-hate relationship with Angular. It's been a complicated journey and at times handled poorly. They seem to be on a better track now.
Regardless, I don't think there was any malintent in nercury's post. They are all good lessons learned.
- The switch from symfony 1.4 to Symfony 2.0 requires a complete rewrite. Support for symfony 1.4 stopped fairly quickly; there seemed no understanding that companies wouldn't pay to rewrite their messy-but-working systems onto a 'cleaner' framework.
- MODX Content Management System. There is no upgrade path from 1.X to 2.X. Good luck to you if you've invested years developing your site on 1.X...
Ignoring that, this concept of backwards compatibility above all things is so strange to me. How modern browsers work has changed fairly dramatically over the last several years. Not to mention a major, major overhaul of ECMAScript.
And yet, every. single. time. we have something that mentions backwards compatibility being straight-forward, the top comment is always about how re-writing frameworks are bad.
I don't have a problem with the way the Angular team are doing things. Angular 1.x will be supported for a long, long time. And even though this hasn't been announced, I expect the 1.x and 2.0 branch to gradually merge, requiring minor changes to code at each minor version increase.
So effectively, Angular 1.4 -> 2.0 is no different than Ember 1.0 -> 2.0 with the caveat that 2.0 was planned in advance so all of the minor version changes will lead to 2.0, rather than 2.0 being the outcome of minor changes in 1.x.
None of these things broke the API; there was always a sane (although sometimes painful) process to help you through the upgrade. There are other things planned for the next few releases, such as routable components, new component syntax, etc. but the things they will replace (controllers and the old component syntax) will be supported through the 2.0 cycle (at least that's what's said).
Ember's deprecations in 1.13 were a bit of work for me, as a developer, but the new features in the past few months have done a lot of good to the framework and removed a lot of the complexity. I much prefer this way of upgrading, and I really, really appreciate the Ember team for doing it this way.