Switching to Angular 2

3.9 (25 reviews total)
By Minko Gechev
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Getting Started with Angular 2

About this book

AngularJS is a JavaScript framework that makes building web applications easier. It is used today in large-scale, high-traffic websites that struggle with under-performance, portability issues, as well as SEO unfriendliness, and complexity at scale.

Angular 2 changes that.

It is the modern framework you need to build performant and robust web applications. “Switching to Angular 2” is the quickest way to get to grips with Angular 2 and will help you transition in to the brave new world of Angular 2.

We’ll start with an overview which sets the changes of the framework in context with version 1.x. After that, you will be taken on a TypeScript crash-course so we can take advantage of Angular 2 in its native, statically-typed environment. We’ll look at the new change-detection method in detail, how Directives and Components change how you create websites with Angular, the new Angular 2 router, and much more.

By the end of the book, you’ll be ready to start building quick and efficient Angular 2 applications that take advantage of all the new features on offer.

Publication date:
March 2016


Chapter 1. Getting Started with Angular 2

On September 18, 2014, the first public commit was pushed to the Angular 2 repository. A few weeks later, at ng-europe, Igor and Tobias from the core team gave a short overview of what Angular 2 was expected to be. The vision at that time was far from final; however, one thing was certain—the new version of the framework would be entirely different from AngularJS 1.x.

This announcement brought a lot of questions and controversy. The reasons behind the drastic changes were quite clear—AngularJS 1.x was no longer able to take full advantage of the evolved Web and to completely satisfy the requirements of large-scale JavaScript applications. A new framework would let Angular developers capitalize on developments in web technology in simpler and more direct ways. Yet, people were concerned. One of the biggest nightmares with backward incompatibility for developers is the migration of their current codebases to the new version of the third-party software they use. In Angular's case, after that first announcement, migration looked daunting, even impossible. Later, at ng-conf 2015 and ng-vegas, different migration strategies were introduced. The Angular community came together and shared additional ideas, anticipating the benefits of Angular 2 while preserving the things learned from AngularJS 1.x.

This book is a part of that project. Making the upgrade to Angular 2 is non-trivial, but it is worth it. The main drivers behind the drastic changes in Angular 2 and its lack of backward compatibility are the evolution of the Web, and the lessons learned from the usage of AngularJS 1.x in the wild. Switching to Angular 2 will help you to learn the new framework by understanding how we got here and why Angular's new features make intuitive sense for the modern Web in building high-performance, scalable, single-page applications.


The evolution of the Web – time for a new framework

In the last couple of years, the Web has evolved in big steps. During the implementation of ECMAScript 5, the ECMAScript 6 standard started its development (now known as ECMAScript 2015 or ES2015). ES2015 introduced many changes in the language such as adding built-in language support for modules, block scope variable definition, and a lot of syntactical sugar, such as classes and destructuring.

Meanwhile, Web Components were invented. Web Components allow us to define custom HTML elements and attach behavior to them. Since it is hard to extend the existing HTML elements with new ones (such as dialogs, charts, grids, and more) mostly because of the time required for consolidation and standardization of their APIs, a better solution is to allow developers to extend the existing elements the way they want. Web Components provide us with a number of benefits, including better encapsulation, better semantics of the markup we produce, better modularity, and easier communication between developers and designers.

We know that JavaScript is a single-threaded language. Initially, it was developed for simple client-side scripting, but over time, its role has shifted quite a bit. Now with HTML5, we have different APIs that allow audio and video processing, communication with external services through a two-directional communication channel, transferring and processing big chunks of raw data, and more. All these heavy computations in the main thread may create a poor user experience. They may introduce freezing of the user interface when time-consuming computations are being performed. This led to the development of WebWorkers, which allow the execution of the scripts in the background that communicate with the main thread through message passing. This way, multi-threaded programming has been brought to the browser.

Some of these APIs were introduced after the development of AngularJS 1.x had begun; that's why the framework wasn't build with most of them in mind. However, exploiting the APIs gives developers many benefits, such as:

  • Significant performance improvements.

  • Development of software with better quality characteristics.

Now let's briefly discuss how each of these technologies has been made part of the new Angular core and why.


The evolution of ECMAScript

