Angular 2: A Guide for Beginners

DZone 's Guide to

Angular 2: A Guide for Beginners

A comprehensive guide covering the introductory steps for the Angular 2 platform as well as a few other development tools.

· Web Dev Zone ·
Free Resource

For about half a year, I've been organizing a local Meetup group around Software Craftsmanship. I recently also published a video course on "Learning Angular 2 Directives" and given that Angular 2 finally released RC1, I decided to organize a Meetup session to introduce Angular 2 to our members.     

Click to get access to the slides   


This article is for those of you who are new to Angular 2 or even to web development in general. Here, I’m going to give you a good overview of what Angular 2 is all about, highlighting some of the main concepts behind. The idea is to give you a good starting point.

If you did already some coding examples in Angular 2, then I’m probably going to bore you.:smiley:But maybe you want to dive deeper with my Learning Angular 2 Directives video course I recently published.:wink:

Big Picture

Here’s a simple classification of today’s web application architectures.

In server-side rendered applications, most of the application’s logic resides and remains on the server. The user basically enters the URL, the request gets sent to the server, which then produces the final HTML containing the requested data and sends that back to the browser—which simply renders it out. When the user interacts with the page, that request again gets sent to the server, which in turn generates a new HTML page and serves it back to the browser.     

This is how the web has been designed, a perfectly valid model that many pages still use today.

But modern web pages are often required to work more like applications do on the desktop. People demand a much better user experience, more interactivity, fast transitions between “pages” and even offline capabilities. That’s where the so-called SPAs (Single Page Applications) come into play.

When the user enters the URL, the web server responds with an HTML page, but also with a set of resources (JavaScript files and images) that make up our client-side application. The browser receives that, loads the JavaScript application and “boots it.” Now it’s the job of that application to dynamically generate the user interface (HTML) based on the data, right from within the browser. After that happens, every new user action doesn’t reload the entire website again, but rather the data for that specific user interaction is sent to the server (usually by using the JSON format) and the server, in turn, responds with only the data requested by the JavaScript client, again using JSON (normally). The JavaScript application gets the data, parses it and dynamically generates HTML code which is shown to the user.

As you can see, the amount of data that is being exchanged is optimized. However, a big downside of such type of applications is that the startup time is usually much longer. You might already have figured why: The browser doesn’t get the HTML code to show, but rather a bunch of JavaScript files that need to be interpreted and executed, which then generates the final HTML to be shown to the user.

I'd like to show you some examples of the third type of web application I’d like to show you. As you might guess, it aims at taking the best of the server-side rendered web apps and SPAs.

In a nutshell, when the user enters the URL, the server loads the JavaScript application on the server side, boots it up and then delivers the already (by the JavaScript app) pre-rendered HTML plus the JavaScript app itself back to the client. There, the browser interprets the JS app and runs it, which has to be intelligent enough to resume where the server has left off.

The advantage is obvious: You get fast startup times and the benefit of a SPA as mentioned before.

Why Angular 2? What’s Different?

Ok, let’s get to the meat. Why should you be interested in Angular 2? Here are a couple of things I picked up mainly from Brad Green and other core member’s talks from a couple of the latest conferences.

At his keynote at NgConf 2016, Brad Green named Angular 2 a platform rather than a library or framework. The main reason is that it is split up into modular pieces built upon each other, some of which can even be used outside the Angular ecosystem.

There are some building blocks, like the dependency injection, decorator support, zone.js (which can be used completely independently from Angular and is currently under discussion at stage 0 at TC39 for being included in the ECMA standard), a compilation service, change detection, and a rendering engine (which is platform independent). On top of that, there are other libraries such as Angular Material (a UI library with material design support), mobile, and Universal, etc.

There are even modules such as i18n, the router, and animation that can be used from within Angular 1.x as well.

Extremely fast!

Angular 2 is designed to be extremely fast. Well, every new JS library would probably claim that, but there are some differences in the approach Angular 2 is taking.

First of all, they’re currently working on a so-called “template compiler” or “offline compiler." Many JavaScript frontend frameworks basically render the templates dynamically into the browser’s DOM at runtime, which requires a templating engine of some kind. Angular 2 templates and components are made in a way that Angular 2 is able “to reason about your app’s templates” and is able to generate an AST and consequently to translate them into pure JavaScript at compile time. This is huge.:+1:

