We Have Seriously Underestimated Angular

I was putting together the keynote for the upcoming NativeScript Developer Day conference, and I had a slide placeholder in to talk about Angular. NativeScript has supported Angular 2 since it was released in RC at ng-conf in May. You can check out our quick 2 minute segment of the keynote where we announced our support…

As I was putting together the slides, I thought, “What exactly am i going to say about Angular?” Hasn’t everything already been said? Like 20 times? Instead, I started doing some research into exactly why we chose Angular 2 for NativeScript to begin with.

I always thought that it was based off of an email that Brad sent me in February 2015…


At that time, NativeScript was already at beta and headed for a full release (May 2015). We had our own binding framework, as well as full support for TypeScript and ES6. I remember thinking, “what exactly do we need Angular for?”. Angular 2 looks complicated, they seem to re-write it every 2 weeks and it feels like an uneccessasry tax to pay on JavaScript.

I, like so many other people, seriously underestimated Angular.

There have been so many articles on React, Angular, blood, guts, and how all JavaScript frameworks are more or less killing us slowly like too much Taco Bell (which, btw, is super unfair because Taco Bell has done a lot to improve the quality of it’s food lately). Man, is it easy to just completely drown in the noise. We also tend to forget why we even made certain decisions in the first place. I’m not sure how anyone ships anything anymore.

I got caught up in this nonsense myself. As it turns out, there are really good reasons why we chose Angular for NativeScript. We could have chosen React, Aurelia (an excellent framework right there) or any number of others. I mean, we could have fully implemented jQuery for NativeScript if we wanted to.

But we didn’t. We went with Angular. And the reasons why are far bigger than you would expect. Starting with the fact that nobody fully understands the adoption Angular enjoys.

Angular Adoption

We knew that we needed to provide an application framework for NativeScript. We still have our own binding solution and vanilla JavaScript model that many developers love, but a great many more need more from NativeScript than just “go nuts with JavaScript”. That’s where Angular comes in.

I don’t think anyone would argue that Angular is popular. I just think that nobody really understands how popular it is. Consider this scoped Google Trends graph…


When you look at this strictly from the angle of what people are searching for, Angular has nearly twice the adoption of the next highest. I didn’t even include any others besides React in the comparison because they are so slight that they are all essentially flat lines on the graph when put up against the behemoths that are jQuery, Angular and React. React is definitely a juggernaut, but it is still half of what Angular is in terms of interest on Google search. Furthermore, at the current pace, Angular will be more popular than jQuery in terms of Google searches by the end of 2017. Let me repeat that in case you didn’t fully catch it – Angular will soon be more popular than jQuery.

That should blow your mind. None of the hype that we hear on a day to day basis would suggest that this is the case, but it is. Don’t like my Google trends? OK, let’s do another. How about StackOverflow?

While the recent 2016 developer survey from StackOverflow shows that React is the trendiest topic, if you look at the tags page, Angular is number 20 down the list with 250 questions asked just today and 1615 this week.

React is on page 6 right before the oddly specific “visual studio 2012” tag, with 82 questions asked today and 515 so far this month. That’s roughly 1/3 the amount of Angular. This is not a slam on React. React is on a ridiculous upwards trajectory. I’m simply trying to point out what real mass adoption looks like.

Now I’ll be the first to admit that StackOverflow is a certain subset of developers, like the fact that their own survey reports that 4 of the top 10 tech stacks per occupation include either C# or SQL Server (roughly 78%) which would indicate that these are primarily enterprise and line of business developers. But who do you think is out there writing 90% of the software everyday? It’s line of business developers, not startups in San Francisco. As a side note, guess which other technology shows up in the top 10 tech stacks by occupation? I’ll give you a hint, it starts with “A” and ends with “ngular”.

I’m saying all of this to point out that the reason why we selected Angular was in large part based on it’s sheer adoption numbers. How do you know when a technology isn’t going anywhere anytime soon? When 2 of the top 10 tech stacks by occupation name it specifically instead of just lumping it under “JavaScript”. The fine folks on the React Native team nailed this when they said, “Learn once, write anywhere”. That’s exactly right! Why should you have to learn our binding, templating and application patterns when you already know Angular? You shouldn’t. That’s how people get worn out and fed up with programming, and rightfully so.

“But Burke! These stats are all Angular 1! Angular 2 is way different and everyone hates it!”

Good point! You’re sharp. That’s a fair concern, but also another huge underestimation. Mostly because Angular 1 is Angular 2.

Angular 1 Is Angular 2

I didn’t realize this until Todd Motto pointed it out to me, but the Angular team has been moving 1.x towards 2.0. If you haven’t looked at Angular 1.x in a while, you might not even recognize it. Consider the following simple application component/module in Angular 1.x.

