Can AngularJS Maintain Its Dominance?

angular_dominance_header

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.

Angular Interest Over Time According to Google Trends

Angular Interest Over Time According to Google Trends

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).

Update 11/3/14: There is some ongoing discussion about the impact of the proposed syntax and how they might be better addressed.

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:

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.

Comments

  • Nick Foster

    It took me months to introduce Knockout to my team who were used to building enterprise apps with ASP.NET MVC. I had been looking at Angular 1.x and thinking whether it was worth convincing them to start using that, but with 2.0 looming and so drastically different, I can’t justify getting my devs to learn a framework that’s about to head into maintenance mode.

    Maybe when 2.0 is out it might be worth picking up, but I think the Angular team have lost a lot of trust with devs by making such dramatic changes. Time will tell I guess.

    • I agree. They are not only changing syntax but a lot of the techniques too. Plus if you want to start with 2.0 you would lose a lot of modules and tools that are currently integrating with Angular. You’d start from scratch and i’m not sure if that is the best option. I think going for ES6 is also way too soon as current browsers are hardly supporting anything from it. You need capable browsers before you are going all-in on a new technique.

      • Rick Jolly

        You’d transpile ES6 which is no big deal since you’re running a preprocessor for a number of other things anyway.

    • Kyle Hayes

      We decided this very thing yesterday as well. If 2.0 was out now, or going to be out in the next month, we would consider it. But we are not going to write any new code in 1.x.

      • tonypee

        I don’t understand why people are so down on 1.x it is perfectly functional now- and has planned support in the visible future. Angular 2 is not out, and probably won’t be mature for over a year. What will you use instead? all technology is evolving. It is great to see them innovating

        • Shien The Kid

          Two words: maintenance mode.
          That’s more than enough to drive 99% of developers away from a framework.

          • Boris Okunskiy

            That’s right. More than enough for me, that’s for sure.

    • Greg Bishop

      YES! This is the problem. “With 2.0 looming and so drastically different, I can’t justify getting my devs to learn a framework that’s about to head into maintenance mode.” you can’t change the HTML syntax on us like this. You just can’t. It will demolish all future development in angular till 2.0 is fully resolved. It HAS to be identical, you can have an ALTERNATE syntax, but not something this horrifically unsupportable and not-backwards compatible. Like it or not google you ARE CHAINED to the syntax exposed in HTML like Prometheus chained to a rock. To act otherwise is to essentially kill all 1.X support, and create only FUD about any 2.0 solutions for several years. I can’t understand why you think this is OK to do in any way.

      • Steve Gentile

        I think if your team can’t convert the syntax of button ng-click=”deleteTodo(todo)” to button (click)=”deleteTodo(todo)” then I think you might want to consider staying away from these SPA frameworks

        • elavoine

          Why would you say that? It’s not about converting an ng-click to a (click) or whatever it is. This is a more profound problem. It’s a matter of trust now. What are my guarantees that 2yrs after 2.0, they won’t come out with another 3.0 that has nothing to do with the previous. Django framework has been out there for almost 10yrs now. Still the same philosophy. Almost no big breaking changes. Why couldn’t the angular team do the same? Why couldn’t the angular team stick to incremental changes. Improving the core (speed…) before even touching any public api?

          • Trevor

            I assume by ‘matter of trust’ that people want stability in the frameworks they choose to use. If that’s the case, then going to a project that’s headed for maintenance mode seems like the best option (and you don’t even have to update your syntax when sticking with the same framework you’re already using–double bonus!). I really think Angular gives us the best of both worlds at this point. We have the tried and true Angular 1.x, for people needing a stable platform, and Angular 2.x for people ready for the cutting edge.

        • Ulises Ramirez-Roche

          Nah, only if you’re working on some small project of no real significance would it be that trivial.

        • metz2000

          You don’t seem to worked on any migration project yet. These are extremely challenging in strongly typed compiled languges too, and even more in loosely type languages like javascript. Sure any junior dev can write a regexp for the line you quoted, but there are lot more changes and not only in syntax so is impossible to do such migration automatically.

          Angular is a very young library, enterprise projects should avoid it until there are more major versions released, especially projects where customers are using older versions of IE.
          Not to mention that Google dropped support for many bigger projects already, who guarantees they’ll still support Angular in 6 months time, or maybe they fork like did with webkit. It’s yet another facade to improve their image and get more mentions.

          • Steve Gentile

            No I haven’t, surprised anyone has since 2.0 isn’t out yet. We used 1.3 and are looking at migrating to 1.4 with it’s new router when ready. We have a fairly large project and 1.3 has been a tremendous success for us. I don’t always think you have to jump on a bandwagon and ‘migrate to 2.0′ at the whim of a new point version. Just like the router update, these alone are incremental updates. When 1.4 comes out, we move to it. When 1.5 comes out we perform updates. I dont’ think moving to 2.0 is some ‘requirement’ that ‘every project MUST move up’ mentality. Angular 2.0 is a new framework – not something you ‘migrate to’, but something you decide to use for the next project. Sorry your stuck migrating from 1.x to 2.x already.

          • metz2000

            I wasn’t writing about migrating to Angular, it was a general comment about migrating from language A to language B, because the planned changes in A2.0 are more like a new language compared to A1.x. On the other hand Angular 2 already exists so it’s possible that someone already tried migration from 1.x to 2.

            You got the point with “Angular 2.0 is a new framework”. Basically everyone who uses Angular 1.x invested into a framework what will be discontinued soon (in enterprise terms 2016 is soon, 1-2 major releases only). So what’s the point in continuing using Angular 1.x?
            Everyone who hasn’t invested much yet would be better off if they’d move to another, more mature and stable framework after they ship their current release.
            Of course Angular 1.x will be available for a while, but there won’t be updates and bugfixes will be less and less too. Google doesn’t like old things to hang around, and there’s nothing forcing them to maintain previous versions of Angular.

          • Scott Busche

            Where are you getting these dates from? As they said at ng-conf, they will continue to focus resources on Angular 1.X until Angular 2.X is more popular, including Angular 1.5 and 1.6. In the mean time they’ve offered two upgrade paths, incremental using the new router or big bang, which is the complete rewrite you’re saying it has to be. It’s fine that you don’t want to upgrade, but providing misleading information does a disservice to others.

            Source: https://scotch.io/bar-talk/the-best-news-from-angulars-ng-conf-2015 (or any article on ng-conf 2015)

          • metz2000

            2016 is from Steve Gentile’s reply on this page and I don’t see any other value in my reply what could be interpreted as a date. We’re not using Angular so will not be affected by these changes.
            “More popular” is a flexible loose term, especially if will include number of downloads. The point is that if this is the only contract for maintenance of 1.x it can be ended any time by Google.
            Realistically: resources will be focused on 2.0 otherwise will never get popular. Ppl will start using 2.x, tons of bugs will be raised and soon there will be no devs left to work on 1.x.
            Will this happen? There’s no way I can tell, but is a possible scenario.

          • Scott Busche

            Where are you getting these dates from? As they said at ng-conf, they will continue to focus resources on Angular 1.X until Angular 2.X is more popular, including Angular 1.5 and 1.6. In the mean time they’ve offered two upgrade paths, incremental using the new router or big bang, which is the complete rewrite you’re saying it has to be. It’s fine that you don’t want to upgrade, but providing misleading information does a disservice to others.

            Source: https://scotch.io/bar-talk/the-best-news-from-angulars-ng-conf-2015 (or any article on ng-conf 2015)

          • metz2000

            2016 is from Steve Gentile’s reply on this page and I don’t see any other value in my reply what could be interpreted as a date. We’re not using Angular so will not be affected by these changes.
            “More popular” is a flexible loose term, especially if will include number of downloads. The point is that if this is the only contract for maintenance of 1.x it can be ended any time by Google.
            Realistically: resources will be focused on 2.0 otherwise will never get popular. Ppl will start using 2.x, tons of bugs will be raised and soon there will be no devs left to work on 1.x.
            Will this happen? There’s no way I can tell, but is a possible scenario.

          • Scott Busche

            Where are you getting these dates from? As they said at ng-conf, they will continue to focus resources on Angular 1.X until Angular 2.X is more popular, including Angular 1.5 and 1.6. In the mean time they’ve offered two upgrade paths, incremental using the new router or big bang, which is the complete rewrite you’re saying it has to be. It’s fine that you don’t want to upgrade, but providing misleading information does a disservice to others.

            Source: https://scotch.io/bar-talk/the-best-news-from-angulars-ng-conf-2015 (or any article on ng-conf 2015)

          • metz2000

            2016 is from Steve Gentile’s reply on this page and I don’t see any other value in my reply what could be interpreted as a date. We’re not using Angular so will not be affected by these changes.
            “More popular” is a flexible loose term, especially if will include number of downloads. The point is that if this is the only contract for maintenance of 1.x it can be ended any time by Google.
            Realistically: resources will be focused on 2.0 otherwise will never get popular. Ppl will start using 2.x, tons of bugs will be raised and soon there will be no devs left to work on 1.x.
            Will this happen? There’s no way I can tell, but is a possible scenario.

          • metz2000

            I wasn’t writing about migrating to Angular, it was a general comment about migrating from language A to language B, because the planned changes in A2.0 are more like a new language compared to A1.x. On the other hand Angular 2 already exists so it’s possible that someone already tried migration from 1.x to 2.

            You got the point with “Angular 2.0 is a new framework”. Basically everyone who uses Angular 1.x invested into a framework what will be discontinued soon (in enterprise terms 2016 is soon, 1-2 major releases only). So what’s the point in continuing using Angular 1.x?
            Everyone who hasn’t invested much yet would be better off if they’d move to another, more mature and stable framework after they ship their current release.
            Of course Angular 1.x will be available for a while, but there won’t be updates and bugfixes will be less and less too. Google doesn’t like old things to hang around, and there’s nothing forcing them to maintain previous versions of Angular.

          • Steve Gentile

            No I haven’t, surprised anyone has since 2.0 isn’t out yet. We used 1.3 and are looking at migrating to 1.4 with it’s new router when ready. We have a fairly large project and 1.3 has been a tremendous success for us. I don’t always think you have to jump on a bandwagon and ‘migrate to 2.0′ at the whim of a new point version. Just like the router update, these alone are incremental updates. When 1.4 comes out, we move to it. When 1.5 comes out we perform updates. I dont’ think moving to 2.0 is some ‘requirement’ that ‘every project MUST move up’ mentality. Angular 2.0 is a new framework – not something you ‘migrate to’, but something you decide to use for the next project. Sorry your stuck migrating from 1.x to 2.x already.

        • metz2000

          You don’t seem to worked on any migration project yet. These are extremely challenging in strongly typed compiled languges too, and even more in loosely type languages like javascript. Sure any junior dev can write a regexp for the line you quoted, but there are lot more changes and not only in syntax so is impossible to do such migration automatically.

          Angular is a very young library, enterprise projects should avoid it until there are more major versions released, especially projects where customers are using older versions of IE.
          Not to mention that Google dropped support for many bigger projects already, who guarantees they’ll still support Angular in 6 months time, or maybe they fork like did with webkit. It’s yet another facade to improve their image and get more mentions.

      • Adrian Lopez

        That is the same reason why i came back from Dart. Google languages are too volatile right now.

    • Steve Gentile

      It’s not ‘drastic’ – declarative bindings, web components – how is that ‘drastically different’. Yes, it will use ES6, and yes, it will be in 2016. Perhaps a good exercise for your devs is to use something like Traceur, or 6to5 and start learning next generation skills now. But if you can’t tell the difference between ‘ng-click=foo()’ and (click)[foo()]’ (or whatever it is) – then there are bigger issues at hand. I find it interesting that the Microsoft stack devs here can’t seem to handle 2 year technology releases, I’m guessing we have some webform devs who need shielding from html/js ?

      • Denis Peroni

        I have no problem with ES6, actually I am glad it has started to be incorporated in js frameworks. But I do have problems with AtScript, aka Let’sDoES4AllOverAgain. I have spent years learning and teaching “the good parts”® of javascript. I like Angular and I have used it in many personal and professional projects, so I am really worried its future is going to be built on a “language” that misses the point of js to such a great extent.

        • Steve Gentile
          • Denis Peroni

            Thank you, I have read many design docs for angular 2.0 and AtScript but I missed this one. However I am still worried that AtScript is used in angular core code as I believe it resembles more ES4 than ES6. While I can certainly develop my webapps in plain js (whichever version I see fit), the language used for the framework is not a secondary concern as it will inevitably influence angular users.

          • Alex

            I’m very hopeful that the combined efforts of Microsoft and Google along with a popular framework will finally allow language extensions like TypeScript and AtScript to become mainstream. I believe the delay in the addition of the structures ES4 provided has set back the web a great deal. When it comes down to it, large applications were easier to build in ES4. And learning new libraries and sharing code is much easier with types.

      • Antoine Lucas

        2016. You’re dreaming.
        how long d you think it will take to
        1 – Develop new CSS farmework based on web components?
        2 – Adapt all the current angular related Github project as foundation, bootstrap, and others.
        3 – Get a stable version of ECMA 6

        Angular became ultra popular from version 1.2. I bet Angualr 2 will become very popular at version 2.3. We’ll come back in 4-5 years, and we’ll see if I am doing stupid unrealistic predictions.

    • Antoine Lucas

      I don’t think angularJS 2.0 is that an issue. The 1.* branch will be maintained, and when I see the improvement between 1.2 and 1.3, I am absolutely not scared for the future, as we’ll see 1.4, 1.5, till 1.9.
      Don’t forget that 1.3 is a major release as well, with drop of support for IE8, a real FORM validation support and huge performance gains.
      Don’t think of angularJS 2.0 as the successor of 1.3, but more as a new technology that will be ready for stable production in minimum 5 years. How long do you think it will take to have ES6 supported on every browsers? AngularJS 2.0 is based on ECMA 6 which is not even developed yet.

    • Antoine Lucas

      I don’t think angularJS 2.0 is that an issue. The 1.* branch will be maintained, and when I see the improvement between 1.2 and 1.3, I am absolutely not scared for the future, as we’ll see 1.4, 1.5, till 1.9.
      Don’t forget that 1.3 is a major release as well, with drop of support for IE8, a real FORM validation support and huge performance gains.
      Don’t think of angularJS 2.0 as the successor of 1.3, but more as a new technology that will be ready for stable production in minimum 5 years. How long do you think it will take to have ES6 supported on every browsers? AngularJS 2.0 is based on ECMA 6 which is not even developed yet.

  • Pingback: Dew Drop – October 30, 2014 (#1888) | Morning Dew()

  • BlessYAHU

    I’m honestly glad I didn’t invest any time into learning Angular 1.x. Maybe I should wait till rev 3, like I do with some Microsoft tools. 🙂

    Though this post (http://blog.andyet.com/2014/10/30/optimize-for-change-its-the-only-constant) throws some jabs, it makes a good point: Modular (design/frameworks) are more flexible.

    Modular FTW

    • matt4446

      Having

  • Roland Zwaga

    Well, they do add this at the end of the quote:

    “Once we have an initial version of Angular 2, we’ll start to work on a migration path for Angular 1 apps.”

    So, judging by that, they will offer a migration path, so I’m not sure if moving to Angular 2.0 will require a 100% rewrite. Perhaps they’ll create some sort of legacy adapter layer that will allow large projects to upgrade gradually.

    Anyways, I guess its too early to tell, let’s wait and see what they come up with.
    I’m gong to chalk this down to bad PR on the Angular team’s side….

    • Greg Bishop

      I hope you are right, but these syntax changes look like angular is going to mess up our clean HTML.

      • Steve Gentile

        I suggest your team start to learn ES6 in general – that will be a far bigger learning curve than these trivial html declarative coding differences.

  • Shawn Wildermuth

    It’s a year too early to panic… See more what I have to say on my blog http://wildermuth.com/2014/10/29/It_Is_Too_Soon_to_Panic_on_AngularJS_2_0

  • While I’m all for breaking changes when there’s danger of legacy getting in the way of innovation, the frightening level of inconsistency here is giving me second thoughts about going forward with this framework. Three different bracket styles (up from two). Two different directive styles (ng-click becomes click but ng-repeat stays the same? what?).

    I was looking forward to 2.0 in the hope that they would be making things simpler for me. However, all I see are changes focused on making things “easy” for them (parsing on their end becomes easier when we do all the hardwork of identifying what’s an attribute(square brackets) and what’s an action(parantheses)).

    They should instead be doing the opposite and strive to remove complexity from our end helping us do more with less. If any angular core dev is reading this, this video[1] by Rich Hickey on the difference between Simple vs Easy should be an eye-opener.

    [1] http://www.infoq.com/presentations/Simple-Made-Easy

    • Steve Gentile

      Actually, it was because of IE that they didn’t use [ ] in the first place – that was the Angular teams first desire – so now that this isn’t a limitation, they are moving on it. It’s a great move for them. It’s a minor change, the bigger changes are related to ES6.

  • Steve Gentile

    So, the arguments against it is someone who thinks they have to run out and upgrade the moment a new version comes and they are upset about it. Angular 1.3 will be relevant for all those tasked to support older browsers, etc… and be around at least until 2016, and will go out even further! And there is a statement, whether it will be relevant in 2016, that in the future they will work on a 1.x to 2 migration, it’s just not something they are worried about now (and shouldn’t be). People who are like ‘oh glad I didn’t use 1.x’ – well, you can sit on the sidelines forever and always say ‘glad I didn’t use xyz’ – but for those using it, it’s been a great experience, it’s a very productive framework! I used Knockout, I learned how SPA frameworks work, and I can use any of them now. Name a single SPA framework that won’t be different in 1-2 years – ie. I’ve followed Ember and it’s constantly changing, every .x release broke things in it. It’s the way these things work. If your afraid of change, your probably in the wrong business 🙂

    • 1.3 needs support far past 2016 as most browsers which are currently shipped with devices will probably not be replaced by new ones. Especially mobile devices are not gonna be upgraded as soon as they were before.

      Not everybody is working on something that will be getting continuous development. And when you have to support things on the long run or have to support older devices, AngularJs 2.0 isn’t going to work no more. This will result in less big-projects for Angular and can effectivly kill of Angular (you need big projects for your framework to stay around).

      You will also lose support of many modules. Start from scratch. Why would i start with something from scratch these days? I want to use things others have already developed and 2.0 keeps you from doing thiat. And you can bet your ass that 2.0 will require a lot of bugfixes and commits before it is ready so you are looking at a period of 2 or even 3 years where not much will happen. Other than people will be waiting and saying “just wait, it will be better soon”

    • Amezick

      And now every google search for Angular [thing i need help with] will have solutions for the wrong version.

      • Mike McElroy

        LMGTFY Angular 2.0 [thing I need help with]

        • An0nym0usC0ward

          That’s assuming that ppl posting solutions, tips and tricks or workarounds don’t forget to mention the angular version. For one, mostly everything already posted about angular doesn’t have an angular version attached.

    • Juan Antonio Navarro Jimenez

      “I’ve followed Ember and it’s constantly changing, every .x release broke things in it” There is a reason why we don’t use Ember. Why not a LTS like Ubuntu ?. Time to improve, time to learn and time to upgrade. I think Google team must use all their efforts to solve the almost 800 issues of current version.

      • Steve Gentile

        it’s open source, the community will solve it, it’s not dead – that is what OSS is about

        • An0nym0usC0ward

          Have you looked at the code? I wouldn’t want to maintain it.

    • Brandon Wilhite

      No, the argument against it is that I cannot tell my enterprise project sponsors that we should use Angular and then turn around and tell them it will be unsupported in 2 years. I *may* be able to explain that things evolve, you have to think about life-expectancy…yadda-yadda. But the most likely outcome of that is having their eyes glaze over and they go an entirely different direction (WinForms anyone?).

      • Steve Gentile

        First off, Angular 1.3 will be around – it’s a very stable platform and works on older browsers. Where does it say the open source 1.3 will not be supported ? On top of that 2 years is quite a bit of time as far as technology goes. Lastly, the response given was that there will a path of 1.3 – 2.0 after 2.0 comes out. That is very reasonable. Your 2 year old app at that point probably will be in production (gee we hope) and the desire to push it to 2.0 in early 2016 would be quite risky, even if it had an ‘upgrade’… I want to see 2.0 be ‘the future’ – this is future vision to provide a next generation platform. Current generation (ES5, older browser support, data-*, etc..) works well, but they are looking forward. 2.0 is targeting ES6, evergreen browsers, new binding, etc… it’s a great move forward. As someone who has built apps in Knockout, Durandal, and Angular – there are core fundamentals that once learned will apply to any of these frameworks, so there is no ‘lost cause’ here.

        • Brandon Wilhite

          Y, I get all of that, and I have also built apps with multiple frameworks. It’s truly not about the learning curve at all. But just as I can’t say “use Durandal” (b/c the creator went over to Angular and it is now essentially a dead-end)…I can no longer just say “use Angular” and then in the next breath explain that Angular will be drastically changing at the end of 2015 (because that’s the part they will focus on). That’s just a discussion that is likely not going to go well. If Angular 1.x is not a dead-end b/c the community will help solve the problem…well, I’d say the community needs some leadership and a word or two from Google on this might go a long way. Maybe they could do us all a favor and hand 1.x off to someone else. Maybe it’s just messaging with all of this, but the Angular team really stepped in it if that’s true.

          The learning curve is an issue when you are thinking about teams of people, and it is a real issue so please don’t ignore it. But the issue outlined above is the more concerning one for me.

          • Steve Gentile

            The biggest issue is the move to ES6. I just realistically can’t see any of these frameworks not going through some big changes as ES6 matures can you ? I see a team looking forward and saying ‘in 2 years we will be out in front of ES6’. Maybe instead of Angular 2.0 they should have called it something else 🙂 Because regardless of the name, it’s great to see devs preparing for the inevitable future of ES6. I 100% agree and hope as well that for many devs who need to support older browsers – Angular 1.x needs to be taken over by the community. SPA frameworks are extremely new and volatile and I don’t *think* until we get to ES6 that will truly start to mature.

    • An0nym0usC0ward

      🙂 Look at qooxdoo – it’s largely unknown, because the company sponsoring its development has no interest at all in marketing it. It has not had a single breaking change in more than ten years, yet it managed to keep up with all technology changes, while continually upgrading its implementation as technology evolved. (They still have outstanding support for legacy browsers, though.) And all their releases are accompanied by automatic migration scripts for old code – scripts that work, because they test them on a large number of projects maintained internally by 1&1 before any public release.

      When you design an API (which is what a framework should be – a collection of interfaces on top of which you can build your application), you design it from the point of view of the API user’s needs, not the technology you want to put it on top of. I highly doubt that the needs of web devs have changed so much over just a few years that the Angular devs had to come out with a completely different interface. IMO the reason is that they designed a less than optimal API initially, and now want to correct the API, not the implementation itself. If they are unable to keep interface and implementation separated, they’re not the right people to develop a framework, and shouldn’t be trusted to do a better job with v2 than they did with v1 – they’ll probably design yet another broken interface, but one that’s broken in a different way. Just my opinion.

  • javawerks

    … if they lose trust in Google’s ability to lead it… Why would anyone trust Google? This is not the first time Google has left developers in the lurch. And it won’t be the last.

    • Yeah i wouldn’t be surprised if 1.3 gets forked and 2.0 will become a totally new framework. Currently Google is working on both Angular as Polymer and i doubt Angular is gonna win that.

  • Juan Antonio Navarro Jimenez

    Reactjs deprecate some apis but you can still use them and upgrade when you want. AngularJs is changing everything. Is a new framework, new language (atscript). For companie’s development teams could be a nightmare.

    • Phil

      Yeah, its like the maintainers are looking at shiny new tools and no caring about the guy who has to maintain a truckload of the current things.

  • Mike Park

    I think it’s worth also considering that 2.0 has a story for seamless web components integration. How will the other frameworks add or integrate with web components?

    • They will eventually but web components are not even supported properly in current browsers (even the standard isn’t nearly finished yet), so how can you talk about already integrating it? Some people actually need backwards compatibility and moving for 2.0 is way too fast.

    • Steve Gentile

      I don’t think it would too hard to guess that if you use a web component framework (aka . polymer), and use that for your directives today that you’d have a decent upgrade path when Angular 2.0 supports web components at the core.

  • Kyle Hayes

    Kyle Hayes

    Innovations and changes are going to happen all the time and they should. The web development community is an extremely volatile one. But when big companies who offer popular toolkits like Angular make it hard to move to the next version, it seems big headed. Enterprises who adopt these frameworks cannot move as quickly to make drastic changes to long term supported codebases.

    • Steve Gentile

      The mistake of past frameworks is they try to retain the old. Eventually they must move forward. Those ‘enterprises’ can’t move quick anyway, they sitting on old code bases today as it is. That isn’t changing because of what Angular does. Angular 1.3 supports what those ‘enterprises’ need today. Angular 2.0 will be for evergreen browsers. Even if Angular 2.0 ships in 2015, my guess is your ‘enterprise’ will finally move from IE7 to IE9 – lol I find it ridiculous that you and others thing modern javascript frameworks need to coddle big enterprises who move at a snails pace. I suggest maybe your teams just stick to server side tech with some jquery sprinkled in

  • Phil

    My two issues with Angular.js is that its trying to be all things to all people (like Windows OS) rather simply a binding framework like knockout.js and the maintainers do not have enough concern for people who have to maintain pre-IE8 browsers. Not everyone have the privilege of always using the new shiny tool or have their end-user use Chrome browser which updates every 6 weeks. If I do use Angular.js, its would be because its required on a job rather than me being a fan. I am a fan of knockout.js’ simplicity and focus and will stick with it as long as I can.

    • AlienWebguy

      KnockoutJS sucks. The I/O is terrible and all it does is binding, whoop-de-doo. ko.toJS(), ko.fromJS()…is foo an observable? foo here, foo() there… garbage.

      • Phil

        It is a has util functions and other things but it just really does one thing and does it well. Angular like jQUery tries to give you the kitchen sink and the chef when all you need is a spoon. We will never agree so let’s just leave it at that. To each their own.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1727()

  • ripvannwinkler

    This is a classic case of developers who want to innovate for the sake of innovation, rather than usefulness. The Angular team has produced a marvelous product in its current state, but adopting a completely incompatible roadmap heading forward is a surefire way to alienate current advocates. It’s framework suicide.

    • Peter Drinnan

      And also a big blow to their reputation. I think a lot of developers trusted the direction, but now it seems totally unpredictable.

  • rtpHarry

    People are mainly complaining about the upgrade path. The first quote I see from the team says “Once we have an initial version of Angular 2, we’ll start to work on a migration path for Angular 1 apps.”

    If the compiler can interpret it then surely a conversion tool can be created to do the majority of the heavy lifting?

    • Kabram

      It would be a first – never seen that successfully done in 20 plus years.

  • Pingback: Dew Drop – October 31, 2014 (#1889) | Morning Dew()

  • Kabram

    The Osborne effect:
    Q: Why would a new project use AngularJS 1.3 now?

    • Steve Gentile

      first off, Angular today can use polymer. Polymer represents a wrapper around web components. Polymer is a library, Angular is a framework. If you write your directives as polymer then you would be in a good place for Angular 2.0 since it would be using web components as well. I don’t see how these tech stacks are mutually exclusive

  • Tony Garcia

    As someone who hasn’t used Angular for any ‘real’ development but was planning on using it on a small project at work in order to introduce its use (for future larger projects) to the team, this has certainly soured me to the idea. Why should we start building stuff in the near future with 1.X when it’s essentially going to be deprecated in 18 months? I’ve been getting turned on to ReactJS recently and I’ve decided to use ReactJS/Backbone for that small project instead.

    • Rick Holland

      Agree, just started a MEAN stack prototype at work and recently stumbled on this Angular 2 story. Think I will mothball it and maybe pitch it to management late next year.

  • Jeff Buhrt

    Having used XUL-like engines/motors, lead various sized development and R&D teams, and been a public domain maintainer it doesn’t seem that scary. The 2.0 can/should start as a what should it really look like knowing what we know now. A couple options to bridge include a simple tool to static, one-time convert the old code to run in the new 2.0 core or a dynamic layer that could just run the old 1.x code in the new 2.x environment. Having fought through a couple battles over the last 11 years like a one XUL motor team torn between ‘next cool thing/do whatever’ vs those trying to use it for production then getting stuck where iOS is not an option, native builds drop, developers drop off and about everything needed falls either to your staff and a few remaining devs; to Adobe Flex’s v1/v2/ and somewhat v3 where we would spend days to a week to just make something basic work a little different vs doing customer focused work, Angular is a lot more sensible so far. Again, I would suggest saying ‘hey, something backward compatible is important’, but allow thought into a simpler/improved syntax needs to be explored. At least from the simpler example above, the core just ignoring tags in a relaxed mode might be enough with some basic syntactic glue.

  • Dave Hoff

    Honestly, by the time 2.0 is released React and the FLUX pattern will more than likely have the same adoption/popularity Angular has now. Why? Because client side MVC blows regardless of the framework. React/Flux is an actual game changer, the likes of which we haven’t seen on the front-end since jQuery. Big, opinionated, monolithic frameworks are fads. Viva la libraries!

    • Sam Levin

      Dude, I’m using Angular 1.2.x right now, and I recently started looking at React and Flux. They look incredibly legit, and support isomorphic webapps. Seems like the next gen, and if they don’t ‘completely rewrite’, then it seems as if they’re gearing up to be AngularJS’ successor

    • Sam Levin

      Dude, I’m using Angular 1.2.x right now, and I recently started looking at React and Flux. They look incredibly legit, and support isomorphic webapps. Seems like the next gen, and if they don’t ‘completely rewrite’, then it seems as if they’re gearing up to be AngularJS’ successor

  • Julio Garcia Sacristan

    I actually like Angular a lot but in spite of the efforts of Mr. Gentile I am very worried. Angular 2.0 not only changes the template syntax, $scope is out, controllers are out, and there is a completely new way of rewriting directives so I am very skeptical about having a workable upgrade path. Besides, Angular 2.0 not only breaks compatibility with 1.x but also with the web, the new template syntax is not HTML compatible, and AtScript is not JavaScript 5 or 6. They are practically inventing a new markup language and a new programming language of their own to run the new version of their framework. I don’t care how big and mighty Google is, the web is what it is because of open standards, going against them seems like trouble.

  • Ciel

    Would be great if Telerik could stop sending us mixed signals regarding its support and plans for Angular. This is getting very tiresome – you roll out Angular support in Kendo, but now have other people within the company talking it down. It does not instill confidence in using your own products.

    • remotesynth

      Thanks for the comment. I think you are reading a bit much into the article. First, I’d say that Telerik will always try to support the frameworks that our customers are using, however that doesn’t necessarily mean that we are specifically advocating that customers use a particular framework. One of the benefits of Kendo is that you can choose to use the framework within Kendo UI or use Kendo UI with whatever framework you already are comfortable with. Since a large number of customers were already adopting Angular, building easy Angular integration makes sense.

      Second, this article is simply reflecting a growing concern within the JavaScript community over the direction of Angular as expressed by the Angular team at ngeurope. It is true that this sort of controversy could impact adoption of Angular. I don’t think anywhere in the article did I express a specific recommendation as to what users should do with regard to adopting Angular or not. As I said, we want to support whatever frameworks our customers use,.

      • Ciel

        “technically”, you are right – but look at this from your customers point of view. “Telerik just pushed that their tools are compatible with Angular! That’s awesome!” – but then, we cannot get a lot of information on how far this support is intended to go. Then you release an article like this that is basically saying “Well, Angular was good but …. it may not be much longer. But I’m not giving you an actual ‘statement’. It’s just my ‘opinion'”

        Those are more mixed signals than teenage hormones. A big part of selecting which part of the framework to go with is having confidence about its future, and this does not instill confidence. It engenders anxiety.

  • Claudio Bosticco

    “Much nicer syntax.”

    Well, it’s like dating a girl based on physical attractiveness. May be good for very short-term relationship.

  • jfroffice

    Angular2 breaking changes – Some rollback after #ng-europe announcement https://medium.com/@jfroffice/angular2-breaking-changes-a4e94d682e8a

  • sherod

    What I genuinely don’t understand is are any of these changes in 2.0 actual improvements, or are they just ‘different’ and we’re going with the whims of a different team? Can anyone enlighten me?

  • elavoine

    It’s not about converting an ng-click to a (click) or whatever it is. This is a more profound problem. It’s a matter of trust now. What are my guarantees that 2yrs after 2.0, they won’t come out with another 3.0 that has nothing to do with the previous. Django framework has been out there for almost 10yrs now. Still the same philosophy. Almost no big breaking changes. Why couldn’t the angular team do the same? Why couldn’t the angular team stick to incremental changes. Improving the core (speed…) before even touching any public api? And also, rewriting the entire framework will just kill the rich ecosystem created around 1.x. I’m talking about all those good modules and tool like ng-inspector or batarang.

  • Gili

    My 2 cents: avoid frameworks like the plague and insist on using libraries instead. Frameworks require you to change your design. Libraries live inside your existing design. The latter are a lot easier to deal with from a maintenance point of view.

  • Pingback: On Our Radar This Week: AngularJS update, ES6 preparation, and more()

  • kmandrup

    If only the web dev community could make a new framework best on the best solutions of the top frameworks…

    Personally I would like to see a framework that combines:

    – AtScript

    – Ember CLI as: build tool, app management and plugin system

    – Angular 2.0 router and components/directives + templates (meat/core of the system)

    – Flexibility to wrap whichever Data provider in a consistent way, such as reusing Ember Data outside ember

    – BaconJS for making streaming data components

    – Freely integrate authentication, authorisation, validation, logging etc. as cross-cutting concerns from whichever library out there… via dependency injection

    – Famo.us, Ionic, Kendo UI integration…

    If anyone would be interested in trying to merge the best of Angular and Ember (and other libraries/frameworks) let me know. Perhaps we can make a roar that will be heard or together start assemble a framework that will deliver for the modern web in 2015 and beyond…

  • Antoine Lucas

    I don’t think angularJS 2.0 is that an issue. The 1.* branch will be maintained, and when I see the improvement between 1.2 and 1.3, I am absolutely not scared for the future, as we’ll see 1.4, 1.5, till 1.9.
    Don’t forget that 1.3 is a major release as well, with drop of support for IE8, a real FORM validation support and huge performance gains.
    Don’t think of angularJS 2.0 as the successor of 1.3, but more as a new technology that will be ready for stable production in minimum 5 years. How long do you think it will take to have ES6 supported on every browsers? AngularJS 2.0 is based on ECMA 6 which is not even developed yet. I wouldn’t worry about 2.0 too much. I am more curious about 1.4 development rather than 2.0.

  • Antoine Lucas

    I don’t think angularJS 2.0 is that an issue. The 1.* branch will be maintained, and when I see the improvement between 1.2 and 1.3, I am absolutely not scared for the future, as we’ll see 1.4, 1.5, till 1.9.
    Don’t forget that 1.3 is a major release as well, with drop of support for IE8, a real FORM validation support and huge performance gains.
    Don’t think of angularJS 2.0 as the successor of 1.3, but more as a new technology that will be ready for stable production in minimum 5 years. How long do you think it will take to have ES6 supported on every browsers? AngularJS 2.0 is based on ECMA 6 which is not even developed yet. I wouldn’t worry about 2.0 too much. I am more curious about 1.4 development rather than 2.0.

  • Long Le

    We’ve all lived through this before and it ended up all good, the event was called Boostrap v2 to v3. Had very similar parallels, rewrite, major breaking changes and even a huge (mind) paradigm shift (e.g. v1 – v2: desktop first then mobile, v3: mobile first then desktop) and there was a lot of community heart burn on the upgrade strategy (which in most cases required a huge refactor and even in worse cases rewrite). After some time (when realization materialized), devs appreciated the fact that the Bootstrap team went bold to refactor with major breaking changes to do things right. It’s a bit early to assume that this story (AngularJS v2) will end up with the same results, but I’m hopeful, if any team has got a shot at this it’s them. For now, I do share everyone’s pain: https://twitter.com/LeLong37/status/544587551781048320

  • dojovader

    Well I use Dojotoolkit and a bit of AngularJS, to be sincere am not a fan of AngularJS despite its awesome, AngularJS has it’s angular way which doesn’t respect HTML or JavaScript in a good way, you are learning AngularJs not JavaScript. its alot easier to integrate DTK with our libraries without wrapping them in services. For now I have no choice than to stick with Angular due to the company policy, i’d hate to break the word that in the next 18month there would be no support been using DTK since 1.5 and it’s be one of the few stable toolkits around. DTK 2 would be even modular. still awaiting Angular 2.0

  • Shien The Kid

    Why is Angular rebelling against the HTML spec even more, and making mostly aesthetic changes that won’t make much of a positive difference to performance? = I feel like they’re just trying to annoy us all.

  • Trisha Edwards

    1999 – html, css and ajax took the same amount of time but less confusion to create a SPA.
    2015 – 10’s of frameworks and to my horror I find jquery, angular, knockout, backbone, react mixtures not to mentions css frameworks.

    I think it is becoming just a trend to throw in a framework and not think of productivity. As a business user I care less if it is writing in simple js / ajax and can be fixed by any intern than a overcomplicated framework that creates such obfuscation that one has to recode the whole thing again.

    My suggestion to all the devs out there is firstly to not go after any framework done by a large organization, as they have lots of whims and fancies as they live in their ivory towers.

  • Geo Washington I

    I have stopped using Angular and am examining React more closely. Meteor takes too much control away from me to consider it. I really have no interest at this time learning any Angular versions prior to 2.0. It makes absolutely no sense.

  • Pingback: A JS framework on every table – Allen Pike | James Reads()

  • I see people harping over the template syntax everywhere. It’s trivial to rewrite html, and I guarantee there will be converters online before 2.0 even comes out. The real issue is going to be changing the way we write angular javascript. And moving from coffeescript to atscript. It’ll be worth it, but it’s going to sting.