A couple weeks ago at ng-europe, the Angular team announced plans for a new 2.0 version which seems drastically different than the latest 1.3 release. There overall reaction was a wee bit on the negative side.

And so on.

While there has certainly been an uptick in vitriol since the Angular 2.0 announcement at ng-europe, this is not new territory for Angular. For much of the past 2 years, Angular has been a lightning rod for heated debate among front end developers.

If you need handholding with factories and providers and service provider factories then consider that the world doesn’t need your bullshit code and go and get a job you’re actually good at. Stop ruining it for the rest of us. from you have ruined javascript, 4/23/2014

Origins of Love and Hate

Many developers fall in love with Angular initially when they see how they can accomplish certain tasks with little or no code. The framework can seem magical (in a good way) for newbies.

This can be extremely infuriating to some Ember or React developers who feel that the newbies are being duped by the shiny object of two-way data binding which hides the true hideous nature of Angular. The typical anti-Angular rant usually includes one or more of the following gripes:

Subpar features (ex. routing, model layer)

Missing features (ex. server rendering, async loading)

Cumbersome and/or confusing APIs (ex. injection arrays, service/factory/provider, directives)

Fundamental design decisions (ex. working off the DOM, dirty checking vs KVO vs Virtual DOM, mutable data vs immutable data).

I think this tweet summarizes the anti-Angular sentiment quite nicely.

But, wait. Something doesn’t quite make sense. You would think at this point that no one in their right mind would use Angular, but in reality it has been the most popular front end framework over the past year. Does that just mean there are a lot of stupid and/or uninformed developers out there?

Angular Personas

One mistake I see time and again in blog articles both for and against Angular is that all developers are lumped into one. Let’s instead split up developers into three levels of experience.

Novice — Just starting to learn. Doesn’t know much. Veteran — Understands enough to write real apps and has started to experience some issues. Expert — Knows pretty much everything (good and bad) about the framework including how it stacks up to other frameworks.

There is no doubt that you see developers leaving Angular at each level.

Novice — This doesn’t make sense. The documentation is terrible. Code in HTML? Ewww. I don’t get Angular at all. Veteran — Ugh, this framework is terrible. It doesn’t do X and has issues with Y. Angular is fundamentally flawed. I’m out. Expert — Angular has brilliant parts and it is possible to create awesome web apps with Angular, but it just isn’t worth the trouble. I am going to use [React|Ember] instead.

But there are many more people that stick with Angular and love it. A cynic may make the following excuses for developers that love Angular:

Novice — This confused developer is being duped by shiny objects. Veteran — This developer may experience some problems, but they must not understand how bad it really is or they don’t know enough about alternative frameworks. Expert — This developer understands all flaws in Angular and is well aware of other options. So…perhaps they are just too emotionally invested in what they have been working on.

I think there is some validity to each of these excuses, but I also think there is a much bigger reason why developers at all levels love Angular. Namely, this:

<div ng-bind=”username” ></div>

I am not talking about the specific syntax here. I am referring to how Angular leverages custom attributes and elements in raw HTML. To some people, this aspect of Angular is especially heinous, but it is also why so many developers love it.

Novice — HTML? Hey, I know that. I don’t understand what transclude means, but all the Angular HTML I see makes total sense. Veteran — Check out this wicked sweet directive I just created. I love declarative programming and being able to create my own DSL in HTML. Expert — This is the future of all web development.

The Past and Future

Before we talk about the future, let’s take a step back and talk about the history of the web.

HTML and the web was originally designed for document exchange. While Brendan Eich got JavaScript to do some amazing things, it was severely limited when compared to desktop code. Extending the web platform at that time was difficult (i.e. impossible) since all the browser vendors were not on the same page (*cough* Microsoft), so there were numerous attempts to circumnavigate the web platform altogether (i.e. Java Applets, ActiveX, Flash, etc.). Not surprisingly since these attempts were usually driven by a singular vendor, they never stuck.