const AppComponent = {
  template: `
    <h1>Root Component</h1>

  .module('app', [])
  .component('app', AppComponent);

Now here is that same thing as a component in Angular 2….

import {Component} from '@angular/core';

  selector: 'app',
  template: `
    <h1>Root Component</h1>
export class AppComponent {}

They look ridiculously similar! Aside from some of the newer additions such as the @Component annotation and leveraging an actual module standard, they are virtually identical. Everyone has this idea in their head that Angular 2 and Angular 1 are drastically different. They are, but the team has been very sneaky in the way that they have merged the API of Angular 1 into Angular 2. The leap from one to the other is significantly shorter than anyone thinks.

There is also this notion that people don’t like Angular 2. That’s just simply not the case. Angular 2 has been the most unstable JavaScript framework ever – by an enormous margin. The team over at Google ships breaking changes almost once a month. And yet, look at the State Of JavaScript survey that came out recently which reports that 64% of people are happy with their Angular 2 development experience. What?!? That’s crazy. This is like 64% of people being pleased with a car that consistently leaves them stranded. Imagine how much higher this number will be now that Angular 2 Final has been released.

Lastly, there’s something here that we haven’t even considered yet that causes people to intrinsically want to move to Angular 2 over any other framework out there, and that’s TypeScript.


TypeScript has been the subject of a lot of consternation for web developers. Why do we need types in JavaScript? What in the name of everything that is holy do interfaces possibly bring to the table for JavaScript developers besides bloat? Why are we trying to complicate something that is so simple to use. Keep your stupid OOP concepts. They aren’t welcome in our browsers.

The trouble is, those concepts that JavaScript so elegantly eschews are the same ones that are the foundation of solid applications. You know that age old argument about how JavaScript isn’t suitable for large applications? That’s because large applications require interfaces, some healthy amount of inheritance (gasp! I know) and the myriad of other structures that typed languages enjoy (and yes, modules). Those things were put into languages by really smart people for a reason. Not so that we could just throw them all out in favor of a language that was created in 10 days.

There are a lot of developers out there with solid OOP backgrounds in C# and Java that have no interest in just ditching decades of hard learned programming experience. For them, TypeScript opens up the door to a whole world of application development that they otherwise would have little to no interest in. This means that when these developers go looking for a framework to build their TypeScript apps with, they will end up in Angular’s front yard like John Cusack in Say Anything.


I’m sure you already know that Angular 2 is built on and for TypeScript, and so is NativeScript. What you may not know, is that other JavaScript frameworks such as Aurelia, Ember and even Dojo are headed towards TypeScript as well. Regardless of your opinion on TypeScript, it is a phenomenon that is sweeping through the JavaScript community, and it is pulling millions of developers into JavaScript along with it.

Be Skeptical But Watch Closely

Nobody can predict the future. And just because this blog post is on the internet does not make it true. If anything, it should make you very skeptical. But skeptical you should be. I’m simply suggesting that none of us fully grasp the enormity of Angular and the crushing influence that it has, even if they did decide to re-write it from scratch and break everything on the daily.

In the end, Angular is far bigger than any of us realize and 2.0 has some aggressive aspirations to be far bigger than just the web. NativeScript is part of that realization, but I don’t think we’ve seen anything yet.

Header image courtesy of Marc Majcher


  • Jochen H. Schmidt

    More searches and more questions on StackOverflow… perhaps Angular users just have to ask more about how to do something with it than others? 😉

    Seriously – Angular brings a lot of non obvious things with it and a lot of new concepts of which not even one makes intuitive sense. The good thing with Angular 2 is that they now at least replaced some of their own conceptions with ES2015 ones; while doing that they did spoil this effort though by directly associating them to TypeScript instead of ES2015. I often meet developers who think that modules, classes, arrow functions, default params, let, const a.s.o are “TypeScript” features and a reason to “abandon JavaScript”.

    To me Angular 2 is just to late on the game. The trend is more and more about functional concepts and Angular 2 is alarmingly weak in that point.

    • burkeholland

      Interesting thoughts. Although don’t you think the functional bit is largely addressed thru RxJS?

    • +1 for FP. — not only ES6+, but also in C#, although it already provides certain language features for a long time, and the Java community is very excited about the new features…

    • bmarkovic

      Functional programming being posh and trendy doesn’t work too well in this argument. It’s more like a popularity contest in a very nerdy school. Both pointless and useless for success prediction.

      Besides, both FP and OOP were around for couple of decades now and guess who has a bigger track record of shipped products. I’ll give you a hint. it’s not that this pig in a prom dress is prettier than the other. It’s just a better match for majority of problem spaces.

      If anything Angular 2’s OOP heavy familiarity with TypeScript will work in its favour.

      • sarxion

        Not necessarily. While yes, Typescripts’s adoption of OOP concepts is surely a big reason of its adoption, its also one of its biggest things that have people not wanting to adopt it. This is because its a well known thing inheritance, classical inheritance, is broken in JavaScript. Prototypical inheritance does exist, but that’s far from a solution. Typescript isn’t a new language, its built on top of JavaScript, and as such suffers from the same pitfalls.

        Because of this, experienced JS developers serious about their code even at an enterprise levels often choose something like Flow over TypeScript, since it offers just the right amount of extra Omph to get JavaScript usable at a grandeur scale while still making use of its useful core components and ditching the foot guns. OOP had it’s time and use, but as far as JS goes, its never really worked, and won’t ever work because JS wasn’t built for that purpose in mind.

        Personally, I’ll be sticking with ES6 and flow. It gets the job just fine, without violating or promoting the use of clearly broken JS features.

        • bmarkovic

          Again, Inheritance based OOP and “whatever Java is doing” is not the whole world of OOP, and everything that exists in JavaScript has exited for decades. Actually, polymorphism isn’t a core OOP concept (despite what your textbook says). OOP, at it’s core is encapsulation, combination of state and functionality, and message-passing. And of the three (ie sans polymorphism), the only one that is seriously re-examined is combination of state and functionality (I deliberately make distinction between this and encapsulation which is simply restricting access to said functionality and data), and even then most I’ve seen is posh buzzwordy blabber and very little convincing argumentation.

          • Jochen H. Schmidt

            OOP is most importantly about identity. This is the actual Lisp heritance it really has. Most OOP concepts today use simple object identity and associated mutable state. At this level there is no difference between what Java does or what JavaScript does. As soon as you drop out mutable state you actually gain a lot. You model association of ID and state over time. This actually can work using messages as long as messages have time. That way you can always compute a deterministic view of the current state on any identified object.

      • Jochen H. Schmidt

        I’ve heard this reasoning a lot in the last 15 years and guess what? OOP concepts are vanishing. Composition over inheritance is a well known idea for quite some time because inheritance is actually a form of compression and this is where its biggest failure is. So OOP programmers learned to avoid inheritance over composition. Guess what “compose” is as a function? FP is the principle of composition realized in its purest form. The next dying thing is mutable state. OOP is inherently stateful, but programmers stay away from creating mutable state and instead use immutability, value types a.s.o. It is easy to understand why if you see todays apps being more and more asynchronous or multi core using. Async… guess where Promises come from? It’s an FP concept. Guess where LINQ comes from? It’s a monad.

        So if you still think this is about being “posh and trendy” then Angular 2 might be really your thing (being hipster for a few more weeks 😉 )

        • I don’t think promises and linq are monads, they look like monads (can be inspired on them) but they are not. Promises are not even functors. They are not mappable, then is not map. The then is Promise a -> (a->b) -> (a->b) -> Promise b (that if it would be point-free, but it is not 🙂 )
          Even in Haskell we need a State monad 😮 the world is stateful, the functions should not be, do blocks should be. OOP and FP can be stateful or immutable 😉
          Sometimes, for performance reasons, states are useful as written in the haskell wiki 🙂 use the FFI when you need it 🙂
          All of this also for JS, when you need performance, don’t waste cycles in allocating/freeing memory, if you can do it in place (destructive updates). The garbage collector in JS is not as smart as in haskell, so not be that purist here.

          • vladap

            Promise .then method behaves both like Functor .map or Monad .bind (aka flatMap). It breaks its laws hence we can’t call it Functor/Monad if we want to be purists. But these FP concepts are there. If developer understands Functor/Monad he can have easier time to understand how Promise works.

            .then accepts either function which takes result of previous Promise and returns another plain value, and .then returns new Promise for further composition using .then – which is like Functor .map.

            Or function which takes result of previous Promise and returns another Promise, which is like Monad .bind.

            It as well accepts functions with side-effects returning nothing and has its own error handling – hence for sure it breaks laws.

          • bmarkovic

            Except that, for every pair you mention, the two are totally unrelated, have not been inspired by eachother and haven’t even been designed for the same, but only overlapping, use cases,

          • vladap

            It doesn’t matter if they have been inspired or not, designed for the same, if designers knew about monads/functors or not. “Totally unrelated” is wrong point of view. You have either misunderstood my point or your understanding of “map” and “flatMap” is along the lines of being helpful operations on collections.

            My primary language is Scala and when I was learning ES6 Promise I immediately tried if functions A => B and A => Promise[B] works with .then. This revealed to me that I can re-use great amount of knowledge gained in another context.

            Rather than “totally unrelated”, Promise looks like monad concept tailored to specific requirements and priorities during JS design. And taking into account history how Promises evolved in JS land (JQuery promise, Angular deffer…), one can’t get rid of a feeling about reinventing the wheel.

        • bmarkovic

          Composition and non-inheritance based OOP has existed at least as long as inheritance based OOP, and has existed as long as LISP or whatever it’s precessors were. The sad thing is that many people equate OOP and “whatever Java is doing” which is incorrect. Thing is, especially in business/work/stuff automating software (which is what 99% of programmers are writing still), objects passing messages to each other to perform tasks is simply a much more natural paradigm to how real world, that the software is modeling, works. The future is obviously in languages like Lua, JavaScript, Scala, Python etc. that marry both worlds into a cohesive and expressive whole, but the thing is that business dictates software and not vice versa. Parallel and asynchronous systems were efficiently implemented from assembly to C++ (if anything I see more people jumping to Go and Scala, and not Haskell for that kind of thing) so I doubt that will change anything. I don’t see that massive shift to FP anywhere but in blogosphere and from (mostly SoCa based) hipster types. To me, until some real working software in the wild changes that, it’s just a case of loud minority and holier-than-thau attitudes.

          • Jochen H. Schmidt

            Why do you try to denigrate users always by bringing up “hipster”-connotations? Is it you feeling you lose track of such trends and it makes you feel better if you can portray those with better track records as some kind of fashion victims? Please don’t do that – it will not help you anywhere.

            You mention LISP. I’m actually a Lisp-Programmer (its written this way thesedays) since more than 17 years. The object oriented programming of the earlier Lisp era is very different to what is known today. The most important concept with it is “identity”. An object has identity. The actor model by Hewitt is perhaps the first version of a concurrent message passing model and it also contained private internal state.

            The biggest problem of OOP using simple object identity and associated mutable state is that you lose control over a very important aspect of the real world: time. An object with mutable state is only in one state at each point in time. With identity and mutable state it will always be difficult to model asynchronous systems.

            It is a misconception of functional programming concepts, that you cannot model objects with it. When modelling objects using immutable data structures you can create a even more natural and flexible model of the world. Object identity is then just a mapping from an ID and a point in time to the tuple that describes the then current state. Modification of an object is just a transformation of one tuple to another using a transformation function that has at least the time and the former state as a parameter.

            You can use this concepts in languages like JavaScript (or TypeScript) – but the established culture in Angular 2 is using objects with classes, simple object identity and mutable state. Its really old school stuff and it doesn’t scale well without much work.

          • Neutrino .

            “Why do you try to denigrate users always by bringing up “hipster”-connotations?”

            You were the one that brought hipsters into it in your very last last post. Remember ” then Angular 2 might be really your thing (being hipster for a few more weeks ;)”. So accusing others of trying to be derrogatory for bringing up hipset connotations is blatantly hypocritical.

    • Not necessarily. While yes, Typescripts’s adoption of OOP concepts is surely a big reason of its adoption, its also one of its biggest things that have people not wanting to adopt it. This is because its a well known thing inheritance, classical inheritance, is broken in JavaScript. Prototypical inheritance does exist, but that’s far from a solution. Typescript isn’t a new language, its built on top of JavaScript, and as such suffers from the same pitfalls.

  • brownieboy

    Well of course you can say “Angular 1 Is Angular 2” if you assume Angular 1.5x === Angular 1. That’s because introducing Angular 2 concepts and constructs into Angular 1 is the entire raison d’etre of Angular 1.5.

    “If you haven’t looked at Angular 1.x in a while, you might not even recognize it.” Exactly the point: will the real Angular 1 please stand up?

    • burkeholland

      Sure, and maybe < 1.5 projects won't upgrade for that reason. But the adoption of Angular is still on a upwards trend, which means that no matter which one developers choose, the APIs are pretty normalized.

  • Pingback: Dew Drop - September 16, 2016 (#2330) - Morning Dew()

  • jphamilton

    So I guess the big push at Telerik has been for Angular 2? I saw a post that had a timeline for React components this year but I never heard another word about it. Has this been abandoned? I’d love to use Kendo again but there is no way I am ever going back to Angular, let alone jQuery in order to do it.

    • burkeholland

      React or die, huh? 🙂 You aren’t alone. Would you mind having a look at the React Wrappers repo and voting the issue up?. We very seriously considering a formal React offering.

      • jphamilton

        Absolutely. Had no idea it was there.

      • brownieboy

        Huh? React wrappers for the jQuery-based Kendo components?

        What happened to the jQuery-less React Kendo components that Telerik has on npmjs? Are they not being taken further?


        • burkeholland

          Can you email me directly at burke dot holland at progress dot com?

  • derekgreer

    The first thing that needs to be acknowledged is that Google Trends reflects all interest … good, bad, and indifferent. For example, everyone that’s ever written an article about how bad some particular technology is will be reflected in the numbers for that technology’s search trends because they likely did some research on it using Google. Also, all the poor saps stuck maintaining Angular 1.x apps who look up stuff almost daily are pumping those numbers. Second, everyone who searches on Angular can’t be included as interest in Angular 2. Now, some of the numbers originating from people just searching for “Angular” probably do reflect interest in Angular 2, but I’d say it would be a small percentage.

    Here is a comparison I think is more fair: https://www.google.com/trends/explore?q=%2B%22Angular%202%22%20%2B%22AngularJs%202%22%20%2BAngularJS2,%2Fm%2F012l1vxv

    This reflects that there’s quite a bit more interest in React than Angular 2. Do a search for open React jobs vs “Angular 2” on Simplyhired.com and it tells a similar story. Of course, None of these results tells the whole story, but I think we have to say React is leading.

    Based on the few surveys I’ve seen, React is way out ahead in terms of favorable interest.

    • burkeholland

      Some great points here! Although not sure I agree on all of them.

      You are basically proposing that Angular enjoys strong search trends because it’s really hard to use. So much so that it affects search trends, but not adoption. I’m having a hard time making that work in my head.

      Also, I am not proposing anything about React and nobody can deny that it’s trendy. I’m simply underscoring the gravity of the current Angular adoption. That is not something that vanishes with trends. jQuery is a prime example of that.

      • derekgreer

        How difficult an API is to use definitely has an impact on how often consumers return to the documentation, post questions on Stack Overflow, etc., but that wasn’t really my point.

        Any non-trival API is going to result in repeated searches by consumers. For example, I’ve been using Autofac for about 6 years now and, while I think it’s one of the best IoC containers out there, I still revisit the docs every time I need to do something non-trivial (multi-tenancy, decorators, etc.) In contrast, I rarely do any searches related to the testing framework I use (MSpec), because the API basically comes down to knowing three delegate types (Establish, Because, and It). It has a very tiny API surface area, so while I’ve been using it for 8+ years, I rarely search for anything related to it.

        Angular has been around for about 5 years and has a fairly large API surface area, so every Angular project started over the last 5 years that is still being maintained is going to generate traffic. As someone who used Angular 1.x for several years, I can definitely say that I frequently found the need to search for how to do something on an ongoing basis. Not necessarily every day, but at least every week. That isn’t a slam on Angular, it’s just a reflection of the fact that it isn’t a trivial API. Given the community is now moving to next generation frameworks (React, Angular 2, Aurelia, etc.), most who are in a situation where they can’t easily switch to one of the new frameworks probably wishes they could. Ergo, there is going to be some traffic on an ongoing basis from teams who are maintaining Angular 1.x projects who would rather be doing Angular 2, React, or something else.

        Since Angular 2 is a new framework with the same name as Angular 1 (as opposed to Durandal vs. Aurelia), it’s almost impossible to say how much of the traffic for the search term “Angular” reflects interest in Angular 2. Given there are 5 years worth of maintenance projects out there and Angular 2 was just released, however, it’s a safe bet that a large percentage of that traffic results from people looking up day-to-day stuff for Angular 1.x maintenance. Therefore, the only fair comparison is to search for variations of “Angular 2”, look at the number of job openings, and consider the various polls as a reflection of interest.

    • I agree with you.

  • manezi

    Why should you have to learn our binding, templating and application
    patterns when you already know Angular? You shouldn’t. That’s how people
    get worn out and fed up with programming
    , and rightfully so.

    I respectfully disagree. As software developers, new paradigms and technologies should excite us! After all, that’s why many of us are in this profession.

    • burkeholland

      That’s fair, but often we are re-learning the same concepts over and over again. There is a ton of churn in our industry.

      • manezi

        True, I can’t argue with that.

    • Butler Reynolds

      Just give it 20 years and you too will be tired of re-learning how to read info from a database, put that information on a screen, accept user input, then write it back out to the database.

      • manezi

        And that is why I will always love Rails.

      • burkeholland

        This was painfully accurate for me

  • Nathan Armstrong

    Wasn’t there an enormous issue with Angular 1 _not_ being similar enough to Angular 2? I know they worked hard on smoothing the transition, but I’m guessing there’s still a significant drop in users during that time. I’ll have to dredge up some of the articles that popped up at the time.

    Also: trying to pit Angular against React doesn’t quite make sense, since they fulfill very different roles in the client system. Angular is a holistic framework for constructing all parts of the client application, while React is very strongly focused on simply the view aspect of the client. The lines are blurry there.

    • burkeholland

      Not pitting them. It’s just that React is really the only other thing you can find to compare against Angular. Nothing else even makes a blip on the radar. Also, you rarely use both together. It’s usually either one of the other.

    • Aleksandr Strutynskyy

      quite tiring, keep reading people describe react as view only… saying react is view only sounds limiting, in react world there is actually no need for models/controllers.

      • Nathan Armstrong

        Only if you want to make React components that are not reusable or maintainable. The view lifecycle embodied by React does not make it suitable for containing other types of application logic.

        • Aleksandr Strutynskyy

          this statement is wildly incorrect, are you even familiar with react?

        • steve

          React has routes and the parent component is the controller for its descendant components and passes models down. So it does have controllers and models. The syntax is just different to angular. It doesnt have services but so what. That doesnt make it inferior to angular. You can still write vanilla js using fetch. Its just not as strict in its vocabulary as angular. That doesnt make it unsuitable for certain logic, unmaintainable, unreusable, inferior or unholistic. It just isnt as opinionated, as strict to enforce you to do it a particular way.

          • Nathan Armstrong

            It’s more like MVVM than anything, from what I’ve seen, when used well. Any actual logic for interacting with other services, performing business logic, etc. tends to happen external to the part of the application that uses React to render views. Unless you have an unpartitioned application, under which case you’re just writing spaghetti code.

            Take care not to stretch tools beyond what they are intended for. Push too far and you end up making your application very difficult to maintain, change, and reason about, since each shift pushes against the grain of the framework that was intended to make only a subset of those changes easy.

          • steve

            True. I agree a framework shouldn’t be pushed too far from it’s intended purpose. The syntax and organisation of code is different between react and angular but the component which you write in react, is a controller.

            Please forgive this very crude example showing react provides MVC, with the option of one missing component, services, which you can pull in externally. I wouldn’t say this creates spaghetti code. It is a matter of taste, if you are used to a different way of doing things, although this isn’t too far removed from traditional vanilla javascript.

            // (4) SERVICE
            // ajax method that will retrieve server data, and publishes changes to a redux json object.
            import equivService from ‘actions/someAction.js’;

            // component combines controller, model, view, and imports service to handle all tasks under one block.
            export default class MyControllerComponent extends Component {

            onChangeRadio(event) {
            // (3) CONTROLLER
            // do stuff here…
            equivService(‘new data’);

            // (1) VIEW
            render() {

            // (2) MODEL
            const modelX = this.props.modelX;
            return (

            // Collect changes from any other redux json object change
            const mapReduxJsonObjToProps = (reduxState) => {
            return {
            modelX: reduxState.prop,

            // Connect redux updates with this component.
            export default connect(

            Now this example doesn’t necessarily represent the best implementation. You can swap out your controller into another component if you wanted to. You could move the connect statement at the bottom into another file. There is a common pattern that a lot of developers use which is collecting the redux data into a separate file – called a container, which then passes the properties down to this component, which is a presenter.

    • steve

      Implementation of react will always have more than just the view. Current popular implementation is react plus redux. So angular can be compared to react+redux.

      • Nathan Armstrong

        No, not really. React is an implementation, not a paradigm, and is intended for view only. Sure, you can pack other logic into those views, but that goes against the grain of what the library is intended to do.

        Flux is a pattern for handling application state that happens to work well with React’s view and update model. Redux is one popular implementation of that pattern.

        Check some of the work that’s cropped up around ClojureScript wrappers for React, that may help flex your mind on what React is designed for and how it can be rethought in other ways. Om, Reagent, Quiescence each have a perspective they take.

        • steve

          I think you have replied to the wrong comment. I didn’t say react was a paradigm. Although every library or framework forces a certain paradigm. Interesting solutions though. I will look into those. Thanks. My comment was just correcting the one above that angular is ‘holistic’ and react isn’t is a pointless statement. Vanilla javascript is more holistic because you control everything.

          • steve

            Had a look at reagent, om and quiescent. Reagent looks the most ledgible. Still its a bit terse. Like regex for react components. I think react is popular because of jsx. It doesn’t remove itself too far from xml like syntax. These clojure alternatives are quite different and might be too much of a push away from familiar markup. Its possible they may gain traction but there will be a learning curve to pay.

          • Nathan Armstrong

            Yeah, they definitely lose the JSX aspect of React’s popularity, but they gain from the utility of using components instead of working directly with the DOM, and the efficiency and abstraction gains that flow down from that.

          • Nathan Armstrong

            I probably misunderstood “Implementation of react”.

            It’s not so much a matter of control as one of opinion, abstraction, and using tools for the purposes they were designed.

  • Luke Rodgers

    It’s a bit of a nitpick, but the survey shows that 64% of people *would use Angular 2 again*, which doesn’t necessarily mean people were *happy* with it — though that is how the author oddly titles and introduces that section. I would use Backbone again, so I would have answered “yes” to that question, but it doesn’t mean it would be my top choice, nor that I am completely “happy” with it. Happy is an unfortunately slippery term here.

    • brownieboy

      I’d go further and say that 64% is actually a very poor score for that kind of a question. To turn the answer around, over a third of devs that have used Angular say that they won’t be touching it again!

      Oh, and on that same graph, React gets a 92% score.

    • burkeholland

      Happiness changes on an hourly basis and it’s a really hard index to measure. There’s no way to know if that number actually would have gone up if the person answering it had been drinking a cold beer after getting a 30% raise that day.

  • CaRDiaK

    A framework locks you in. A library does not. Huge difference. Not only that but FB dogfoods React which carries a lot of weight, in my opinion. I’m not hating on Angular here, I just think it’s run it’s course and I for one won’t be looking at it. React and React Native provides so such flexibility with such a small API.

    • burkeholland

      Angular 2 isn’t for everyone. If you use React and love it, go forth and be awesome. There is no reason to change to a different framew….er…library when you are perfectly happy with the one you’ve got.

  • sarxion

    There are a lot of developers out there with solid OOP backgrounds in C# and Java that have no interest in just ditching decades of hard learned programming experience

    And this justifies the use of a broken feature in JavaScript? Honestly, if everyone had this mentality of “change is bad” we would still be stuck with unreadable code filled to the brim with “goto”s. If anything, TS is doing a terrible thing in deceiving thousands of developers in making them think JS inheritance works just like in whatever OOP language background they had (C#/Java)

    • burkeholland

      TypeScript is not for everyone. Myself included, but NativeScript is a really good use case for it. http://developer.telerik.com/featured/how-i-came-to-love-typescript/

      • sarxion

        TypeScript isn’t for anyone as far as it’s OOP concepts go.

        Keep your stupid OOP concepts. They aren’t welcome in our browsers.

        And arguments like this are extremely deceiving. No web developer hates OOP for no reason. A lot of us actually still enjoy doing OOP in other programming languages, the problem is OOP in JavaScript is broken, and failure to acknowledging this early on (which this article fails to do) will only lead to a bigger problem in the future.

        That’s because large applications require interfaces, some healthy amount of inheritance (gasp! I know) and the myriad of other structures that typed languages enjoy (and yes, modules). Those things were put into languages by really smart people for a reason.

        While there is some truth to this (strongly typed languages have some amazing pros), saying that because this has been “put into languages by really smart people for a reason”, it should be added in JavaScript is incredibly misleading. There is no denying JavaScript’s creator was an incredibly smart person, but he himself admitted he regretted how many parts of the JavaScript language came out.

        Again, just because ES6 standardized the “class” keyword, doesn’t necessarily make it a good feature. And by the logic of “every feature exists for a reason” to defend it, we could defend plenty of poorly written and negatively viewed JS features like eval and such.

        I honestly think you could have used so many other pros of TS to defend it, but it’s implementation of OOP? That’s by far it’s most controversial part, and imo a big mistake of this article. If anything, this article solidified why so many people don’t want TS to ever fully take off. We have enough developers confused with plenty of JavaScript’s confusing parts, we don’t need thousands more confusing Classical Inheritance with JavaScript’s own Prototypical Inheritance.

        • bmarkovic

          There is nothing “Classical” with Java and C#. OOP existed since 70s, and those languages were devised in the 90s/noughties.

          • derekgreer

            Rock me, Amadeus!

        • Todd Hilehoffer

          Have you changed your mind yet? Have you stopped coding JavaScript and moved on TypeScript?

  • guyAtHockeyBiasDotCom

    As a .NET developer I never went near Angular 1. But once I heard that Angular 2 was going to be written in TypeScript it became very appealing to me. After getting a bit frustrated with all of the RC changes I am very happy that version 2 is out and am working on my first project. I love it! Thank you Angular 2 team!

    • burkeholland

      This is the same sentiment that we see every day with NativeScript developers. A lot of folks are thrilled with where it ended up and are extremely happy with it.

  • steve

    The popularity of a framework can be decided by the job market and commutable distance from affordable areas. Currently there are more jobs in angular 1 than any of the above. Once a company has moved to a framework it isn’t likely to move for sometime due to the extra cost and pain of learning and ironing out its team for another. Angular 1 has already secured itself into lots of companies. Companies have targets to meet and bills to pay. The only incentive for a company to use a new framework, ie angular 2, is through force of their clients or encouragement from their developers.

    Clients dont give a monkeys. They only care that its quick for changes and fast. Developers just want to get a job and are tired of having to learn another framework just to get a job.

    They especially aren’t likely to encourage angular 2 because of its track recod of instability. It has left a bad taste in the mouth and has a bad reputation.

    I’m sure if angular 2 was held back a little longer until it had more extensive testing on itself before being made available outside its own company it wouldn’t have damaged it’s potential.

    I believe another 6 months of calm is going to be needed before angular 2 builds up any real steam, but in that time, for all the developers that have yet to move away from their current job of jquery to learning something easier than angular, reactjs has developed more headway, conquered more positions into those developers interest.

    • burkeholland

      Angular definitely didn’t do themselves any favors. It remains to be seen whether or not developers will forgive them. I can only tell you that from our customer base, nobody cared that it broke every other month. The demand for Angular 2 support in our products was deafening. React was just noisy.

      • brownieboy

        > The demand for Angular 2 support in our products was deafening

        Maybe they were hoping for somebody (anybody!) to come along and help them make some kind of sense out of the whole thing.

  • Tolis Christomanos

    I’m really afraid of developers coming from OOP languages to learn Angular 2 and Typescript first instead of JavaScript… How many low end mobile phones we want to explode? There are health and safety issues here guys!

  • steve

    With regards to –
    “There are a lot of developers out there with solid OOP backgrounds in C# and Java that have no interest in just ditching decades of hard learned programming experience”
    Those developers never wanted to touch html, css and javascript, not because javascript wasn’t oop based, but because they don’t want to get their hands dirty faffing around changing styling to a clients whim or design spec. they care about problem solving on reliable platforms, ie the server they are familiar with, not 10’s of different devices that might behave differently. There is a reason there is a divide between front end and back end developers. Jquery is still just much quicker to see results because you are manipulating the dom directly. Take away that power from a front end developer and then the client will be asking that of the now ‘backend developers’ who are quickly going to hand that responsibility back to the front end developer, who is now left in a limbo of having to pick up all these frameworks that quite frankly slow them down.

  • housecor

    I see three core reasons to bet on Angular 2:
    1. Inertia – Those who know Angular 1 are likely to find Angular 2 more approachable than alternatives.

    2. Comprehensiveness – There are opinions in the box on almost everything.

    3. Corporate backing – Both Google and Microsoft are helping push Angular which gives it a huge amount of street credibility. MS shops often only consider tools that MS recommends.

    The problem for Angular 2 is, these advantages are no longer a slam dunk.

    Angular 2 is significantly different than Angular 1 (RxJS, component model vs directives, new binding syntax, and so on). So much so that inertia isn’t a huge sales pitch anymore.

    And Angular 2 is more complex than React with Redux because it failed to embrace the most significant paradigm shift for eliminating complexity: React puts HTML in JS. Angular 2 puts JS in HTML. I describe why this issue is so key here: https://medium.freecodecamp.com/angular-2-versus-react-there-will-be-blood-66595faafd51#.deomnn5nf.

    Until recently, Angular 2 enjoyed a massive advantage in comprehensiveness. That’s a big deal because many enterprise developers love strong opinions. They like a clear recipe. They prefer to choose highly opinionated tools recommended by major vendors like Microsoft. Angular fits that bill.

    For the longest time this has been a weakness for React. There are literally over 100 React starter kits trying to solve the problem of decision and set up fatigue. But a huge shift occurred recently with the launch of create-react-app – a Facebook endorsed and supported way to build real React apps. This one decision suddenly made React extremely competitive with Angular 2 in comprehensiveness. You can clone the repo and begin coding immediately with a rapid feedback build process that’s production grade.

    In summary, Angular 2 will be successful, but not nearly as dominant as Angular 1. The competition is too good. React is objectively simpler, nearly equally comprehensive out of the box, and backed by Facebook which is dogfooding the project with over 20,000 components in production on Facebook.com.

    It’s going to be an interesting 2017!

    • burkeholland

      Some great insight in this comment. But I would expect nothing less from you Cory!

      I don’t think the fact that Facebook created a boilerplate (while awesome) affects the three reasons you laid out at all. I don’t think – and this is anecdotal from talking to customers – that enterprises generally view Facebook as being a purveyor of enterprise-grade software. We, as developers know that some of the best developers in the world work there, and therefore, their contributions to tooling are going to be legit. But to the suits that make the calls, they are a social network, not a serious software company. I believe that one fact will be why enterprises will continue to choose Angular 2.

      But I could be completely wrong. I’m wrong all the time; almost every day. Like you said, it’s going to be an interesting 2017!

      • housecor

        Well said and agreed Burke. In the JS community, FB is well-respected. But I agree that execs are likely to continue to respect MS and Google far more.

        Thing is, in JavaScript land, execs often aren’t making the tech calls. Dev teams are. Why? 3 reasons:
        1. No money is involved in the decision.
        2. JS is moving too fast for execs to keep up with the state of the art so they’re trusting dev teams more.
        3. Due to #1, it’s easy to pivot from one JS framework to the next when something better pops up.

        Thus, exec opinion is less relevant on the client than the server.

        JavaScript is freedom. And that’s a big reason I’m focused here. 🙂

    • hipertracker

      You are wrong. React does not push HTML in JS. JSX is optional and has nothing to do with HTML. It’s is only a syntactic sugar for JavaScript function React.createElement(). More, as you look at packages like react-native, react-art, react-canvas, and react-three, it’s become clear that the beauty and essence of React has nothing to do with browsers or the DOM.

      React is not a framework, it’s a JavaScript library for building user interfaces. So comparing it with Angular is like comparing apples to oranges. For having more fair comparison we could use e.g. Cerebral http://www.cerebraljs.com/. It has all features of the full blown framework but zylions times simpler than Angular 2. And it’s more powerful (unique router controlled by signals, the debugger with time travel, unique sync/async workflow controlled by Function Tree https://github.com/cerebral/function-tree, etc.) And Cerebral can work with different UI layers. Currently React, Snabdom and extremely fast: Inferno.

  • HyderabadRocker Prasad

    Looks like a marketing strategy for NativScript and nothing else. FYI I am a db guy and has been away from anything called frontend or UI for good 5 yrs now

    • burkeholland

      I take it you don’t miss the front end?

  • Aleksandr Strutynskyy

    “There are a lot of developers out there with solid OOP backgrounds in C#
    and Java that have no interest in just ditching decades of hard learned
    programming experience.”
    The worst javascript code with awful leaking abstractions I’ve seen, was done by those solid OOP C# and Java developers that don’t want to learn a new language and want every other language to look and behave like java, so they would be “familiar” with it.

  • Sam Ghaderyan

    It’s true. It all depends on your project and resources. In my current place, lots of code is written in JS by java developers that do not even know “var” is not block scoped. Also not a lot of even JS developers like to plug in different tools to start a project. For them Angular is better but I personally prefer React because of its benefits in universal apps, functional style programming, fast re-rendering, no need for templating language and easy component creation and reuse to name a few. If you have strong JS developers, you will probably choose React or rewrite your angular code in React 🙂 I know a lot of famous companies that did it I think mostly because of server side rendering and fast rendering reason.

    • burkeholland

      This is probably very accurate. To be honest, if I was going to go sans-TypeScript, I would naturally gravitate towards React for the same reasons that you listed.

  • Michael Snead

    The comment “Angular 1 is Angular 2” is going to be really hard to take “seriously”. While you certainly can write Angular 1.x apps in a more component-based fashion, the simple fact is that Angular 2 is an entirely different framework. Even your cherry-picked example is vastly different… Classes and decorators are not at all the same as plain objects and functions. Attaching to Angular 1.x “modules” using a window-level API is not at all the same as using ES6 to explicitly share import/exports.
    With the sort of comparisons you’re making you could just as easily say “Aurelia is Angular 2”, as you’ve ignored how binding syntax, dependency injection, validation, directives (ng1 vs ng2), controllers (ng1) etc. work.
    That says nothing about the veteran Angular 1.x developer who supports legacy applications that are nowhere as clean and pretty as your example above and followed all the cool/hip trends.
    JavaScript already is an “OOP” language by many definitions and certainly already has inheritance – which is not one of the shining pillars of the “benefits of OOP”. Interfaces *at design time* are nice, but you get about as much benefit from a competent IDE and TypeScript isn’t the only game in town (see Flow Type).
    One of the additions to TypeScript is the “protected” keyword. This allows classes up and down an inheritance chain to share internal state, and will be used to create the same problems we’ve had “for decades” in the server, where you can’t figure out which base class made the change that caused the bug to corrupt your data.

  • hipertracker
  • James Parsons

    Ughh, all this talk about FP in the comments makes my head hurt. Honestly, though, I think Angular 2.0 came too late. React (and Reacttive) have siply filled the hole. As a former web developer turning mobile developer, I simply can’t decide what to do. NativeScript looks nice, but it simply does not have the community drive other projects do. Ionic is ok, but it has the Hybrid stigma attached and React Native is simply not friendly towards Windows developers.

    Angular simply did not get released early enough to be pertinent. JavaScript moves to fast for my taste. I think it is about time I left JavaScript for something else.

  • bellasys

    Interesting Article and I love the discussion below. I only have 2 comments to add:

    Functional Programming is not a fad. It’s a trend and it always will be trending because it is a natural phenomenon. All software systems and languages for that matter slide toward FP, the same way that entire peoples slide left-ward on the political scale over time. And of course, the only place that maxim does not hold true are for the dead (languages|people).

    I am not a particular fan of JS or Angular, and I’m lucky enough not to *have to* have the same experience as others who are divided among loyalties, common efficiency patterns or the like. Yet I have had to make some impactful decisions about integrating front-end technology, templating, and systems integration. I get to review if I want a high-level language involved at all; as much as high-level languages have developed, so low-level languages make certain tasks do-able at practically bare-metal speeds. This was not really possible back in the day when JS was first establishing its identity. Back in the day it was uniquely useful, remember 1999 for those of you who were coding relevant apps back then. JS was browser-glue. Now that has changed, it’s usefulness has changed, and there are significant choices of implementation and even style.

    Whatever happens, it looks like JS is going the route of PHP: An industrial language which develops according to the needs of the masses. If you are elegant, elite, or you are employed by a business whose infrastructure leads you to *very little* JS; or your needs are such, you might have a specific strategy that leads you away from JS entirely, or you just might not be working on facing technologies… otherwise, you will have these important choices to make.

    Yes, in an industrial fashion I would prefer everyone to experience a similar framework and be able to use their brain-cpu-cycles for creating awesomeness rather than learning a new API every year; on the other hand, my needs for web applications and interfaces (systems integration), and the needs of the businesses I serve are so varied that I think it impossible to serve everyone well with one framework.

    The bottom line is that I am pleased Angular has made its stand. After all, you know what they stand for, opinions and all.

  • Farhad

    VueJS for small- & mid-size, React+Redux for mid- & large-size apps. Basta 🙂

  • brownieboy

    The key difference between React and Angular has always been that React makes you learn how to JavaScript, whereas Angular teaches you how to use, well…Angular! Take the example below, from the Angular docs:


    I don’t know if the above example is Angular 1 or Angular 2, but I do know that it’s a nonsense. “*ngfor” is an invented syntax that has zero transferability outside of Angular. Time spent learning syntax like this will be little help to you if and when you have to move from Angular to something else.

    For comparison, the corresponding React code would be something like:

    render() {
    let items = moviesArray.map((movie) => {
    return {movie.title};
    return {items};

    Note how my React example uses .map(), which is a standard JavaScript method, rather than Angular’s totally invented gobbledy-gook. Also, the React code will be in your JavaScript file, whereas the Angular example will be in your HTML. Because you know, if you’re going to be doing programming, maybe it makes sense to do it with your actual programming language, instead of shoe horning it into your markup?

  • Shea Martin

    While I think it is great (especially for TS) that Ng2 ships with TS as the default, I use React with TS and it works great. TS with Redux is a mess, but use something like MobX (which has momentum) with React, and it plays beautifully with TS. We have built an Enterprise app with Ng1, but our next app will likely be React+MobX+TS. The main reasons are the simplicity of React, and flexibility.

    I have yet to hear a strong argument against TS. Nobody says you have to completely change the way you code everything you do because you switch to TS. Use FP if you want, just use TS to add a little safety for you life. Think of it as a more pro-active version of eslint. Or let me guess, you are too awesome to need eslint as well.

  • Angular is a piece of crap, specially for Native Script (why in the world I can’t use self-terminated ?)
    Why not Aurelia? Why???