Nowadays, browser vendors are releasing new features in short iterations, and users receive updates quite often. This helps move the Web forward by allowing developers to take advantage of the bleeding-edge technologies, aiming to improve the Web. ES2015 is already standardized. The implementation of the latest version of the language has already started in the major browsers. Learning the new syntax and taking advantage of it will not only increase our productivity as developers, but also prepare us for the near future when all the browsers will have full support for it. This makes it essential to start using the latest syntax now.

Some projects' requirements may enforce us to support older browsers, which does not support any ES2015 features. In this case, we can directly write ECMAScript 5, which has different syntax but equivalent semantics to ES2015. However, we can take advantage of the process of transpilation. Using a transpiler in our build process allows us to take advantage of the new syntax by writing ES2015 and translating it to a target language that is supported by the browsers.

AngularJS has been around since 2009. Back then, the frontend of most websites was powered by ECMAScript 3, the last main release of ECMAScript prior to ECMAScript 5. This automatically meant that the language used for the framework's implementation was ECMAScript 3. Taking advantage of the new version of the language requires porting of the entirety of AngularJS 1.x to ES2015.

From the beginning, Angular 2 took into account the current state of the Web by bringing the latest syntax in the framework. Although Angular 2 is written with a superset of ES2016 (TypeScript, which we're going to take a look at in a moment), it allows developers to use language of their own preference. We can use ES2015 or, if we prefer not to have any intermediate preprocessing of our code and simplify the build process, even ECMAScript 5.

Web Components

The first public draft of Web Components was published on May 22, 2012, about three years after the release of AngularJS 1.x. As mentioned, the Web Components standard allows us to create custom elements and attach behavior to them. It sounds familiar; we've already used similar concept in the development of the user interface in AngularJS 1.x applications. Web Components sound like an alternative to Angular directives; however, they have more intuitive API, richer functionality, and built-in browser support. They introduced a few other benefits such as better encapsulation, which is very important, for example, in handling CSS-style collisions.

A possible strategy for adding Web Components support in AngularJS 1.x is to change the directives implementation and introduce primitives of the new standard in the DOM compiler. As Angular developers, we know how powerful but also complex the directives API is. It includes a lot of properties such as postLink, preLink, compile, restrict, scope, controller, and many more, and of course, our favorite transclude. Approved as standard, Web Components will be implemented on a much lower level in the browsers, which introduces plenty of benefits such as better performance and native API.

During the implementation of Web Components, a lot of web specialists met the same problems the Angular team did when developing the directives API and came up with similar ideas. Good design decisions behind Web Components include the content element, which deals with the infamous transclusion problem in AngularJS 1.x. Since both the directives API and Web Components solve similar problems in different ways, keeping the directives API on top of Web Components would have been redundant and added unnecessary complexity. That's why the Angular core team decided to start from the beginning by building on top of Web Components and taking full advantage of the new standard. Web Components involves new features, some of them not yet implemented by all browsers. In case our application is run in a browser, which does not support any of these features natively, Angular 2 emulates them. An example for this is the content element polyfilled with the directive, ng-content.


JavaScript is known for its event loop. Usually JavaScript programs are executed in a single thread and different events are scheduled by being pushed in a queue and processed sequentially, in the order of their arrival. However, this computational strategy is not effective when one of the scheduled events requires a lot of computational time. In such cases the event's handling is going to block the main thread and all other events are not going to be handled until the time consuming computation is complete and passes the execution to the next one in the queue. A simple example of this is a mouse click that triggers an event, in which callback we do some audio processing using the HTML5 audio API. If the processed audio track is big and the algorithm running over it is heavy, this will affect the user's experience by freezing the UI until the execution is complete.

The WebWorker API was introduced in order to prevent such pitfalls. It allows execution of heavy computations inside the context of different thread, which leaves the main thread of execution free, capable of handling user input and rendering the user interface.

How can we take advantage of this in Angular? In order to answer this question, let's think about how things work in AngularJS 1.x. What if we have an enterprise application, which processes a huge amount of data that needs to be rendered on the screen using data binding? For each binding, a new watcher will be added. Once the digest loop is run, it will loop over all the watchers, execute the expressions associated with them, and compare the returned results with the results gained from the previous iteration. We have a few slowdowns here:

  • The iteration over large number of watchers.

  • Evaluation of expression in given context.

  • Copy of the returned result.

  • Comparison between the current result of the expression's evaluation and the previous one.

All these steps could be quite slow depending on the size of the input. If the digest loop involves heavy computations, why not move it to a WebWorker? Why not run the digest loop inside WebWorker, get the changed bindings, and apply them to the DOM?

There were experiments by the community, which aimed for this result. However, their integration into the framework wasn't trivial. One of the main reasons behind the lack of satisfying results was the coupling of the framework with the DOM. Often, inside the watchers' callbacks, Angular directly manipulates the DOM, which makes it impossible to move the watchers inside WebWorkers since the WebWorkers are invoked in an isolated context, without access to the DOM. In AngularJS 1.x, we may have implicit or explicit dependencies between the different watchers, which require multiple iterations of the digest loop in order to get stable results. Combining the last two points, it is quite hard to achieve practical results in calculating the changes in threads other than the main thread of execution.

Fixing this in AngularJS 1.x introduces a great deal of complexity in the internal implementation. The framework simply was not built with this in mind. Since WebWorkers were introduced before the Angular 2 design process started, the core team took them in mind from the beginning.


Lessons learned from AngularJS 1.x in the wild

Although the previous section introduced a lot of arguments for the required reimplementation of the framework responding to the latest trends, it's important to remember that we're not starting completely from scratch. We're taking what we've learned from AngularJS 1.x with us. In the period since 2009, the Web is not the only thing that evolved. We also started building more and more complex applications. Today, single-page applications are not something exotic, but more like a strict requirement for all the web applications solving business problems, which are aiming for high performance and good user experience.

AngularJS 1.x helped us to build highly-efficient and large-scale single-page applications. However, by applying it in various use cases, we've also discovered some of its pitfalls. Learning from the community's experience, Angular's core team worked on new ideas aiming to answer the new requirements. As we look at the new features of Angular 2, let's consider them in the light of the current implementation of AngularJS 1.x and think about the things with which we, as Angular developers, have struggled and which we have modified over the last few years.


AngularJS 1.x follows the Model View Controller (MVC) micro-architectural pattern. Some may argue that it looks more like Model View ViewModel (MVVM) because of the view model attached as properties to the scope or the current context in case of controller as syntax. It could be approached differently again if we use the Model View Presenter pattern (MVP). Because of all the different variations of how we can structure the logic in our applications the core team called AngularJS 1.x a Model View Whatever (MVW) framework.

The view in any AngularJS application is supposed to be a composition of directives. The directives collaborate together in order to deliver fully functional user interfaces. Services are responsible for encapsulating the business logic of the applications. That's the place where we should put the communication with RESTful services through HTTP, real-time communication with WebSockets and even WebRTC. Services are the building block where we should implement the domain models and business rules of our applications. There's one more component, which is mostly responsible for handling user input and delegating the execution to the services—the controller.

Although the services and directives have well-defined roles, we can often see the anti-pattern of the Massive View Controller, which is common in iOS applications. Occasionally, developers are tempted to access or even manipulate the DOM directly from their controllers. Initially, this happens for achieving something simple, such as changing the size of an element, or quick and dirty changing elements' styles. Another noticeable anti-pattern is duplication of business logic across controllers. Often developers tend to copy and paste logic, which should be encapsulated inside services.

The best practices for building AngularJS applications state is that the controllers should not manipulate the DOM at all, instead all DOM access and manipulations should be isolated in directives. If we have some repetitive logic between controllers, most likely we want to encapsulate it into a service and inject this service with the dependency injection mechanism of AngularJS in all the controllers that need that functionality.

This is where we're coming from in AngularJS 1.x. All this said, it seems that the functionality of controllers could be moved into the directive's controllers. Since directives support the dependency injection API, after receiving the user's input, we can directly delegate the execution to a specific service, already injected. This is the main reason Angular 2 uses a different approach by removing the ability to put controllers everywhere by using the ng-controller directive. We'll take a look at how AngularJS 1.x controllers' responsibilities could be taken from Angular 2 components and directives in Chapter 4, Getting Started with Angular 2 Components and Directives.


The data-binding in AngularJS is achieved using the scope object. We can attach properties to it and explicitly declare in the template that we want to bind to these properties (one or two-way). Although the idea of the scope seems clear, the scope has two more responsibilities, including event dispatching and the change detection-related behavior. Angular beginners have a hard time understanding what scope really is and how it should be used. AngularJS 1.2 introduced something called controller as syntax. It allows us to add properties to the current context inside the given controller (this), instead of explicitly injecting the scope object and later adding properties to it. This simplified syntax can be demonstrated from the following snippet:

<div ng-controller="MainCtrl as main">
  <button ng-click="main.clicked()">Click</button>

function MainCtrl() {
  this.name = 'Foobar';
MainCtrl.prototype.clicked = function () {
  alert('You clicked me!');

Angular 2 took this even further by removing the scope object. All the expressions are evaluated in the context of given UI component. Removing the entire scope API introduces higher simplicity; we don't need to explicitly inject it anymore and we add properties to the UI components to which we can later bind. This API feels much simpler and more natural.

We're going to take more detailed look at the components and the change detection mechanism of Angular 2 in Chapter 4, Getting Started with Angular 2 Components and Directives.

Dependency Injection

Maybe the first framework on the market that included inversion of control (IoC) through dependency injection (DI) in the JavaScript world was AngularJS 1.x. DI provides a number of benefits, such as easier testability, better code organization and modularization, and simplicity. Although the DI in 1.x does an amazing job, Angular 2 takes this even further. Since Angular 2 is on top of the latest web standards, it uses the ECMAScript 2016 decorators' syntax for annotating the code for using DI. Decorators are quite similar to the decorators in Python or annotations in Java. They allow us to decorate the behavior of a given object by using reflection. Since decorators are not yet standardized and supported by major browsers, their usage requires an intermediate transpilation step; however, if you don't want to take it, you can directly write a little bit more verbose code with ECMAScript 5 syntax and achieve the same semantics.

The new DI is much more flexible and feature-rich. It also fixes some of the pitfalls of AngularJS 1.x such as the different APIs; in 1.x, some objects are injected by position (such as the scope, element, attributes, and controller in the directives' link function) and others, by name (using parameters names in controllers, directives, services, and filters).

We will take a further look at the Angular 2's dependency injection API in Chapter 5, Dependency Injection in Angular 2.

Server-side rendering

The bigger the requirements of the Web are, the more complex the web applications become. Building a real-life, single-page application requires writing a huge amount of JavaScript, and including all the required external libraries may increase the size of the scripts on our page to a few megabytes. The initialization of the application may take up to several seconds or even tens of seconds on mobile until all the resources get fetched from the server, the JavaScript is parsed and executed, the page gets rendered, and all the styles are applied. On low-end mobile devices that use a mobile Internet connection, this process may make the users give up on visiting our application. Although there are a few practices that speed up this process, in complex applications, there's no silver bullet.

In the process of trying to improve the user experience, developers discovered something called server-side rendering. It allows us to render the requested view of a single-page application on the server and directly provide the HTML for the page to the user. Later, once all the resources are processed, the event listeners and bindings can be added by the script files. This sounds like a good way to boost the performance of our application. One of the pioneers in this was ReactJS, which allowed pre-rendering of the user interface on the server side using Node.js DOM implementations. Unfortunately, the architecture of AngularJS 1.x does not allow this. The showstopper is the strong coupling between the framework and the browser APIs, the same issue we had in running the change detection in WebWorkers.

Another typical use case for the server-side rendering is for building Search Engine Optimization (SEO)-friendly applications. There were a couple of hacks used in the past for making the AngularJS 1.x applications indexable by the search engines. One such practice, for instance, is traversal of the application with a headless browser, which executes the scripts on each page and caches the rendered output into HTML files, making it accessible by the search engines.

Although this workaround for building SEO-friendly applications works, server-side rendering solves both of the mentioned issues, improving the user experience and allowing us to build SEO-friendly applications much more easily and far more elegantly.

The decoupling of Angular 2 with the DOM allows us to run our Angular 2 applications outside the context of the browser. The community took advantage of this by building a tool, allowing us to prerender the views of our single-page application on the server side and forward them to the browser. At the time of writing the following content, the tool is still in the early phases of its development and is outside the framework's core. We're going to take a further look at it in Chapter 8, Development Experience and Server-Side Rendering.

Applications that scale

MVW has been the default choice for building single-page applications since Backbone.js appeared. It allows separation of concerns by isolating the business logic from the view, allowing us to build well-designed applications. Exploiting the observer pattern, MVW allows listening for model changes in the view and updating it when changes are detected. However, there are some explicit and implicit dependencies between these event handlers, which make the dataflow in our applications not obvious and hard to reason about. In AngularJS 1.x, we are allowed to have dependencies between the different watchers, which requires the digest loop to iterate over all of them a couple of times until the expressions' results get stable. Angular 2 makes the data-flow one-directional, which has a number of benefits, including:

  • More explicit data-flow.

  • No dependencies between bindings, so no time to live (TTL) of the digest.

  • Better performance:

    • The digest loop is run only once.

    • We can create apps, which are friendly to immutable/observable models, that allows us to make further optimizations.

The change in the data-flow introduces one more fundamental change in AngularJS 1.x architecture.

We may take another perspective on this problem when we need to maintain a large codebase written in JavaScript. Although JavaScript's duck typing makes the language quite flexible, it also makes its analysis and support by IDEs and text editors harder. Refactoring of large projects gets very hard and error-prone because in most cases, the static analysis and type inference are impossible. The lack of compiler makes typos all too easy, which are hard to notice until we run our test suite or run the application.

The Angular core team decided to use TypeScript because of the better tooling possible with it and the compile-time type checking, which help us be more productive and less error-prone. As the preceding figure shows, TypeScript is a superset of ECMAScript; it introduces explicit type annotations and a compiler. The TypeScript language is compiled to plain JavaScript, supported by today's browsers. Since version 1.6, TypeScript implements the ECMAScript 2016 decorators, which makes it the perfect choice for Angular 2.

The usage of TypeScript allows much better IDE and text editors support with static code analysis and type checking. All this increases our productivity dramatically by reducing the mistakes we make and simplifying the refactoring process. Another important benefit of TypeScript is the performance improvement we implicitly get by the static typing, which allows run-time optimizations by the JavaScript virtual machine.

We'll be talking about TypeScript in detail in Chapter 3, TypeScript Crash Course.


Templates are one of the key features in AngularJS 1.x. They are simple HTML and do not require any intermediate processing and compilation, unlike most template engines such as mustache. Templates in AngularJS combine simplicity with power by allowing us to extend HTML by creating an internal Domain Specific Language (DSL) inside it, with custom elements and attributes.

However, this is one of the main purposes behind web components as well. We already mentioned how and why Angular 2 takes advantage of this new technology. Although AngularJS 1.x templates are great, they can still get better! Angular 2 templates took the best parts of the ones in the previous release of the framework and enhanced them by fixing some of their confusing parts.

For example, let's say we built a directive and we want to allow the user to pass a property to it by using an attribute. In AngularJS 1.x, we can approach this in three different ways:

<user name="literal"></user>
<user name="expression"></user>
<user name="{{interpolate}}"></user>

If we have a directive user and we want to pass the name property, we can approach in three different ways. We can either pass a literal (in this case, the string "literal"), a string, which will be evaluated as an expression (in our case "expression"), or an expression inside {{ }}. Which syntax should be used completely depends on the directive's implementation, which makes its API-tangled and hard to remember.

It is a frustrating task to deal with large amount of components with different design decisions on a daily basis. By introducing a common convention, we can deal with such problems. However, in order to have good results and consistent APIs, the entire community needs to agree with it.

Angular 2 deals with this problem as well by providing special syntax for attributes, whose values need to be evaluated in the context of the current component, and a different syntax for passing literals.

Another thing we're used to, based on our AngularJS 1.x experience, is the microsyntax used in template directives such as ng-if, ng-for. For instance, if we want to iterate over a list of users and display their names in AngularJS 1.x, we can use:

<div ng-for="user in users">{{user.name}}</div>

Although this syntax looks intuitive to us, it allows limited tooling support. However, Angular 2 approached this differently by bringing a little bit more explicit syntax with richer semantics:

<template ngFor let-user [ngForOf]="users">

The preceding snippet explicitly defines the property, which has to be created in the context of the current iteration (user), the one we iterate over (users).

However, this syntax is too verbose for typing. Developers can use the following syntax, which later gets translated to the more verbose one:

<li *ngFor="let user of users">

The improvements in the new templates will also allow better tooling for advanced support by text editors and IDEs. We're going to discuss Angular 2's templates in Chapter 4, Getting Started with Angular 2 Components and Directives.

Change detection

In the WebWorkers section, we already mentioned the opportunity to run the digest loop in the context of a different thread, instantiated as WebWorker. However, the implementation of the digest loop in AngularJS 1.x is not quite memory-efficient and prevents the JavaScript virtual machine from doing further code optimizations, which allows significant performance improvements. One such optimization is the inline caching (http://mrale.ph/blog/2012/06/03/explaining-js-vms-in-js-inline-caches.html). The Angular team did a lot of research discovering different ways the performance and the efficiency of the digest loop could be improved. This led to the development of a brand new change detection mechanism.

In order to allow further flexibility, the Angular team abstracted the change detection and decoupled its implementation from the framework's core. This allowed the development of different change detection strategies, empowering different features in different environments.

As a result, Angular 2 has two built-in change detection mechanisms:

  • Dynamic change detection: This is similar to the change detection mechanism used by AngularJS 1.x. It is used in systems with disallowed eval(), such as CSP and Chrome extensions.

  • JIT change detection: This generates the code that performs the change detection run-time, allowing the JavaScript virtual machine to perform further code optimizations.

We're going to take a look at the new change detection mechanisms and how we can configure them in Chapter 4, Getting Started with Angular 2 Components and Directives.



In this chapter, we considered the main reasons behind the decisions taken by the Angular core team and the lack of backward compatibility between the last two major versions of the framework. We saw that these decisions were fueled by two things—the evolution of the Web and the evolution of the frontend development, with the lessons learned from the development of AngularJS 1.x applications.

In the first section, we learned why we need to use the latest version of the JavaScript language, why we want to take advantage of Web Components and WebWorkers, and why it's not worth it to integrate all these powerful tools in version 1.x.

We observed the current direction of frontend development and the lessons learned in the last few years. We described why the controller and scope were removed from Angular 2, and why AngularJS 1.x's architecture was changed in order to allow server-side rendering for SEO-friendly, high-performance, single-page applications. Another fundamental topic we took a look at was building large-scale applications, and how that motivated single-way data-flow in the framework and the choice of the statically-typed language TypeScript.

In the next chapter, we're going to look at the main building blocks of an Angular 2 application—how they can be used and how they relate to each other. Angular 2 reuses some of the naming of the components introduced by AngularJS 1.x, but generally changes the building blocks of our single-page applications completely. We're going to peek at the new components, and compare them with the ones in the previous version of the framework. We'll make a quick introduction to directives, components, routers, pipes, and services, and describe how they could be combined for building classy, single-page applications.


Downloading the example code

You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

You can download the code files by following these steps:

  • Log in or register to our website using your e-mail address and password.

  • Hover the mouse pointer on the SUPPORT tab at the top.

  • Click on Code Downloads & Errata.

  • Enter the name of the book in the Search box.

  • Select the book for which you're looking to download the code files.

  • Choose from the drop-down menu where you purchased this book from.

  • Click on Code Download.

Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:

  • WinRAR / 7-Zip for Windows

  • Zipeg / iZip / UnRarX for Mac

  • 7-Zip / PeaZip for Linux

About the Author

  • Minko Gechev

    Minko Gechev is a Google Developer Expert for the Angular team and a presenter at over 40 worldwide conferences, including ng-conf, AngularConnect, AngularUP, and many others. Minko is co-author of the official Angular style guide, and has developed codelyzer – a tool for static analysis of Angular applications and best practices, which is part of the Angular CLI, and currently has over a million downloads each month.

    Minko is a former member of the Angular Mobile Team where his role involved him with tools for facilitating the process of developing Progressive web applications with Angular easier. Other projects by the author include the AngularJS style guide, which is translated to 13 different languages, aspect.js, Angular Seed, and many others.

    Minko Gechev is co-founder and CTO at Rhyme and strongly believes in open source software.

    Browse publications by this author

Latest Reviews

(25 reviews total)
use unix, use node.js version 6.3.1 as last stable release
ho dato una rapida lettura, ma ancora non ho avuto modo di leggerlo completamente come sempre però rilevo un'ottima qualità generale del contenuto.
En cours d'étude dessus depuis JS, c'est un avantage du e-book lorsque l'on est obligé de synthétiser.
Book Title
Access this book, plus 7,500 other titles for FREE
Access now