Then around 2010 something changed. I am not sure exactly what went down, but at least part of it was probably a result of Safari, Chrome and Firefox gaining market share on IE. Regardless of the reasons, all the major players started collaborating more effectively and eventually standards committees started actually making progress. We have already started to reap the benefits of this (Web Sockets, HTML5, CSS3) and there is a huge wave of new, exciting changes that will land within the next couple years including ES6, ES7 Async, Shadow DOM, Object.observe() and Web Components.

Read through all of these specs and think about what is going on. The way we build web apps today is very different than the way we built web apps just 2 years ago. I would argue that 2 years from now, the differences will be even more drastic as web browsers give more and more power to apps.

The future of the web, therefore, is going to be exploiting the web platform, not circumnavigating it. Take, for example, React. It is a wonderful framework which has many brilliant ideas. But, it is not designed for the web platform. It is designed to build HTML in the Virtual DOM and then push it to the real DOM. Actually using the real DOM or something like Object.observe() are React anti-patterns. That is perfectly understandable in today’s world with today’s limitations, but will it make as much sense in the future as the real DOM becomes more and more powerful?

Angular 2.0

Angular was conceived from the very beginning to enhance the existing web platform and give us features today that would hopefully be built natively into all browsers in the future. Well before ng-europe, Misko and Igor said on numerous occasions that they wanted Angular 2.0 to be built for browsers of the future. At ng-conf last January, Misko said point blank that 2.0 would be a complete rewrite. Even though the ideas for Angular 2.0 presented at ng-europe seemed like a completely different framework to some people, it actually better represents the core essence of “Angular” than the current version. In many ways, Angular 2.0 is what Misko was trying to achieve all along.

I have stuck with Angular despite its flaws because I love many of the higher level abstractions which includes HTML custom elements. More importantly, I know that the underlying mechanism which enables those abstractions will only continue to get better and better as the Angular hacks fade away to native browser functionality. 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.

If you believe in the future of the web platform, help us make Angular 2.0 a reality.

Learn about web components. See what other frameworks like Ember or Polymer are doing. Start thinking about how the apps you are working on today will change in the future. And, remember that the 2.0 design is not finalized yet. The Angular team wants to hear your opinions and feedback.

Addendum — Migration Path

As much as I already knew about the 2.0 plans at a high level before ng-europe, the one thing that really made me cringe was the apparent implication throughout the talks that the Angular team was “abandoning” the current 1.x version branch. Some people expressed anger that they wasted their time building on a version which cannot be migrated and will not be supported for very long.

The reality, though, is that Igor was really hesitant to say anything about a migration path from 1.x to 2.0 because he was afraid to give the impression that the transition would be painless. While I am sure it will be more painful than a simple incremental release, please understand that THERE WILL BE A MIGRATION PATH to Angular 2.0. I can say that definitively after talking with several core members and developers in the community who are committed to helping everyone move to 2.0 as painlessly as possible.

That said, realize that there is no migration path right now because 2.0 does not actually exist. There is nothing to migrate towards. My impression from numerous discussions is that the team is trying to work with the community to finalize the design for 2.0 first and then we can all work together to figure out the migration path. I realize that this approach is different than standard OSS protocol, but it does not mean the current version has been abandoned or that you won’t be able to migrate to 2.0.

Addendum II — Haters

One last point I want to make is that if you are working with OSS, you have to learn to love the haters. Besides the fact that they are often really funny (see Tom Dale), I really believe that the heated and passionate debate from different view points helps the web move forward.

Recently there has been a great little triangle of battles going on among Ember, React and Angular. The reason why these debates are so great is that each of the frameworks have various pieces that are pure genius (ex. Angular DI, React Virtual DOM, Ember Router) and it is not abnormal to see developers in one framework borrow the great idea from another framework (ex. Angular UI Router from Ember Router).

I also believe that is is healthy to question your own ideas and open yourself up to criticism from others. So, have at it. Tell me why I am wrong.