You need to learn Angular 2

Reading Time: 5 minutes

TLDR: Even if you don’t ever plan on using Angular 2 in a production webapp, you should learn it and here’s why.

It’s no secret that with the rate of usage and adoption of Angular 1.x is incredible.

Momentum chart
Momentum chart

The ease, accessibility, and expressiveness in web development today is incredible. With the increasing size of web developers (at least in the US), scores of frameworks are being constantly released (sometimes it feels like daily). It can be difficult to pick the right web development framework for an app.

The benefits of Angular 1.x are smatterd across the Internet. Although they are out of scope for this post (and honestly, a single Google search will answer better than I could), we’re going to focus on why Angular 2 matters and what it means for you and your team.

Angular 2 is not just another framework

Component-based web development is pretty much the future of web development. If you’re unfamiliar with the component development pattern, it basically emphasizes the separation of concerns throughout a given system (Wikipedia). For all the benefits of using Angular 1.x, it requires the entire stack to be written using Angular. Web components, on the other hand emphasizes the separation of concerns and allows segmentation within an app to be written independently of each other. If you’re familiar with the module-loading mechanism in Angular 1.x, this should come as no surprise. Angular 2 takes this a step further and requires nothing else to be written using Angular.

Angular 2 is more important than you think

Angular 1.x took great ideas from other frameworks and wrapped the process into a pleasant development environment. It does a great job of abstracting a lot of difficult parts of web development so allow us to focus on the functionality of our applications. Rather than dealing with module-loading orders, finding and injecting dependencies, and made building custom components incredibly easy, we could just focus on business logic. These benefits are no longer a convenient feature, but almost a requirement out of any thick-client web framework. With transpilers (such as BabelJS), we’re taken out of the ivory tower and can (and should) start using the pattern today.

Not only does Angular 2 keep this pattern, it makes it a requirement to core development. Take the very first example in the (official current) Angular 2:

There it is, a simple component completely isolated from every other part of our application. If we want to build and use another component, we simple do. There’s no ceremony, no major refactor to support the new functionality. It just works. This idea is fundamental to using the web component pattern and it is here to stay. Angular 2 makes learning and using the pattern easy.

Another really cool and important piece to notice from the example is that the business logic of our application is just JavaScript. There’s no magic in writing JavaScript objects (well… that’s exposed to us, the developer). It is just JavaScript. This makes things really easy to test, to write, to share and expose. Seriously easy.

Sharing code (aka letting someone else do the work)

If you’ve ever built any software worth it’s keyboard salt, you’ve likely used other libraries written by someone else. We’ve already discussed how Angular 1.x abstracts away complexities in software, component-based development not only allows us to write our pieces independently, it also allows us to use other components written by someone else in another framework (be it Angular or not). This is the real saucy promise. Find yourself needing an AutoSuggestion field or a credit card checkout form? Likely someone else needs it too and has written it.

The best software I write these days is the software I don’t write.

Polymer, WebComponents, React , and Angular 2 take this concept seriously (although in different ways). In our opinion, Angular 2 takes the best ideas of these other framework contenders and wraps them up the right way. We diver deeper into these concepts in ng-book 2.

Comparing Angular 2


Let’s get this out of the way first: Angular 2 does not require TypeScript.

So… while trying not to start a flamewar here, but types are awesome. Typescript, the markup language sits atop JavaScript that needs to be ‘compiled’ to JavaScript (browsers don’t yet know about TypeScript). A logical question to ask is why use TypeScript in the first place? How does it make sense to compile a language that can be executed without the pains of compilation?

The answer: error checking, documentation, and share-ability. Just as tests allow us to be confident that our app is running the way that we expect, types force us to only call our functions with expected types. For instance, take the following function:

Despite the terrible naming, it’s pretty obvious what this function does, right? We pass Numbers into the function and get out another number. Later in our app we realize it’s important to show significant bits of a number to a certain amount of precision (for instance in cents). Taking our example a bit further, let’s use our computeTotal function to compute the total our customers would pay including sales tax:

