[{"id":"ch01","contentType":"text","title":"Get Going with Angular","content":"

Chapter 1. Get Going with Angular

On September 18, 2014, Google pushed the first public commit to the repository that now contains the new versions of Angular. A few weeks later, at ng-europe, Igor and Tobias, from the core team, gave a short overview of what the new version of the framework 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.

This announcement brought a lot of questions and controversies. The reasons behind the drastic changes were quite clear: AngularJS was no longer able to take full advantage of the evolved Web and the requirements of large-scale JavaScript applications needed to be completely satisfied. A new framework would let Angular developers capitalize on developments in web technology in simpler, more performant, and productive 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 2015, different migration strategies were introduced. The Angular community came together and shared additional ideas, anticipating the benefits of the new version of the framework, while preserving the things learned from AngularJS.

This book is a part of that project. Making the upgrade to the new versions of Angular is now smooth and 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 in the wild. Getting Started with Angular will help you learn the new framework by making you understand 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. Some of the topics that we will discuss in this chapter are as follows:

How to use TypeScript and how it extends JavaScript.
Building the user interface of Angular applications with a component-based architecture.
Using Angular's dependency injection mechanism and delegating the business logic to services.
We are going to explore in-depth Angular's router and forms module.
We'll take a look at the Ahead-of-Time compilation for building lightning fast applications.

Angular adopted semantic versioning, so before going any further let's have an overview of what this actually means.

","url":"https://subscription.packtpub.com/book/web-development/9781787125278/1","metaDescription":"","titleSlug":"get-going-with-angular"},{"id":"ch01lvl1sec7","contentType":"text","title":"Angular and semver","content":"

Angular and semver

AngularJS was rewritten from scratch and replaced with its successor, Angular 2. A lot of us were bothered by this big step, which didn't allow us to have a smooth transition between these two versions of the framework. Right after Angular 2 was stable, Google announced that they wanted to follow the so called semantic versioning (also known as semver).

Semver defines the version of given software project as the triple X.Y.Z, where Z is called patch version, Y is called minor version, and X is called major version. A change in the patch version means that there are no intended breaking changes between two versions of the same project, but only bug fixes. The minor version of a project will be incremented when new functionality is introduced, and there are no breaking changes. Finally, the major version will be increased when incompatible changes are introduced in the API.

This means that between versions 2.3.1 and 2.10.4, there are no introduced breaking changes but only a few added features and bug fixes. However, if we have version 2.10.4 and we want to change any of the already existing public APIs in a backward-incompatible manner (for instance, change the order of the parameters that a method accepts), we need to increment the major version, and reset the patch and minor versions, so we will get version 3.0.0.

The Angular team also follows a strict schedule. According to it, a new patch version needs to be introduced every week; there should be three monthly minor releases after each major release, and finally, one major release every six months. This means that by the end of 2018, we will have at least Angular 6. However, this doesn't mean that every six months we'll have to go through the same migration path like we did between AngularJS and Angular 2. Not every major release will introduce breaking changes that are going to impact our projects. For instance, support for a newer version of TypeScript or change of the last optional argument of a method will be considered as a breaking change. We can think of these breaking changes in a way similar to what happened between AngularJS 1.2 and AngularJS 1.3.

Note

Since the content that you're going to read in this book will be mostly relevant across different Angular versions, we'll refer to Angular 2 as either Angular 2 or only Angular. If we explicitly mention Angular 2, this doesn't mean that the given paragraph will not be valid for Angular 4 or Angular 5; it most likely will. In case you're interested to know what the changes are between different versions of the framework, you can take a look at the changelog at https://github.com/angular/angular/blob/master/CHANGELOG.md. If we're discussing AngularJS (that is, version 1.x of the framework), we will be more explicit by mentioning a version number, or using AngularJS instead of Angular.

Now that we've introduced Angular's semantic versioning and conventions for referring to the different versions of the framework, we can officially start our journey!

","url":"https://subscription.packtpub.com/book/web-development/9781787125278/1/ch01lvl1sec7/angular-and-semver","metaDescription":"","titleSlug":"angular-and-semver"},{"id":"ch01lvl1sec8","contentType":"text","title":"The evolution of the Web - time for a new framework","content":"

The evolution of the Web - time for a new framework

In the past 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 JavaScript, 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 set of 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 in 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 Web Workers, which allow the execution of the scripts in the background that communicate with the main thread through message passing. This way, multithreaded programming was brought to the browser.

Some of these APIs were introduced after the development of AngularJS had begun; that's why the framework wasn't built with most of them in mind. Taking advantage of the APIs gives developers many benefits, such as the following:

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.

","url":"https://subscription.packtpub.com/book/web-development/9781787125278/1/ch01lvl1sec8/the-evolution-of-the-web-time-for-a-new-framework","metaDescription":"","titleSlug":"the-evolution-of-the-web-time-for-a-new-framework"},{"id":"ch01lvl1sec9","contentType":"text","title":"The evolution of ECMAScript","content":"

The evolution of ECMAScript

Nowadays, browser vendors are releasing new features in short iterations, and users receive updates quite often. This helps developers take advantage of bleeding-edge Web technologies. 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 will also prepare us for the near future when all 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 do not support any ES2015 features. In this case, we can directly write ECMAScript 5, which has different syntax but equivalent semantics to ES2015. On the other hand, a better approach will be to 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.

Angular has been around since 2009. Back then, the frontend of most websites was powered by ECMAScript 3, the last main release of ECMAScript before 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 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 new Angular is written with a superset of ES2016 (TypeScript, which we're going to take a look at in Chapter 3, TypeScript Crash Course), it allows developers to use a 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, we can even use ECMAScript 5. Note that if we use JavaScript for our Angular applications we cannot use Ahead-of-Time (AoT) compilation. You can find more about AoT compilation in Chapter 8, Tooling and Development Experience.

Web Components

The first public draft of Web Components was published on May 22, 2012, about three years after the release of AngularJS. As mentioned, the Web Components standard allows us to create custom elements and attach behavior to them. It sounds familiar; we've already used a similar concept in the development of the user interface in AngularJS applications. Web Components sound like an alternative to Angular directives; however, they have a more intuitive API 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 is to change the directives implementation and introduce primitives of the new standard in the DOM compiler. As Angular developers, we know how powerful and complex the directives API is. It includes a lot of properties, such as postLink, preLink, compile, restrict, scope, controller, and much 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 with 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. 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 a framework compatible with Web Components and taking full advantage of the new standard. Web Components involve new features; some of them were 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 emulates them. An example for this is the content element polyfilled with the ng-content directive.

Web Workers

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 will block the main thread, and all other events will not be handled until the time-consuming computation is complete and the execution passed 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 Web Workers API was introduced in order to prevent such pitfalls. It allows execution of heavy computations inside the context of a 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. 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, the framework will create a new watcher. 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 a large number of watchers.
The evaluation of the expression in a given context.
The copy of the returned result.
The 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 Web Worker? Why not run the digest loop inside Web Worker, get the changed bindings, and then 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, AngularJS directly manipulates the DOM, which makes it impossible to move the watchers inside a Web Worker since the Web Workers are executed in an isolated context, without access to the DOM. In AngularJS, 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 introduces a great deal of complexity into the internal implementation. The framework simply was not built with this in mind. Since Web Workers were introduced before the Angular 2 design process started, the core team took them into consideration from the beginning.

","url":"https://subscription.packtpub.com/book/web-development/9781787125278/1/ch01lvl1sec9/the-evolution-of-ecmascript","metaDescription":"","titleSlug":"the-evolution-of-ecmascript"},{"id":"ch01lvl1sec10","contentType":"text","title":"Lessons learned from AngularJS in the wild","content":"

Lessons learned from AngularJS in the wild

Although the previous section listed a lot of arguments for the required re-implementation 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 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 web applications solving business problems, which are aiming for high performance and a good user experience.

AngularJS helped us to efficiently build 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.

Controllers

AngularJS 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 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 blocks 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 while you want to achieve something simple, such as changing the size of an element, or quick and dirty changing elements' styles. Another noticeable anti-pattern is the duplication of the 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 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 Angular in all the controllers that need that functionality.

This is where we're coming from in AngularJS. 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 why Angular now 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 controllers' responsibilities could be taken from the new components and directives in Chapter 4, Getting Started with Angular Components and Directives.

Scope

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, it 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 through the following snippet:

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

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

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

We will take a more detailed look at the components and the change detection mechanism of Angular in Chapter 4, Getting Started with Angular 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. DI provides a number of benefits, such as easier testability, better code organization and modularization, and simplicity. Although the DI in the first version of the framework does an amazing job, Angular 2 took this even further. Since the latest Angular 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, or add metadata to it, 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, such as the different APIs; in the first version of the framework, 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's dependency injection API in Chapter 5, Dependency Injection in Angular.

Server-side rendering

The bigger the requirements of the Web are, the more complex 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 React, which allowed prerendering of the user interface on the server side using Node.js DOM implementations. Unfortunately, the architecture of AngularJS 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 Web Workers.

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 applications indexable by the search engines. One such practice, for instance, is the 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 above-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 with the DOM allows us to run our Angular applications outside the context of the browser. We will take a further look at it in Chapter 8, Tooling and Development Experience.

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. Taking advantage of 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 data flow in our applications not obvious and hard to reason about. In AngularJS, 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. The new Angular makes the data flow one-directional; this has a number of benefits:

More explicit data flow.
No dependencies between bindings, so no time to live (TTL) of the digest.
Better performance of the framework:
- The digest loop is run only once.
- We can create apps, which are friendly to immutable or observable models, that allow us to make further optimizations.

The change in the data flow introduces one more fundamental change in AngularJS 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 to be more productive and less error-prone. As the following diagram shows, TypeScript is a superset of ECMAScript; it introduces explicit type annotations and a compiler:

Figure 1

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.

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 runtime optimizations by the JavaScript virtual machine.

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

Templates

Templates are one of the key features in AngularJS. They are simple HTML and do not require any intermediate translation, unlike most template engines, such as mustache. Templates in Angular 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.

This is one of the main purposes of Web Components as well. We already mentioned how and why Angular takes advantage of this new technology. Although AngularJS templates are great, they can still get better! The new Angular 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 have a directive and we want to allow the user to pass a property to it using an attribute. In AngularJS, we can approach this in the following three different ways:

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

In the user directive, we pass the name property using three different approaches. 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 a large amount of components with different design decisions on a daily basis. By introducing a common convention, we can handle such problems. However, in order to have good results and consistent APIs, the entire community needs to agree with it.

The new Angular deals with this problem 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 experience, is the microsyntax in template directives, such as ng-if and ng-for. For instance, if we want to iterate over a list of users and display their names in AngularJS, 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"> 
  {{user.name}} 
</template>

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

Since 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"> 
  {{user.name}} 
</li>

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

Change detection

In the Web Workers section, we already mentioned the opportunity to run the digest loop in the context of a different thread, instantiated as Web Worker. However, the implementation of the digest loop in AngularJS is not quite as memory-efficient and prevents the JavaScript virtual machine from doing further code optimizations, which allows for 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 in order to discover different ways the performance and efficiency of the change detection could be improved. This led to the development of a brand new change detection mechanism.

As a result, Angular performs change detection in code that the framework directly generates from the components' templates. The code is generated by the Angular compiler. There are two built-in code generation (also known as compilation) strategies:

Just-in-Time (JiT) compilation: At runtime, Angular generates code that performs change detection on the entire application. The generated code is optimized for the JavaScript virtual machine, which provides a great performance boost.
Ahead-of-Time (AoT) compilation: Similar to JiT, with the difference that the code is being generated as part of the application's build process. It can be used for speeding the rendering up by not performing the compilation in the browser and also in environments that disallow eval(), such as CSP (Content-Security-Policy) and Chrome extensions. We will discuss it further in the next sections of the book.

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

","url":"https://subscription.packtpub.com/book/web-development/9781787125278/1/ch01lvl1sec10/lessons-learned-from-angularjs-in-the-wild","metaDescription":"","titleSlug":"lessons-learned-from-angularjs-in-the-wild"},{"id":"ch01lvl1sec11","contentType":"text","title":"Summary","content":"

Summary

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 applications.

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

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'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 will take a look at the main building blocks of an Angular application, how they can be used and how they relate to each other. The new Angular reuses some of the naming of the concepts introduced by AngularJS, but generally changes the building blocks of our single-page applications completely. We will take a peek at the new concepts and compare them with the ones in the previous version of the framework. We'll make a quick introduction to modules, directives, components, routers, pipes, and services, and describe how they could be combined for building classy, single-page applications.

Tip

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.

","url":"https://subscription.packtpub.com/book/web-development/9781787125278/1/ch01lvl1sec11/summary","metaDescription":"","titleSlug":"summary"}]

Getting Started with Angular - Second edition - Second Edition

By : Minko Gechev

Getting Started with Angular - Second edition - Second Edition

By: Minko Gechev

Overview of this book

Related Content you might be interested in

Current Title:

Getting Started with Angular - Second edition - Second Edition

Essential Angular 4

Learning Angular 4 for .NET Developers

Expert Angular

Chapter 5. Dependency Injection in Angular