As a result, your deployed app doesn’t require any templating engine to run, but it rather contains highly optimized JavaScript code for directly manipulating the DOM. That’s super fast and, moreover, the resulting Angular 2 library gets a lot smaller, as you don’t need its templating engine anymore when you deploy in production.

And that leads us to the next part.


The library gets really, really small.

By being able to strip out useless parts, a lot can be dropped when deploying in production. Furthermore, the goal is to use a bundler that supports tree shaking and thus reduces the size of the final compiled JS files even more by eliminating everything that is not actively being used within your application. Frankly, if you don’t use the routing module of Angular, it simply won’t get included in your final app.

Tree shaking is basically “dead code elimination”. By analyzing which JavaScript modules are used and which aren’t, compilers that support such approach can eliminate the unused parts and thus produce a much more optimized and smaller bundle. Obviously a proper module system such as ES2015 modules has to be used for this to work.

Built-In Lazy Loading

Finally! Lazy loading has been a hot topic for Angular 1.x and many other frameworks. When you build a serious application, it might get quite big pretty quick. That said, you cannot force your users to download megabytes over megabytes just to get your app booted up, especially on flaky Internet connections or mobiles. That’s why lazy loading needs to be implemented. The idea is to load only those parts the users most heavily use and load other parts on demand when needed. This was particularly hard in Angular 1. ocLazyLoad being one possibility to achieve this.

Now with Angular 2 this is finally built-in right from the beginning, through the framework’s router and so-called “lazy routes”.

Unfortunately, the router has been rewritten and thus there are no docs at the moment. It should be available shortly. Till then, you may want to give this video a go, where Misko Hevery explains it.

Angular Universal

This is Angular 2’s answer to isomorphic JavaScript or server side pre-rendering. Again, it’s all about performance, to get the app to the user as quickly as possible.     

Angular-universal is a library that lives under the Angular 2 GitHub repository with the goal of making server-side rendering as easy and straightforward as possible. Since Angular 2 is made to be platform agnostic, it can be executed in non-browser environments without many issues.

So, when loading a universal Angular 2 app, from a high-level perspective, here's what happens:

  1. Your user opens your universal Angular app, perhaps also invoking a client-side route like http://myuniversal-app.io/people/detail/1
  2. Some angular-universal compatible server gets the request, knows it is a client-side route and thus boots the Angular 2 root component (usually app.component.ts) on the server side and executes it.
  3. The server then delivers the already rendered application state of that invoked client route inside index.html back to the browser.
  4. The browser renders the HTML, so the user will see the person with id 1 rendered immediately (as it is already present in the HTML)
  5. Meanwhile the Angular 2 app boots again, but this time on the client-side (the browser) in the background (in a hidden div, basically). A library, preboot.js, records all user events, like clicks and input changes, until Angular 2 is fully loaded.
  6. When the Angular 2 app is ready, it will have the same rendered state as the server has delivered previously. preboot then replays all of the user events against that client-side rendered app.
  7. Finally, the client-side rendered app gets activated and the server-rendered HTML is dropped.

That was from a bird's-eye perspective, but you get the idea. A good place for more details is the quickstart guide. Also, the universal-starter repository has some good examples to play around with.

Currently, the angular-universal-supported server frameworks are Node and ASP.net. But support for Java, Go, and PHP is the works.

Unified Development

Something I’m particularly excited about is having a unified development model.

You can choose among four different possibilities for developing mobile applications with Angular 2.

Angular Mobile Toolkit focuses mostly on a new architectural approach for creating web applications: Progressive Web Apps (PWA). These are normal web applications that facilitate modern web technologies like service workers for offline caching and a special (non-standard right now) manifest file that instructs Chrome to provide “installation like capabilities” for the app. It can be added onto your home screen. Even better, Google I/O 2016 was all about PWA development. Just check out some of the talks on Youtube. Also, JavaScriptAir’s latest talk on it might be relevant.

