Angular 2+ - A Getting Started Guide for Beginners
A gentle introduction to a local Meetup group
23 min read
23 min read
Wohooo! This article earned some fame and was chosen at rank #1 out of ~1500 Angular 2 articles published in May-June 2016. Read the whole story 😊
This article is for those of you that are new to Angular 2 or even to web development in general. Here, I’m going to give you a good overview what Angular 2 is all about, highlighting some of the main concepts behind. The idea is to give you a good starting point from where to go and do further research.
TL;DR - Check out the video screencast at the end of this article 😉
If you did already some coding examples in Angular 2, then I’m probably going to bore you 😃. But maybe you want to dive deeper with my Learning Angular components video course I recently published 😉.
Here’s a simple classification of today’s web application architectures.
In server-side rendered applications, most of the application’s logic resides on the server, and remains there. The user basically enters the URL, the request gets send 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 gets again 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 and what many pages still use today.
Modern web pages often require to work more like applications do on the desktop, though. People demand for 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 web site again, but rather the data for that specific user interaction is send to the server (usually by using the JSON format) and the server in turn responds with the just the amount of 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 very 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: well, because the browser doesn’t get the HTML code to show, but rather a bunch of JavaScript files that need to be interpreted, and executed, and which in turn then generates the final HTML to be shown to the user.
Just some names that are currently being used for 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, what it does is the following. 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 then to be intelligent enough to resume where the server has left off.
The advantage is obvious: you get fast startup times, but still the benefit of a SPA as mentioned before.
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’s 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, build 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 btw. can be used completely independently from Angular and is currently under discussion at stage 0 at TC39 for being included into 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 (an 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.
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 hardly working on a so-called “template compiler” or “offline compiler” the so-called Ahead-of-time (AoT) compilation. 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 it’s components are made in a way that Angular 2 is able “to reason about your app’s templates” and thus to generate an AST and consequently to translate all of your templates into pure JavaScript code at compile time. This is huge IMHO :+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 any more 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 with the template/offline compiler, lots of stuff can already be dropped when deploying in production. Furthermore, the goal is to use a bundler that supports tree shaking and thus reduce 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.@John_Papa @arhoads76 @DanWahlin I believe current numbers are something like 49K via Rollup and 25K via jscompiler.
— Brad Green (@bradlygreen) May 31, 2016
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 has been created by Microsoft already in 2010 and then went first public in 2012. It really kicked off only recently, though, with Angular 2. The main difference to other transpilers is that it adds optional type support to JavaScript. First of all, this allows to discover and prevent nasty errors at compile time and second it opens up numerous possibilities for better tooling support.
Ok ok wait wait, so 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 above 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 is the new paradigm for frontend development. This is not something particular to Angular but is something that’s shared among other libraries like React, Ember or Polymer as well. The idea is to build autonomous pieces with clearly defined responsibilities and which 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. Like..
<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 most probably 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 may also want to check out Polymer and webcomponents.org
Angular 2 fully embraces this component based development style. In fact, already 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:
@Component({
selector: 'hello-world',
template: `<p>Hello, world!</p>`
})
class HelloWorldComponent {
}
In the corresponding HTML you would write this to instantiate it.
<hello-world></hello-world>
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 1st class citizens in Angular 2"
Now with components being a 1st 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 always again come across it. 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 performing 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.
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.
@Component({
...
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:
{% raw %}
@Component({
selector: 'hello-world',
template: `
<p>Hello, {{ who }}</p>
`
})
class HelloWorldComponent {
who: string = 'Juri'
}
{% endraw %}
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.
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” s.t. it can be shared and consumed by multiple components. A service is nothing else than a simple ES6 class:
@Injectable()
export class PersonService {
fetchAllPeople() { ... }
}
From within some component we can then use this service
import { PersonService } from './services/person.service';
@Component({
...
providers: [ PersonService ]
})
class PersonComponent {
people;
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 two things
@Injectable annotationPersonService 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
Angular 2 heavily uses a paradigm called “Reactive Programming”, in particular this is implemented through the RxJS 5 library. Like the Angular 2 http service won’t return promises, but instead RxJS Observables.
This pattern is not new at all, and gained a lot of popularity recently 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.
Here are some good articles to get started 😃
We will also briefly touch it in the screencast at the end of the article.
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 by far no more enough. What you need is some transpiler and a build tool that transpiles the code and serves it up, not to mention then optimizations like minification, inclusion of HTML templates, CSS compilation etc..
Some build tools/module bundlers you should definitely take a closer look at is 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 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 has still 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 to learn 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.
Other popular starters you definitely also want to take a look at are these. They are community based, have lots of best practices bundled and have been around for quite a while now.
Are you ready? Great, so let’s create our first Angular 2 application, step by step :+1:.
Congrats, you’ve come to the end 😉. So 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 learn new toolings like Webpack and SystemJS…these are all things you can totally reuse, even though you dont’ 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 start 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, Slack,…), there are lots and lots of awesome people willing to help you with their enourmous expertise. 😃
_Thanks to Martin Hochel for reviewing this article :+1:_
