Why Angular has to break everything in the 2.0

There is a big controversy going on my Twitter account regarding the design of the new 2.0 version of Angular. I want to add my bit to the debate.

Summary of previous episodes

At the last big Angular conference (ng-europe) I attended, the Angular developer team announced the design of the next major release of the framework. For those who follow closely the news, it was not so much of a breakthrough. But for the whole community it was quite huge.

Indeed, it has previously been said that the v2 would be entirely rewritten “at least” in ECMA Script 6 and compiled (transpiled to be precise) in standard JavaScript. Miško Hevery announced in his keynote that in addition, they wanted to use annotations, types and introspection so, they would use their own superset of ES6 called AtScript.
It has also previously been said that the new version of Angular would embrace the WebComponents standards and that the “disliked” directives API would be replaced. They added at that very conference that this component’s philosophy will be central in the new version and the current controller focused approach will be removed.
The new design implies so many changes that I never imagined that Angular 2 would be backward compatible with the 1.x branch. It has been confirmed at the conference, but it was announced so roughly with big tombstones and church bells that it was a great shock for the community and not only by the Angular community. I feel that everyone who didn’t like Angular jumped on the occasion to have a new argument to criticise Angular.

Angular needs to be upgraded

As an Angular fan, I know that Angular is far from perfect. Any part which could be improved with backward compatibility for 1.X has already been improved or is about to be improved.
Lots of things could be improved, but at the cost of breaking compatibilities. Because Angular being massively used means that Angular is doomed to stay as it is and become an old monster that everybody uses but hates? Aren’t the major versions there for that use precisely?
To be precise, I’ll take an example: the directive API. It is the most complicated part for mastering Angular. Everybody complains about it, lots of the people who don’t like Angular are precisely repelled by this API. The advent of the Web Components will further highlight this weakness. So, I think that this API must be replaced by something better.

The WebComponents revolution

The WebComponents is the absolute keyword on the Web recently and everyone wants their frameworks to be “compatible”. But it seems that not so many understand how impacting complying to WebComponents can be.
Every framework has its way of defining components, some of them already have an API similar to the WebComponents’, but for others, sticking to the new API can lead to major refactoring which means breaking changes. Do you want your future framework to have a crossbred API allowing to do the same thing with two completely different ways to keep backward compatibility?
The API question is not the only one. The WebComponents forces you to approach your interface in an “all is component” way. It’s a major design orientation and lots of frameworks have not been created with this in mind.
For Angular, it’s already a complicated question. Angular supports a “view” approach with routes and controllers and another with a “component” approach with the directives. Currently, the view approach is preferred because the controllers API is so much simpler to use than directives but there are already people who are switching (How I’ve Improved My Angular Apps by Banning ng-controller) to an “all is directive” design.
This duality brings lots of pain because people keep asking “for this feature, should I use a directive or should I put it on the controller?” all the time. With the switch to WebComponents for the next major features, isn’t it legitimate to deprecate the “view” approach and the controllers to promote the new “components” design and avoid any additional confusion?
Angular 2.0 Core by Igor Minar & Tobias Bosch at ng-europe 2014

Resistance to change

This point is certainly more personal, but I can’t keep it silent. Isn’t all of this debate (not to say troll) a question of resistance to change? In our IT world where we should be used to changes, to always learn, it seems that we’re as resistant to change as in any other field.
This whole question is just about changing habits and learning the new concepts of Angular 2. All of the projects currently using Angular 1.x will not stop working. If you want to continue your project with Angular 1 or even bring new features to it, you will still be able to do it. Yes Google will, at some point, stop maintaining it, but this doesn’t break it. Other projects have a 1.x branch still living after the master switched to the 2.x, I think of PlayFramework of course.
When you start a Web project in JavaScript these days, do you really believe that your framework will be maintained for 20 years and keep backward compatibility on top of that? And if not, aren’t you prepared to keep using a framework not up to date anymore?
The whole open source thing is a great way to deal with these problems. You can fork the project if the evolutions don’t suit you. You can continue to maintain an old version if you want. Finally, you can just keep using the version you like with its sources. So why a framework like Angular should stop evolving to ensure constant backward compatibility?

The world hates change, yet it is the only thing that has brought progress. – Charles Kettering –

Respect of standards

My final point will be about the respect of the standards. When I started using Angular, some people said to me “Angular has its own ways and it will lock you with Google, I don’t believe their promises to keep up with the standards”.
The whole point of this big Angular 2 refactoring is to reinvent itself, to drop what is not needed in the framework and to comply with the new Web Components standards. So, in my opinion, Google is exactly following its promise even if it costs a lot to the framework.
Even if I look like a Google fan here, I want to say that I thank Google for keeping their word and preventing Angular from reinventing the Web and sticking to the standards.

AtScript

To counteract a little, the question of AtScript remains. I fully agree that using the latest specifications of the JavaScript to implement the new version is a great idea. As we’re able to transpile the code for all the current browsers, why should the developers bother writing with an old syntax?
But the choice of creating a new superset of JavaScript which we don’t know if it will be the orientation of the standards seems risky to me. We could even fear that Google will use Angular massive weight to influence the future of the JavaScript specification itself. AtScript can be the point which will drive Angular away from the standards.

Conclusion

As a conclusion, use Angular 1.x, don’t hesitate, don’t delay your project. Whatever the framework you choose, there will be something new next year. Start thinking in components if you want to prepare yourself for the future.
In the future, for your existing projects, keep using the framework you like, it’s still working even if there is something new out there. If you have a new project or the time and money to refactor, do it.
The Web evolves, it’s a chance, not a tragedy!