Author: mattchapman

mattchapmanhttp://

Investigating download size in Angular 4

During the development of Angular 2, I was concerned about the size of the new framework compared with AngularJS. It’s also harder to tell now that the setup is more complicated. Back with AngularJS v1.5 for example, you can look at the size of angular.min.js at around 160KB, which shrinks to around 57KB with server compression. Although in a typical application you would probably be adding other libraries like angular-animate and angular-translate, at least the starting size is very small, plus you can easily look at the size of the additional libraries too.

When I first started playing with Angular 2, I did an ‘ng serve’, and the Angular-CLI tool collected everything together (using webpack) and it displayed nicely in my browser. But then I looked in the browser console and was rather shocked to see 2.5MB – 16 times bigger! Your web app would take around 15 seconds to load that over a 3G connection, some users would give up before then! Of course, it’s not as bad as all that, it’s due to the runtime engine used by Angular during development. When Angular 4 was released it was described as ‘smaller and faster’, so I thought I’d take a closer look.

I created a basic test app in Angular 4, and with ‘ng serve’ it was still about 2.5MB. I then did ‘ng build –prod’ and looked in the generated ‘dist’ folder – the files were down to around 400KB, looking promising. I then put them in a server with compression, and it’s only 97KB, sweet! That same 3G connection (measured using Chrome’s network throttling test mode) loads everything in under 700ms, instead of 15 seconds!

So still larger than AngularJS v1.5, but perfectly acceptable in my opinion, unless you are targeting users on really slow networks. Also it looks like further optimisations are possible using Ahead-of-time(AOT) compilation – something to investigate later!

 

Advertisement

Why I like Angular: ng-repeat / ngFor

Continuing the theme from my previous post about two-way data binding, I’m going to cover another simple yet powerful feature of Angular: creating repeating elements.

I’m going to cover both the Angular 1 syntax and the Angular 2+ syntax as the concept is the same across both.

A lot of Angular’s power comes from making HTML more expressive, and the repeat/for loop is a very good example of that. A common use case for web apps is obtaining a list of items from the server, and then rendering them on the page. With Angular we can write the HTML for displaying a single item, and then just add an ng-repeat expression to repeat that HTML element for each item in the list.

Let’s start with a very simple bit of HTML that displays two list items:

<ul>
  <li>Apple</li>
  <li>Orange</li>
</ul>

Now let’s convert it to use Angular 1’s ng-repeat directive:

<ul>
  <li ng-repeat="fruit in ['Apple','Orange']">{{ fruit }}</li>
</ul>

This looks the same as before when rendered. The <li> element is duplicated for every item in the given list, and the fruit variable takes the value of each item in the list in turn.

The Angular 2+ syntax uses *ngFor instead, like this:

<ul>
  <li *ngFor="let fruit of ['Apple','Orange']">{{ fruit }}</li>
</ul>

This is a basic, somewhat contrived example to show the syntax. A more realistic example would obtain the list from the server, and then create an Angular component for each one. For example, if the component is called myComponent, and the list is available on the controller as ctrl.items, the HTML might look something like this:

Angular 1:
<myComponent ng-repeat="item in ctrl.items" item="item"></myComponent>
Angular 2+:
<myComponent *ngFor="let item of ctrl.items" item="item"></myComponent>

 

There are a number of additional options available for more complicated cases, such as iterating over the properties of an object, or the ability to access the index of each element in the list using the $index special property (or the exported index property in Angular 2+). But even in the simple case, it is still a powerful tool that reduces the amount of code you need to write.

 

Why I like Angular: Two-way data binding

This blog post is a gentle introduction to the AngularJS framework, Angular for short. I’m only going to cover one feature – there are other reasons why I like it but I’ll save those for a future post! I’ll also point out that I’m a strong believer in using the right tools for the job – although I am a big fan of Angular, there are situations where other tools, like React, might be more suitable.

I’m going to cover Angular 1 syntax, as that is what I’m most familiar with, but the same concept exists in Angular 2 and I’ll include the new syntax at the end.

Now let’s get straight down to business with some HTML:

 <input type="text" ng-model="model"></input>
 <p>You entered: {{model}}</p>

Angular keeps the HTML separate from the JavaScript, but does enhance the HTML with extra features. The first of which is the ng-model attribute to the input element. This is an Angular directive that binds the input field to a property. In this case we are binding the value of the text field to a property called model. This means that whenever the value of the text field changes, the value of the property changes too.

We can see this by using another feature: Angular expressions. These are inserted into the HTML using {{ and }} characters. So the string “{{model}}” is replaced by the results of evaluating the Angular expression “model“, which in this case is simply the value of that property. So with the above HTML, we can type into the text field and the characters are immediately shown in the paragraph below:

twowaybinding

That shows the binding working in one direction, from the value of the input field to the property. It also works in the other direction – let’s try that out by adding a button to our example:

<button ng-click="model='Testing'">Press me</button>

Here we have another Angular directive, ng-click which runs the given expression when the button is pressed:

twowaybinding2

As shown, pressing the button sets the model property, and because the input field is bound to that property with two-way data binding, it notices the change and updates the value of the input field.

This simple concept is very powerful, and saves you writing a lot of code. Imagine you’re writing an application that has a form with multiple fields, and then a submit button – a very common scenario in web apps! A traditional approach would be to add a click listener to the submit button, then find each input element in the DOM, extract its value, and collect them together into a JavaScript object for sending back to the server. And if you need to initialise the form with values returned from the server, you need additional code to take each value in turn, find the corresponding input element, and set its value accordingly. Instead, with Angular you only need to bind each input element to the appropriate property. Then when that property is set with the initial values, the fields automatically display those values. And when the submit button is pressed, the property automatically contains all the current values from the input elements.

For me this was one of the features that first attracted me to Angular. It certainly saves a lot of time when writing form based applications.

Angular 2 update:

Angular 2 onwards supports the same two-way data binding, but the syntax is now like this:

<input type="text" [(ngModel)]="model">

To help you remember this syntax of round brackets inside square brackets, it has a catchy name of “Banana in a Box”.

This change might look a little strange at first, but it makes it clear that two-way data binding is being used, which is important when building large applications because having a large number of two-way bindings can slow an application down. With Angular 1 it was easy to use two-way bindings even when you only actually needed one-way bindings.