Will Angular 2 be a success? You bet!


Back in March 2014, the Angular team dropped a bomb by announcing Angular 2 and everyone started yelling. Instead of an evolutionary step forward, the proposal was too revolutionary for its time.

As with every revolution, the promise was to break from the past and build а bright new future. The problem was that it was early 2014 and no one was ready: ES6 was one year away from standardization; AtScript sounded too exotic; two-way data binding was really needed for data over forms apps. But most of all backwards compatibility was really a must for such a popular and widely used framework.

During the latter half of 2014, other frameworks like React and Ember grew in popularity in part because of fears about Angular 2’s Titanic future. But the Angular team did not stand still.

Why Angular 2 is going to be successful?

I have a very simple answer to this burning question – because it is built by the same people who built Angular 1.

Have you considered why TypeScript has been successful even while coming from Microsoft? Because it is designed (and built) by Anders Hejlsberg, the language designer of C#. But why is C# successful – because Anders also designed Turbo Pascal. But why was Turbo Pascal successful – OK, let’s stop here, we are going way too far down the rabbit hole.

Yes, it is that simple. The same team that built Angular 1 is working on 2, and they are bringing all their hard-learned knowledge with them. They are not going to repeat their mistakes.

The team is also entirely dedicated and open to the community. First, they are posting everything they are doing in the weekly meeting notes. Second, they are collaborating closely with the community to deliver integration with two widely popular frameworks for mobile app development – Ionic (for hybrid) and NativeScript (for native).

Why is Angular 2 the future?

Allow me to list the items that I personally believe are done well in Angular 2.

Simple, but Not Simplistic

Angular 2 framework is simpler than Angular 1 and has far fewer concepts, making it easier to understand. But being simple does not mean that it is less powerful – just the opposite.

For example in Angular 2 everything is encapsulated in a Component, no need for Controller because the Component acts as one. No need for $scope or ViewModels. Even the View can be embedded in the Component using decorators and multi-line strings.

Here is a definition of a simple Component in Angular 2 (written in TypeScript):

  selector: 'messenger'
  template: '<div>Hello, {{message}}</div>'
class Messenger {
  message: string;