Great, now our functionality is done, right? What happens if we don’t pass a number into the function, for instance a JSON object from a backend doesn’t give us a raw number, but instead returns a string — happens more often than I’d like to admit). When we call our add function, it’s not going to do anything different than what we told it to do and it’ll look kinda funny:

Umm… not quite right. Typing can help us fix this problem:

Now when we call the computeTotal function, we can ensure that we’ll only send a number in (compiled with type–checking), so rather than showing our crazy string from above, we’ll throw an error instead. If we write a test to check on the usage, we can be sure that our computeTotal function works as expected.

TypeScript is not a requirement of Angular 2, but it is awesome.

Seriously, learn Angular 2

Although there is so much more to Angular 2 than we roughly covered here, we strongly recommend learning it. Not only will it help you and your team be faster and write better code, it will make you a better software developer overall. Invest the time into Angular 2. Seriously.

  • Dustin Davis

    I tried the demo for Angular 2. I REALLY wanted to like it. I’ve got tickets to the coveted ng-conf for the third year in a row. But alas, I hated the syntax. So many symbols make it harder to write & grok the code. I hated TypeScript too. They managed to make JavaScript more verbose and unpleasant.

    I looked around for alternatives. I’m starting my next project with Aurelia.

    • Tiago Braga

      Symbols? You mean the decorators?
      You are not forced to use them. That is just ES2016 working.
      You can simply develop your application with ES5.

      • Felipe Coury

        Tiago, I think he means using brackets and parenthesis for attribute setting and event handling.

        • Tiago Braga

          You still are not forced to use them.

          For properties for can use bind-* and for events you can use on-*.
          I guess that is the correct syntax.

      • Dustin Davis

        No I’m talking about in the templating syntax. I’m a python developer so I have no issue with decorators.

        • Tiago Braga

          You are not forced to use that syntax.

          Instead of using [property] and (event), you can go with:
          bind-property and on-event.

          • Dustin Davis

            Yeah, I recently learned of this alternate syntax. I would definitely use this over the symbols.

    • Noro Korny

      On the contrary, I love the Typescript for the simplicity (as opposed to the javascript) – defining a class for example Strong typing definitely doesn’t do harm either.

      • Dustin Davis

        Just use ES6/ES7. I’ve never said, “I wish I had strong typing in JavaScript.”

        • Andreas Kroll

          I didn’t know that Angular 2 development was only to satisfy YOUR needs. I think the majority of developers will like typescript as it tends to get rid of a lot of errors that happen in javascript if you are not extremely careful.

          • Dustin Davis

            Of course it wasn’t. That’s why I’m not using it… or TypeScript. πŸ˜‰

          • Andreas Kroll

            Seems to be Google, Microsoft and a lot of intelligent people are wrong and you are one of the few brave knights that uphold the old syntax.

          • Dustin Davis

            Did I every say they were wrong for using it? It seems you are taking this very personally.

          • Luis Sierra

            Looks like we have a badass over here!

          • Samantha Atkins

            I am not the majority and frankly I consider the majority stupid if they fall for this embrace and extend trap locking typescript in.

          • Michael Schore

            Aren’t you just the most special of snowflakes.

        • Adam

          “Just use ES6/ES7. I’ve never said, ‘I wish I had strong typing in JavaScript.'”

          I have seen other people make this sort of statement, and I do not understand it at all. If nothing else, strong typing (or static typing, or any other combination of those two terms that you want to use to describe a language like TypeScript):

          1. Gives you more information about code, especially code you haven’t written yourself, which makes it easier to use without having to constantly refer to the documentation (which surely exists…)

          2. Stops you from making simple mistakes, even with code you’ve written yourself, because the types of inputs and outputs to/from functions are checked at compile time

          3. Allows you to easily find all uses of a particular type, and refactor code easily if needed. In addition it allows IDEs like Visual Studio to offer features like IntelliSense which makes writing and navigating code significantly easier

          I have never heard a coherent argument against strong typing – TypeScript or otherwise. The two complaints I see most often are verbosity, as you mentioned, and the hassle of having to compile/build your code.

          I have slightly more sympathy for the compiling/building argument in the case of TypeScript, because in the end you do end up with plain old JavaScript, so I can understand that it seems like a bit of a hassle to have to set up a build process for something that wouldn’t otherwise need it.

          But if you’re doing anything like minifying or bundling your JavaScript files, or you’re also writing your own server-side back-end, or you have an automated deployment process for your site (are you seriously doing none of these things?), then you already have a build process and so the “hassle” of having to introduce TypeScript into your build is not a good argument against it.

          As for the verbosity complaint, I have no sympathy for this whatsoever – especially with regards to TypeScript. TypeScript is a superset of JavaScript, and you can use as little of its extended syntax as you like. A lot of the typing is implicit, and there are shorthand ways of doing things, so you really don’t end up with a lot of extra code compared to JavaScript. It’s about as concise as it can be while still having static/strong typing.

          I am yet to hear a compelling argument as to why strong typing with static type checking is worse than weak typing with minimal dynamic type checking.


      Why bother looking for an alternative to Angular 2 when you can continue working with Angular 1.5 into the future.

      The Angular team is going to continue iterating on Angular 1 along side of 2 so there’s I need for developers or companies to have to move to Angular 2 or another framework from Angular 1 if they are already happy and proficient with that framework version.

      There seems to be a movement within the Angular community that you must either evolve from 1 to 2 or find a new solution for your isomorphic web application development needs. When in all actuality Angular 1.x is so mature, feature rich and stable, you could continue developing with that framework for the next few years without needing to find another solution for your business problems in the web app space.

      • Dustin Davis

        Yeah, we thought about that too but in the back of my mind I think, if Angular 1.x is so great, why are they completely rewriting it? And of course there are things in Angular 1.x not to be liked that are solved by many of these newer frameworks.

        • michael corbridge

          Why ng2? Watch ng-wat on YouTube then come back to me.

          • Dustin Davis

            I was there in person

    • michael corbridge

      If you have never worked in a multi-developer, multi-national, multi-timezone, multi-version project where code is concisely organized into packages, classes, and valueObjects … then why on earth use Typescript? For the rest of us: Hallelujah!

      • Tony Brown

        seems to me teams have been doing it with POJO for a long time now, you just need to understand JavaScript a bit better maybe?

    • Amaredeus

      Seems like Aurelia is a UI based framework. It’s not accurate to say that Aurelia is an alternative to Angular2.

      There’s a post online by a Google engineer regarding those who compare React vs Angular2, “Also, let’s not compare Apples to Oranges, as people usually do. React is a library for your view rendering. You have to go out of your way to look for other pieces like architecture like Flux, routing, authentication e.t.c. Angular on the other hand is a comprehensive framework and not just a library!”.

      Angular2 is so much more than a UI framework. It is incredibly powerful and efficient.

  • Shahzad Nawaz

    Hi.. ng-book team, You are doing a great stuff.

    Angular 2 beta released ! How much it would take you guys to update your book with the final (at least beta) changes to this book ?

    Thanks !

    • Felipe Coury

      Hi Shahzad, we are actively working to update all the existing chapters. I think it will be done if not by end of this week, at the beginning of next one.

      • Shahzad Nawaz

        Sweet ! I wish you guys very gud luck. πŸ™‚

        • Carlos Taborda

          Thanks @shahzadns:disqus ! πŸ™‚

  • Sean

    I have no doubt ng2 will become the defacto… the only reason React took off is because it found a nich time between Angular 1.5 being downplayed by Google and the announcement of Angular 2 by google which was still not available. So React found a perfect timing to catch the eye of developers looking for a new framekwork. With Microsoft and Google both supporting Angular 2 (not to mention 80% of the browser market)… Angular 2 (and ES7) will become the standard… hey don’t take my word for it… just look at Angular 2 slogane from Google: “One framework” in other words, the one to rule them all… + ngAnimation 2.0 coming + polymer for ng2… it will be AMAZING;;;; Thanks for a great article… I just posted a massive Angular 2 bootstrap project. Anyone interested om Angular 2 will love it. Check out the working demo @ and source at:



  • planetoftheweb

    I have to say. I’m working on some Angular 2 projects, and I’m somewhat disappointed at the Angular Team. You say that ‘you can write in ES5’, but the documentation for that is pretty weak. My problem is that learning Angular 2 in the version that has the most documentation means Typescript and that means understanding not just Angular 2, but Also ES6 and TypeScript. The ‘simple’ example at the angular 2 site involves installing a transpiler, a server and a module manager. The whole thing doesn’t translate into something that people can understand unlike the 1.x quickstart and it doesn’t even give you the same sense that you’ve ended up with something awesome like the original example. Understanding the quickstart example is frankly exhausting.

    Ultimately, I think that the language and the component structure is great, it’s just that the barrier of entry and the understanding that someone not already working with TypeScript, ES6, transpilers, module loaders, etc is going to see the ‘quickstart as alien’ and too difficult to grasp.

    • michael corbridge

      Re Typescript: I felt the same way. That was until I npm’d Typescript, git cloned a ng2 ‘hello world’ app – and WOW! Finally! For someone from the Java/AS3/Flex world … THEY GET IT! Classes, interfaces, inheritance, strong typing, the IDE (Intellij) instantly applies code hints. Finally … cosmic order has been reestablished.

      • Dustin Davis

        Everything you mentioned that you love is ES2015/ES2016 features except strong typing, right?

        • Christian Matthew

          but the point is… lets say I don’t want strong typing and just want es6… it still has to be transpiled into something today’s browsers can read… so why not just use typescript? See what I mean?

          • Dustin Davis

            Or just use Babel for today’s browsers and then at some point you won’t need a transpiler for tomorrow’s browsers. If you use typescript you will always need a transpiler – unless you never make use of the strong typing and just use ES6 and typescript as your transpiler – but then you aren’t really using typescript are you? You’re just transpiling with typescript’s transpiler.

    • Blacksonic

      this repository can be a good starting point for those who just want to get a feeling of Angular 2 without Typescript

  • Obzerver

    I am trying to find some information on how to deploy Angular 2 apps to production environment . I tried to find in the ng-book 2 . Is that section covered ? I couldnt find it in the contents.

  • Pfaff Venter

    I purchased ng-book 2 online; however I have not received the book. I tried following up my purchase via email to but only received an automated reply, please let me know how I can get hold of my copy?

  • Emmanuel Oluwagbemi

    “The best software I write these days is the software I don’t write.” I wouldn’t boast of that.

  • Gaurav Chandra

    I have not tried angular 2 yet as I am waiting for ngbook2 to be final but from a very high perspective, I find that there is a barrier to entry like installing npm modules, webpack configs etc. I did a hello world app without writing any custom code apart from what the generator used, and I was shocked that the app was 2.52MB in size! What happened to lean software? Then to reduce that size, I have to spend time on writing webpack config, which is clearly waste of time.

    In case of angular 1, I just need to include one file and rest plugin or directive files based on the requirement. I am still making my apps in angular 1.5 as it is lighter and faster for me to develop. Still waiting for the book to complete and I will then wet my beak. Probably that will change my opinion for the good.

  • Johann Stocklands

    Looking for a comprehensive Angular 2 introductory course? Check this out! πŸ™‚

  • dizhar

    In the long run Angular 2 will be worth it. It’s designed for large scale applications and up-scaling them . Large companies are going to love it. It’s definitely not something I would use for small projects.

  • Samantha Atkins

    Right now it does require typescript. Javascript use is not documented or common.

  • Phillip Parr

    The first ES6 example in this post is much less readable than the ES5 example given directly underneath. I’m all for making code smaller, but when you change the syntax from something that looks similar in every other C based language to something completely different… you’ve gone wrong.