Ionic 2 is a hybrid mobile application framework. That just means you build a web application and package it in a native installable package for iOS and Android, which can be installed through the corresponding app stores. The app itself is served through a WebView component, which means you’re running a web application in the end. Access to underlying APIs is achieved through Apache Cordova. Ionic specializes in providing you the tools for setup and building the native app packages. Moreover, it gives you a highly tuned UI framework and mobile routing support. They recently also announced future support for PWAs, so it’ll be quite interesting to see it evolve.

NativeScript is a framework developed by Telerik. Different from Ionic, it “compiles” to a native application. Actually, your JavaScript code is being executed through a special JavaScript VM, like Chrome’s V8, which builds the bridge to the underlying native platform. But anyway, take a look at this video with John Papa, Burke Holland and TJ VanToll showing off some NativeScript capabilities.

React Native—It's even possible to use React-Native with Angular 2. Unfortunately, I haven't done anything with it yet, so you may want to browse the web for it if you’re particularly interested in this one.

Installed Desktop

When talking about “installed desktop” we don’t mean like running an Angular 2 app on a desktop browser, but rather to run it inside an installable application. This is powered by Electron and Windows Universal (UWP). Watch what Brad Green had to say about it at NGConf 2016.

A very important point here that’s easy to miss: By running Angular 2 directly from within a web worker, not only you get an enormous performance boost, as it runs in a separate thread, but you also get access to the underlying platform, databases etc..

Not convinced? Well, chances are you’re already using an Electron app, like VSCode, or Slack or some of these:     

The 7 Key Concepts behind Angular 2

At NGConf 2016, John Papa had a slide in his talk describing the seven main key concepts behind Angular 2. These really nail it.     

Modules and the ES2015 story

Ok, at this point I should probably stop, and we should take a broader look at what modules are all about.

Initially in web development, you most likely did something like this:



<script src="./vendor/jquery.min.js"></script>
<script src="./vendor/super-awesome-datepicker.min.js"></script>
<script src="./myapp.js"></script>

You simply include the required JavaScript files in the correct order. Within your myapp.js you might have:

function initDatePicker(someDateValue) {
value: moment(someDateValue)

A couple of things to note here. We rely on global state and libraries to be loaded, like $ for jQuery and moment and superAwesomeDatePicker. These libraries need to be present at the moment this function is executed. Meaning you have to load all of the scripts in the right order based on their respective dependencies. This is simply not feasible for large scale applications with hundreds of different JavaScript files. That’s why module systems have been created, like the AMD standard implemented by—for example—RequireJS:

define(['jquery', 'moment'], function($, moment) {
function initDatePicker(someDateValue) {
value: moment(someDateValue);

return initDatePicker;

Note, we now have imports where dependencies called jquery and moment get defined somewhere and imported as $ and moment inside this specific file. In turn, functionality within this file gets exported with return initDatePicker. It can be imported by other files in the exact same way. And so on.

This worked, but it wasn’t always ideal. Or better, there have been different patterns around and they weren’t always that nicely compatible and interchangeable. With ES6 or ES2015, the TC39 (the committee deciding over the next ECMAScript features to be implemented by browsers) finally specified a standard syntax for defining JavaScript modules.

import * as $ from 'jquery';
import * as moment from 'moment/moment';

function initDatePicker(someDateValue) {
value: moment(someDateValue)

export initDatePicker;

A much more clear and expressive syntax.

Another notable feature that many developers coming from languages like Java or C# may like are classes and inheritance:

class MyApp {

constructor(someDateValue) {
this._someDateValue = someDateValue;

get someDateValue() {
return this._someDateValue;

set someDateValue(value) {
this._someDatevalue = value;

static someStaticFunction() { ... }

Finally, another construct we need to learn about to understand Angular 2 apps are decorators.

export class MyApp { ... }

These simply provide metadata to the underlying framework, in this case Angular, about the class. There is currently a proposal for decorator support in ECMAScript. Also, despite what some may think, decorators are not annotations in JavaScript.

Annotations and decorators are two competing and incompatible ways to compile the @ symbols that we often see attached to Angular components. Annotations create an "annotations" array. Decorators are functions that receive the decorated object and can make any changes to it they like.

Traceur gives us annotations. TypeScript gives us decorators. Angular 2 supports both. nicholasjohnsom.com

Also, check out the article on Thoughtram on this topic.

So, can I use all of this in the browser right now? No, unfortunately not. What you need is a compiler or transpiler. Currently, Babel and TypeScript are the most popular ones.

The Angular team decided to go with TypeScript and has written its entire codebase with it. TypeScript was created by Microsoft in 2010, going public in 2012. But it really kicked off only recently with Angular 2. The main difference to other transpilers is that it adds optional type support to JavaScript. First of all, this helps discover and prevent nasty errors at compile time and opens up numerous possibilities for better tooling support.

OK, wait, how is this relevant for Angular 2? Angular 2 is written entirely in TypeScript, and while it’s not impossible to write Angular 2 applications in ES5, it is highly recommended to write them in ES6 or TypeScript to get the best out of it. This way you can start using all of the mentioned features on modules, classes, decorators, and much more we didn’t even cover.

Long story short, you should get accustomed to the new features of ES2015. Browse the web or check out my article , which gives you a quick intro and links to many other useful resources.


Component-based architectures are the new paradigm for frontend development. This is not something particular to Angular, but it's something that’s shared among other libraries like React, Ember, or Polymer. The idea is to build autonomous pieces with clearly defined responsibilities that might even be reusable across multiple applications.

So what are web components about? Roughly speaking, it’s about defining custom HTML tags and their corresponding behavior.

<google-map pointer="46.471089,11.332816"></google-map>

It’s a powerful way to express semantics, isn’t it? By simply looking at this HTML tag, we know that it’ll render a Google map and set a pointer at the given coordinates. Neat! Currently, this isn’t something the browser understands natively, although there’s a draft spec document on the w3c website on the web component standard and what concepts it should embrace.

You might also want to check out Polymer and webcomponents.org.

Angular 2 fully embraces this component-based development style. In fact, since the beginning of Angular 1.x, allowing the user to define custom HTML elements with behavior was one of the core philosophies of the framework. A simple component in Angular 2 looks like this:

selector: 'hello-world',
template: `<p>Hello, world!</p>` })
class HelloWorldComponent {


In the corresponding HTML, you would write this to instantiate it.


As you can see, decorators are being used to add meta information about the tag of the component, about the template that should be rendered and much more, which aren’t being used in this basic example here.

"Components are first-class citizens in Angular 2"

Now with components being a first-class citizen in Angular 2, there’s the concept of the so-called component-tree. Every Angular 2 application consists of such a component tree, having a top-level “application component” or root component and from there, lots of child and sibling components.

For example:     

 And this could then be mapped to HTML code like as follows.

The component tree is of major importance in Angular 2, and you will come across it again. For example, this is how you compose your application, and the arcs from one component to the other are the way data is assumed to flow through your application as well as what Angular uses for change detection.

“Change detection” is the mechanism by which Angular determines which components need to be refreshed as a result of changes in the data of the application.

Templates and Data Binding

Obviously, when we write something like <hello-world></hello-world>, we also need to define somewhere what Angular should render in place. That’s where templates and data binding come into play. As we’ve seen before, we define the template directly in the @Component({}) annotation by either using the template or templateUrl property, depending on whether we want to define it inline or load it from some url.

template: `
<p>Hello, world!</p> `
class HelloWorldComponent {}

We also need some data binding mechanism to get data into this template and out of it again. Let’s look at an example:

selector: 'hello-world',
template: `
<p>Hello, </p> `
class HelloWorldComponent {
who: string = 'Juri'

As you can see, the variable who inside the component’s class gets bound to into the template. Whenever you change the value of who, the template will automatically reflect that change.

Services and Dependency Injection

Besides components, Angular always had the concept of Services and Dependency Injection. So does Angular 2. While the component is meant to deal with the UI and related stuff, the service is the place where you put your “business logic” so that it can be shared and consumed by multiple components. A service is nothing else than a simple ES6 class:

export class PersonService {
fetchAllPeople() { ... }

From within some component, we can then use this service

import { PersonService } from './services/person.service';

provider: [ PersonService ]
class PersonComponent {
constructor(private personService: PersonService) {
// DI in all it's beauty, just provide TS type annotation and Angular will handle the rest
// like adding the reference of personService to the class
// no need for "this.personService = personService;"

ngOnInit() {
this.people = this.personService.fetchAllPeople();

Nice, we get a reference to PersonService from within our component. But wait, who instantiates the class? You guessed it, Angular’s dependency injection. For this to work you need to two things:

  • add the @Injectable annotation.
  • register PersonService as a provider either on the app, the top level component or from the part of the component tree (downwards) where you want to have the service injectable.

Reactive Programming With RxJs 5 and HTTP

Angular 2 uses a paradigm called “Reactive Programming." This is implemented through the RxJS 5 library. The Angular 2 HTTP service won’t return promises, but instead RxJS Observables.

This pattern is not new at all and has recently gained a lot of popularity in modern frontend development. I’m not going into the details here now, as it would be an entire article on its own. Just know that Angular 2 will heavily rely on it and that’s why you should probably go and learn more about it.

Lot’s of Stuff, Let’s Get Started With Some Code

In recent years, getting started quickly with frontend development got notably more difficult. Just creating some index.html with a couple of <script> tags is not enough. What you need is a transpiler and a build tool that transpiles the code and serves it up, not to then mention optimizations like minification, inclusion of HTML templates, CSS compilation etc.

Just some of the tools being used in modern JavaScript development (not mentioning frontend frameworks here, just tools).

Some build tools/module bundlers you should definitely take a closer look at are  SystemJS and Webpack. These are currently at the base of most Angular 2 projects. To make this easier, the Angular CLI project has been created. Mike Brocchi, core contributor of the CLI project demoed it at NGConf 2016.
The CLI allows you to do things like:
$ ng new my-super-awesome-project
$ ng g component my-new-component
$ ng g route hero

Moreover, it generates these components by following the official styleguide and has even linting built-in.

Angular CLI is still under heavy development and still has some way to go till it’s fully usable. But it’s awesome for quickly getting started, and I’m quite sure it’ll get better and be a huge help, especially for newcomers, to get started with Angular 2 without having to know all the tooling in depth (recently Webstorm integrated Angular CLI support). However, I also strongly recommend learning these tools as you go along. The CLI will bring you quickly to a good point, but it’s indispensable to know your tooling to get further ahead.

Here are some other popular starters you definitely want to take a look at. They are community-based, have lots of best practices bundled and have been around for quite a while now.

Here's an Angular 2 starter kit featuring Angular 2 (router, HTTP, forms, services, tests, E2E, Dev/Prod, Material Design, Karma, Protractor, Jasmine, Istanbul, TypeScript, TsLint, Codelyzer, Hot Module Replacement, Typings, and Webpack by @AngularClass. 

Okay, We’re All Set Up, I Guess. Time to Code!

I recorded a ~20 min screencast where I walk through some of these seven key concepts behind Angular 2. Hope you enjoy it!


Congrats, you’ve come to the end.

By now, you probably realize there’s lots of new stuff for you to learn. But the nice thing is that maybe it isn’t even only Angular 2 related. Like switching to ES2015 (ES6) and/or TypeScript, or adopting the reactive programming style with RxJS, or learning new toolings like Webpack and SystemJS. These are all things you can totally reuse, even though you don't plan to continue with Angular 2 in the end. Fortunately, the things you have to exclusively learn for Angular 2 got a lot smaller compared to Angular 1.x!

So this was basically just the beginning. From here, you can go more in depth. Follow the links I provided to get started. Also, feel free to drop me a line on Twitter. In general, try to connect with the Angular 2 community (over Twitter, GitHub, and Slack). There are lots and lots of awesome people willing to help you with their enormous expertise. :smiley:

Thanks to Martin Hochel for reviewing this article :+1:

If you enjoyed this post you might want to follow me on Twitter for more news around JavaScript and Angular 2. :smiley:

Note: This article has been reposted here on DZone with my permission. Please refer to the original article for future updates and more links.

angular 2.0, ionic, nativescript

Published at DZone with permission of Juri Strumpflohner . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}