  constructor() {
    this.message = 'World';

The @Component decorator defines a selector that matches the messenger tag similar to ng-controller in Angular 1. The component’s view defined in @View will be bound and inserted in the elements matched by the selector. The binding context used when generating the view is the Compoment itself, so its properties are accessible in the Mustache template defined in the @View.

Mobile First

Angular 2 is designed from the ground-up for mobile and optimized for memory efficiency and less CPU cycles. It has first-class support for touch events and gestures that work across all devices. All the benchmarks that Angular team is exercising are public and part of the GitHub repo, so everyone can look at them and even run them locally.

Speaking about performance recently the Meteor team did a front-end frameworks performance shoot-out and Angular 2 came out first, overtaking React.

Better Foundations

The main building blocks of Angular 2 are just better.


Take for example the Router. It is declarative and way more flexible. Here is an example router configuration:

@Component({selector: 'inbox-app'})
@View({templateUrl: "inbox-app.html", directives: [RouterOutlet, RouterLink]})
  new Route({path: '/', component: InboxCmp, as: 'Inbox'}),
  new Route({path: '/drafts', component: DraftsCmp, as: 'Drafts'}),
  new Route({path: '/detail/:id', component: InboxDetailCmp, as: 'DetailPage'})
export class InboxApp {

The route configuration is streamlined and each route maps to a Component. If you want to dive deep into 2.0 routing, I would recommend this session from the recent AngularConnect conference.

The router itself is even backported to Angular 1.

Dependency Injection

Another building block that has improved is the Dependency Injection. Let’s look at the following example:

export class TodoService {

@Component({selector: 'todo-app'})
@View({templateUrl: 'todo.html'})
class TodoApp {
  constructor(public todoService: TodoService) {}

Using TypeScript’s type annotation makes obsolete the need for “magic” strings. Combined with the declarative nature of decorators, we end up with something that we can easily reason about.

Another great feature of the Dependency Injection system is that it is hierarchical. This is especially useful when we have complex Component trees and want a clear separation between component boundaries.


Data-binding is another core aspect of the framework that has evolved in Angular 2. The change detection implementation was rethought from the ground up, eliminating all issues currently present in Angular 1.

The most notable improvement to data-binding is that the graph of change detectors in 1 is transformed to a tree which reduces the complexity of determining when a change should be applied, thus resulting in better performance. Combined with Observable or Immutable objects you can even further optimize the change detection strategy

Also listening to the community feedback, the Angular team implemented two-way data-binding using the well known ng-model directive that can be used in Angular 2 forms.


Templates are another part that has improved from the previous version. Yes, for the untrained eye, it might look like just a “facelift” (using [], (), [()], # and *), but actually the whole template system was redesigned from the ground up to support web components and even native elements. This means that popular frameworks like NativeScript can plug in their own Renderer and, all of the sudden, Angular will render a cross-platform native UI for iOS and Android.

Decoupling the rendering pipeline from other parts of the frameworks allows for other interesting scenarios like server-side rendering.


I’m a big fan of TypeScript and I believe it is the right way to solve the complex problem of building large scale applications in JavaScript with a team of developers. TypeScript is first-class citizen in the Angular 2 ecosystem but how did it end up there?

Earlier this year, the TypeScript and Angular teams met to discuss the possible ways of using TypeScript as a substitution for AtScript, which resulted in shifting the priorities for the TypeScript team for the better. Decorators were implemented along with plenty of other ES6 features.

The Angular team jumped on it as well and refactored a big portion of the codebase into an idiomatic TypeScript. The end result was a better TypeScript and a better Angular.

Being first-class means not only that the source of the framework is written in TypeScript, but the documentation and tutorials will have TypeScript examples as well. Also Angular’s npm package comes with TypeScript declaration files (.d.ts), which will ease the framework’s getting started experience if your editor supports TypeScript.

JavaScript (ES5) will also be supported as first-class citizen in Angular 2 in the form of a nice, fluent API for component definitions.

Still running away from TypeScript? There is absolutely no reason to. Even Burke Holland loves TypeScript, so you will love it too.

Migration from Angular 1

When Angular 2 was announced there was no clear migration path from Angular 1. The community immediately criticized this, and the Angular team listened. This is how ngUpgrade was born.

ngUpgrade is a collection of best practices, guides and interop strategies covering how you can augment your existing Angular 1.x apps so that they are 2.0 friendly. The community also did not stand still and introduced ng-forward, which is a concrete implementation of an upgrade strategy.

If you are interested in using those tools and guidelines you can watch this talk.

What’s next?

Yes, Angular 2 has had some bad PR, but we’ve been in the framework for months now; we’ve been working with the Angular 2 team directly, and I believe Angular 2 is going to be amazing and Angular 2 will be what’s “so hot right now” in 2016.

Source: http://blog.bitovi.com/longevity-or-lack-thereof-in-javascript-frameworks/

So what’s your bet for 2016? Mine is on Angular 2.



  • Nicholas Lowman

    Nice post. Your code examples are using the @View decorator. That’s been dropped. It’s all in the @Component

  • nielskrijger

    Angular 2 will be a waste of time for most developers out there.

    The similarities between Angular 2 and J2EE/JSF are striking. This allows me to make a different prediction; Angular 2 will have advantages for only the very biggest of code bases. For the vast majority (>90%) of websites and use cases it is just a bloated framework, language and eco system and you’ll desire something more lean and mean. There are plenty client frameworks out there these days (react being the obvious contender currently).

    Even if you’re planning to build that huge monolitic codebase you’re doing something wrong most likely; they are cumbersome beasts that become horrible to maintain and just slow you down.

    Unfortunately Ionic 2 is happily embracing this monster and might force it down my throut; before I let that happen I’ll have a hard look at alternatives.

    • Steve Gentile

      Haters going to hate – it is actually very slimmed down and quite similar to ReactJS – modern, slim, better performance, flexibility… Not sure I see any ‘bloat’ here – quite the opposite ! Great article!

      • Gavin Engel

        Ng2 is slimmed down? Interesting.

        • Rob Eisenberg

          Um….ng2 is quite large. It’s way bigger than ng1 and bigger than pretty much every other framework too I think. I know it’s roughly twice the size of Aurelia, for example.

          • Gavin Engel

            Oh that’s not good. Thanks.

          • burkeholland

            What’s a core project size for Aurelia? I mean if I just needed DOM abstraction and binding.

    • Lars Jeppesen

      Hi React, is that you?

    • burkeholland

      Large projects are the reason why frameworks like Angular even exist. Small projects really don’t need anything more than a simple DOM abstraction, like jQuery. Even React is overkill for small projects.

      • Steve Gentile

        Agree and yet actually the way that angular has moved to a move modular structure having a simple page still works well – I wouldn’t categorize Angular as a no go for smaller apps just to appease posts like above 🙂

      • nielskrijger

        Couldn’t agree more.

        To fix my apparent “fan-boy”-remark; 70% what I do is in Angular 1, 20% React/Redux, 10% jquery. I’ve been playing with Angular 2 as part of Ionic 2 which is my main reason to dislike what I’m seeing; it reminds me of previous experiences with JSF/J2EE; a level of abstraction and concepts I know don’t work nicely for smaller projects; it feels overengineered very quickly.

        With regard to React; I merely stated it is a common (popular) alternative. React + Flux / Redux is a monster as well.

        • mbokil

          Alas, why do re-writes end up being over engineered instead of simplifying and tightening up the tech like improving performance with virtual dom. It is like a disease of process in engineering.

  • Before actually choosing a library / framework, we need to understand that selecting the right abstractions for our components is actually more important than “betting” on anything. Currently the web development is divided into 2 main trends: Web Components and Reactive Components. For example, Angular 2, Polymer, Aurelia etc. are embracing Web Components, whereas React, Vue, Riot, Om etc. are based on Reactive Components. Now, everybody knows that there’s a slight problem with the Web Components specs because of the lack of consensus among the entities that are responsible for defining them, therefore frameworks like Angular 2 or Aurelia are not built with Web Components at their core. Only Polymer is 100% Web Components. Nevertheless, Web Components is actually Google, just like React is Facebook.

    Another important criteria for choosing a library / framework is whether or not you prefer all encompassing / opinionated frameworks that you’ll unavoidable get to marry with (Angular 2, Ember 2 etc.), or you prefer a small set of focused libraries that do one thing and they do it well, like for example React + a Flux library + React Router etc.

    Also, when choosing a library / framework one should be looking at how difficult and costly it is to be changed, how well it integrates with other technologies, whether or not it has a strong ecosystem etc.

    Finally, just because React was brought into the original post a couple of times, here are some facts about it and Facebook:
    – Facebook has a strong open-source culture: http://opensource.com/business/15/7/keynote-oscon-james-pearce-facebook
    – React is the 5th most popular JavaScript project on GitHub, the first being Angular 1: https://github.com/search?l=JavaScript&p=1&q=stars%3A%3E1&s=stars&type=Repositories
    – Facebook’s code base has over 15k React components: https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html
    – Some companies already use React in production: Yahoo, Dropbox, Netflix, Salesforce, Mozilla, BBC etc.

  • Isabelle Diez

    angular2 is the future.

    • albanx


      • Isabelle Diez

        read the article

        • albanx

          already done, it is just the author opinion and guessing nothing concrete

          • Isabelle Diez

            there are soooo many excellent articles, videos, presentations, etc. out there. they excplain the benefits better than i could do. and actually wan’t do!

          • Dwight Vietzke

            Yes time will tell. But they said the same things about Angular 1.x not to long ago…and then a complete rewrite? Burned once, twice shy.

    • You don’t say

  • Rob Eisenberg

    Why does it even matter to Telerik? You build components. You should be building Web Components that can work with any framework and you should be talking about how Telerik stuff works great no matter what front-end framework you use. By embracing the standards you can reach a larger market and not run the risk of alienating clients. It also means you don’t have to keep re-writing things every time there’s a new framework.

    • Actually only time will tell if Web Components will be the actual way to go or they will be “ActiveX 2.0”. I believe focusing on interoperability is a must for a component library. The internals make sense for the community only if the library is open-source.

      • Rob Eisenberg

        HTMLTemplateElement is implemented today in every browser except IE. It is in development in Edge now. Shadow DOM is being locked down to v1. It is being implemented by all the major browsers. Custom Elements is nearing v1 completion and is already implemented in some of the browsers with the rest soon to follow. These capabilities will probably be available in every major browser within a year. You can use webcomponents.js today to polfyfill it and build apps and components now.
        Component vendors have a responsibility to build components to web standards, in my opinion. Telerik should be focusing on that. Alternative approaches wouldn’t really be wise at this point in the game, not when all the big players have agreed upon a standard component model and not when modern frameworks have WC interoperability.

        • For Shadow DOM there is no general agreement yet on how to be standardized. Also you didn’t mentioned anything about HTML Imports which still overlaps with ES2015 Modules. Here are some more details about Web Components status http://www.2ality.com/2015/08/web-component-status.html

          Indeed, you can use Webcomponents polyfill today, but only if your business allows supporting IE11+. Let’s not forget that many of us need to support IE9+. Another thing about Webcomponents polyfill is that Shadow DOM is so slow that even Polymer uses a lighter version called Shady DOM (or Local DOM). In fact, if I’m not mistaken, Polymer is the only library that is fully built on top of Web Components. Others like Angular 2, Ember 2 use only similar abstractions.

          In order for anything to be available in every major browser, it needs first to be agreed by everyone, which is not the case with WC.

          Also, there are already some React techniques influencing not necessarily Web Components, but rather the way we should be writing our components and what the language itself should be offering – see the case with Object.observe that is withdrawn from JavaScript TC39 https://esdiscuss.org/topic/an-update-on-object-observe

          Telerik Kendo UI is already built with jQuery at it’s core, but is providing interoperability for Web Components and Angular which is a good thing. They could do better than jQuery, but this is totally their choice.

          IMHO, the real options that developers have today are either libraries implementing similar Web Components abstractions (Angular 2) or libraries implementing Reactive Components (React / Vue / Om etc.)

          • Rob Eisenberg

            Cosmin, I think your information on WCs is a bit out of date. There is consensus on Shadow DOM v1 now. But even if there wasn’t, you can create custom elements without using Shadow DOM. HTML imports are on hold, but they aren’t essential and aren’t needed to create web components at all either. You can just use ES 2015 modules. As I said, templates are pretty much everywhere….though even those aren’t needed. What is needed is only Custom Element, which can be polyfilled with a fairly small amount of code. There are multiple polyfills for it in existence. That is how I hope Telerik is building their components going forward. If they do, they will automatically interoperate with modern frameworks and even when no framework is present. As a component vendor, I wouldn’t tie myself to any one framework. I would build based upon standards.

          • If Custom Elements are really everything that you need in order to “build based upon standards”, then why the fuss about Shadow DOM and HTML Templates? Also why HTML Imports?

            And then again, how to build based upon standards, when only 25% of the standards matters and can be used with lower versions of IE?

          • Rob Eisenberg

            It’s about layering on functionality to make native components richer and richer over time. The base custom element spec can be used to build any custom element you want. It’s easier if you have HTML templates. It’s easier still if you have shadow dom. But you can just use the Custom Elements spec on its own….and that’s what you would want to do if you wanted to create components that would integrate with any framework.

            Here’s a 3k polyfill that has broader browser support than any of the modern SPA frameworks: https://github.com/WebReflection/document-register-element

          • How can you layer on functionality when Web Components aren’t really about functionality? Templates are really pointless and inert without some sort of data binding – and we all know that React’s unidirectional data flow is already a space rocket. Shadow DOM is DOM encapsulation. HTML Imports are a renegade child of modules.

            So, back to my initial point, with today’s technologies and “standards” is mostly about interoperability.

          • Danny

            IE8, IE9 and IE10 is not even supported by Microsoft anymore, so why are you supporting it? https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support

            IMHO React is a cancer and should be erased from planet earth as soon as possible, because this is JS I give it 18 months to live 🙂

            Reactive programming has been around for some time now, not sure what you mean… Is there a reason why a web components can’t be reactive? What does reactive programming have to do with web components I think you are mixing things a bit here. If you can clarify, it would be helpful.

        • Atanas Korchev

          Rob, do you know if WebKit will support custom elements? Doesn’t seem so from this https://bugs.webkit.org/show_bug.cgi?id=150225

          *We don’t have any plan to support the current proposal as it’s fundamentally incompatible with ES6 class syntax.*

    • Gavin Engel


    • Hi Rob,

      Thanks for your reply. First of all I should mention that this article is my own opinion. I could have easily post it on my own personal blog but I preferred the tribune of Telerik Developer Network so that my thoughts could reach more people.

      I can also assure you that Kendo UI will support Web Components (or any future standard) out of the box. You can even right now go to the samples that demonstrate its usage with Web Components http://demos.telerik.com/kendo-ui/integration/webcomponents and Angular 2 http://demos.telerik.com/kendo-ui/integration/angular2. I’m sure Kendo UI will work in Aurelia as well.

      Speaking about Aurelia I would be really glad to see it supports different platforms like NativeScript the same way Angular 2 does. Unfortunately this is not the case: https://github.com/NativeScript/NativeScript/issues/536

    • ba dmm tss

  • Aurelia is the way to go and I agree with @EisenbergEffect:disqus .

    • mbokil

      I really like the syntax of Aurelia compared to Angular 2. It just looks so much cleaner. I already now Angular 2 will not be as successful as Angular 1. I just look at what my friends are using now. React > React Router > Flux > Node.js. They dumped Angular. I still use Angular 1 for work but am considering changing for new projects to something component based. Possibly Riot instead of React. It is a shame they had to reinvent the wheel for Angular 2.

  • Norman Klein

    Not to rain on your parade, but I’m more than extremely disappointed that even after breaking everything with Angular2, its still necessary to use JQuery underneath the hood. Let’s face it, Angular is still nothing more than a wrapper around JQuery. You want to be writing to a virtual machine — as with data bindings — and be completely independent on depending on JQuery to manipulate the DOM. The goals of Angular2 weren’t nearly grand enough to justify a complete break and no amount of rah-rahing will change that.

    • mbokil

      I agree a complete rewrite with added complexity will probably lead to mass defection. Just a guess but early signs don’t look good. It seems like adding components and cleaning up 2 way binding would have been successful upgrade.

  • Pingback: 11 Community Resources for Angular 2 Developers 2015 - Colorlib()

  • Pingback: Some good reads on Angular 1.x | Windows Live space()

  • Robert Penner

    Meme should be Hansel. So hot right now. Hansel.

  • Pingback: Daily links 2015-12-07 | Marcin Kossowski()

  • Pingback: [js] Angular 2 beta | PipisCrew Official Homepage()

  • brownieboy

    I think it’s far from certain that the majority of Angular 1 devs are going to move to Angular 2. There’s a human element here that’s being largely skated over, IMHO.

    I was chatting a to a number of Angular Devs at a recent JavaScript meet-up. None of the ones that I spoke to were at all happy with what’s going on in the Angular world. Rather then Angular 2’s technical improvements – which none of them even mentioned by the way – they were more concerned with how they’ve had the rug pulled out from under them by the breaking changes from Angular 1.

    Many of these devs have had to face uncomfortable conversations with their management and/or clients, about how the the current solution, which they had originally recommended, was about to become obsolete. (Is it still the plan that Angular 1 will be supported for only 18 months after Angular 2’s release?) The upgrade path that the Angular team finally announced is a step in the right direction. But Angular devs are still going to have to allocate time and money towards a code only (as in no new features) rewrite just to get on to the new framework at some point, aren’t they?

    Of course, this kind of thing could just as easily happen to React, or to any other framework, at any time. But Facebook have been pretty good on that score up to now. E.g, while they would obviously prefer devs to use the new ES6 Class syntax, they still promising to support the original createClass syntax indefinitely.

  • elgselgs

    Have a quick look at Angular 2, it looks really ugly, as ugly as React. I might be horribly wrong, but this is my opinion. I don’t think Angular 2 will be successful.