Telerik Developer Network

There are a lot of frameworks in the JavaScript world. This was true even several years ago, before it became de rigueur to have your own framework in order to join the elite, conference-speaker crowd.

Just a couple of years ago, it seemed as though Backbone was on its way to becoming the de facto framework for JavaScript developers. It was beating out more established frameworks like Dojo and keeping upstarts like Knockout and Ember at bay.

Then, seemingly overnight, things changed and AngularJS appeared to suddenly dominate any framework discussion related to JavaScript. I was running a popular site for developers (called Flippin’ Awesome, which is now called Modern Web) and it seemed that all any author wanted to write about was Angular. At the time, I thought Angular was just the flavor du jour and that the community would just as quickly move on. That didn’t happen.

Tooling and Integration

I think multiple factors led to Angular’s “dominance” being relatively stable. The first was framework fatigue. No one could realistically keep up with the rate of new frameworks, so it seemed the time was ripe to coalesce around a particular framework, and the fact that it was led by Google probably made it seem like a safer choice.

However, this led to what is probably the more important factor, which is the integration of Angular into other tools and frameworks. This made the decision to choose Angular easier, especially for larger companies. For example, Angular integration comes pre-built into frameworks such as Telerik’s Kendo UI, Ionic, Famo.us, Wijmo and others. IDEs including WebStorm/IntelliJ, Visual Studio, and NetBeans come pre-baked with features specifically for Angular projects.

The point is, all these integrations not only made the choice of Angular easier, but make leaving harder. It’s no longer just about the code I write, but Angular is tied into my entire development experience.

The Controversy

The Angular dominance has not halted the growth of competitive frameworks. Ember continues to innovate. React has gained a small but growing (and seemingly devoted) following. Projects like Meteor seem to be finding an audience, especially among those who are looking for JavaScript front and back ends.

I’d love to chart out relative interest in these frameworks using Google Trends, but it is hard to find specific search terms (i.e. React, Ember and Meteor all give irrelevant results, and searches of Reactjs, Emberjs and Metorjs, for example, barely register on the chart).

However, recently the Angular team has appeared to step into some controversy with some of the plans aired for Angular 2.0.

First of all, it is a complete rewrite, which, in and of itself, isn’t a bad thing. However, one of the key issues seems to be a potential lack of backwards compatibility or easy migration path. Here is a quote on that topic from Igor Minar (emphasis mine):

Our goal with Angular 2 is to make the best possible set of tools for building web apps not constrained by maintaining backwards compatibility with existing APIs. Once we have an initial version of Angular 2, we’ll start to work on a migration path for Angular 1 apps.

In coverage of the changes in Angular 2.0 announced at the ng-europe conference, David Iffland said:

Developers familiar with the Angular 1.X will encounter a drastically different looking framework and will need to learn a new architecture.

Based upon the video of the presentation from ng-europe, Jaxenter noted a basic example given illustrating how different the code may end up being. Below is the example in Angular 1.3 (taken from about 3:20 in the video):

<div ng-controller="SantaTodoController">
  <input type="text" ng-model="newTodoTitle">
  <button ng-click="addTodo()">+</button>
  <tab-container>
    <tab-pane title="Tobias">
        <div ng-repeat="todo in todosOf('tobias')">
            <input type="checkbox"
                ng-model="todo.done">
            {{todo.title}}
            <button ng-click="deleteTodo(todo)">
            X
            </button>
        </div>
    </tab-pane>
    ...

…And the same example written for Angular 2.0 (from about 3:26):

<div>
  <input type="text" [value]="newTodoTitle">
  <button (click)="addTodo()">+</button>

  <tab-container>
    <tab-pane title="Good kids">
        <div [ng-repeat|todo]="todosOf('good')">
            <input type="checkbox"
                [checked]="todo.done">
            {{todo.title}}
            <button (click)="deleteTodo(todo)">
            X
            </button>
        </div>
    <tab-pane>
    ...

A close examination of the code shows a number of significant differences, none of which seem to bring to mind any quick and easy upgrade paths (for example, the syntax for directives has completely changed).

What Does This Mean?

Much like the recent Renee Zellweger controversy, Angular developers seemed to be staring at something that looked mildly familiar and at the same time unrecognizable. While other popular frameworks have had breaking changes or complex migration paths, Angular 2.0 seemed so different that it garnered some harsh reactions.

For example, John V. Petersen says that Google has broken the OSS compact with Angular 2.0:

Clearly, 2.0 is a revolutionary step over 1.x. The Angular Team looking to capitalize and build upon Angular 1.x’s success. As such, the community that was praised at ng-Europe has a reasonable expectation to be kept in the loop. That’s the way you’re supposed to treat the community that makes up your development partner base. To me, it seems rather common-sensical. Why on Earth would a team want to disenfranchise the very community it relies upon and praises?

Reaction on Reddit to the Jaxenter post was almost unanimously harsh (granted, harsh comment threads on Reddit are common, but the unanimous unhappiness with the changes was still somewhat surprising). This comment by jbarkett was emblematic of the general feeling of commenters:

I honestly didn’t think it was possible for the Angular team to do anything in the 2.0 release that would turn me off. All of the talk of a real persistence layer with offline first capabilities and dropping support for old browsers to make way for new things sounded great.

This is a mess…the huge gap between this and 1.3 means those of us with real jobs where projects live for years and years have to back off. I can’t tell my boss that we’re going to build something incredible, but that we need to plan for a code only, no new features rewrite in 18 months.

Meanwhile other frameworks continue to innovate. For instance, this week alone featured a new release of Ember, featuring a revamped rendering layer, and a new release of React (and don’t forget the new Kendo UI beta).

This begs the question as to whether Angular can maintain its dominance. For example, in response to my tweet about the Ember release, Jason Marshall wrote:

@remotesynth given the bad news from @angularjs this week I’m very excited to see the HTMLBars work landing in EmberJS. Much nicer syntax.

—— Jason Marshall (@InnerJason) October 29, 2014

If enough of the syntax and functionality changes, moving from 1.3 to 2.0 will come with a steep learning curve. While Angular has some of the inherent tooling and integration advantages I discussed earlier, drastic changes could also make it difficult for tools and frameworks to maintain integration with 1.3, satisfying the majority of their audience, and 2.0, satisfying early adopters. Plus, at some point, if the migration is a complex one, you practically incentivize users to at least research alternatives, negating much of Angular’s inherent advantages.

And let’s not forget enterprises. Many were just in the midst of standardizing on Angular 1.3 only to see it seem to take a sharp turn that may affect their projects over the long term (and enterprises aren’t often known for rapid adoption). They may be hesitant to futher commit to the project if they lose trust in Google’s ability to lead it.

It’s still relatively early in the game, and the Angular team could take the backlash as a sign to alter their direction, or at least offer a simpler migration story. Also, admittedly, the actual long-lasting effects of a backlash of this sort can often be overstated during the heat of the moment. Nonetheless, it does appear as if Google has at least opened the door wide enough that a framework competitor could walk through.

I’d love to hear your thoughts.

• Share This:   
• Twitter
• Facebook
• Google+