So, here we are, starting with Angular 1.x, which seemed to be fairly pragmatically designed to solve certain pains and has received (IMO well-deserved) uptake in the ecosystem. Now, we are looking at Angular 2.x, where many of the decisions seem "academically" right, yet feel to me (and many of us) as practically disastrous.
This article is essentially saying: 'some kind of a migration path will definitely be worked on once we have a destination Angular 2.0, so stop freaking out.' Also this statement: ". If you are working on Angular 1.x today and you like it, you should want 2.0 to exist and you should be an active participant in making it happen."
Listen, we've been around the block and we've seen projects go through changes like these. And we've seen enough projects fail after changes like these, and we've seen enough 1.x branches wither in abandonment. And we've spent years now advocating for more incremental development approaches that validate decisions little by little. And so when Angular, as a project, decides to make huge changes, Angular tech leadership should understand this modern climate, and should make sure that the messaging touches on migration right away.
Look, I'd love to be pleasantly surprised, but I sure am skeptical that this will be a successful transition. It just doesn't sound like the Angular 2.0 project plans are grounded in reality of shipping production code and solving production problems. And I really think that's the root cause red flag that has everyone up in arms.
I hear what you are saying, but I think the big difference between Angular 2.0 and (for example) something like Python 3 is that the goals and direction of Angular 2.0 are directly aligned with the future of the web whereas Python 3 changes were changes just for the sake of changes.
In other words, the world of the web is going to change drastically over the next two years regardless of what Angular does.
Now, I do think there are other approaches. Take Ember for example. They plan on building on top of all the new features coming out, but they are taking a more measured, iterative approach. The thing is that just because it seems like a good idea for Ember does not mean it is a good idea for Angular.
Look at it this way. If nothing else, it is really awesome to have two big front end frameworks taking two drastically different approaches to achieve a similar goal. There are merits to the Angular approach, but it all comes down to execution.
As much as I am rooting for Angular 2.0, it very well could be a train wreck. But, that is why I am planning on being an active participant during the entire process and I will do my best to make sure that doesn't happen.
In other words, "If Angular is so bad then why do so many people use it, huh?!" See Visual Basic, PHP, the list goes on.
