Although the content of this book can be properly digested without any prior AngularJS or Angular experience, you will get most of the book if you are familiar with the basics of AngularJS and you are willing to switch to Angular.

On the internet, often AngularJS and Angular 1 are used interchangeably to refer to the AngularJS framework. This misconception leaves AngularJS experts confused about the Angular versioning. Very often, in many community events, I get questions similar to this one:

Here, you can replace X with any number bigger than 2.

The short answer to this question is: no, you don't have to learn a new framework when a new major version is released. In fact, the API deprecations between Angular 2 and Angular 5 can be listed on a few lines.

This confusion was brought mostly by incorrectly referring to AngularJS as Angular 1, which makes developers believe that every new version of Angular will be as different from the old one as Angular is from AngularJS.

Along the remaining sections of this chapter and in Chapter 2, Get Going with Angular, we will explain how Angular differs from AngularJS and why the development of a new framework was required.

Angular is a framework for application development. Its main focus is to provide a solid foundation for the development of the user interface of our applications.

One of the core primitives that the framework provides is its powerful dependency injection mechanism which allows us to easily control the relations between the individual building blocks of our code. Angular's obviously fast change detection provides a way to synchronize the views of our application with the current state of the data model. Being completely transparent to developers, the change detection knows exactly when the model has changed and performs the minimum set of operations in order to reflect the update in the view.

Being able to extend the valid HTML, Angular's templates with custom elements allow us to use a declarative Domain Specific Language (DSL) to express the structure of the user interface of our application and its bindings to the model.

Angular was inspired for all these ideas and many others by its predecessor, AngularJS.

The initial release of AngularJS was on October 20, 2010. The framework nowadays is used in millions of applications around the world. AngularJS got so popular that numerous technologies were inspired by it and even started using it as a foundation.

One such platform for development of mobile applications is Ionic. Over time, the framework was constantly evolving, trying to provide an API as ergonomic and simplistic API as possible while still being powerful and expressive enough to help us develop complex web applications with ease. The API changes between versions were small and usually introduced through a deprecation process. This way, we: as developers: have enough time to go through the transition process and align to the latest changes.

In the meantime, however, the web evolved, and tens of new technologies got created, some of which directly impacted AngularJS itself or gave the framework opportunities for big jumps in terms of performance or ergonomics. Such new APIs were introduced, for example, by the web worker standard, or even new languages such as TypeScript.

This way, although AngularJS was the optimal technology for application development in 2010, it struggled to stay competitive and flawless, given the constantly moving web. This was the birth of the idea for a new framework, inspired by AngularJS, but with more powerful APIs and better performance! Because of the conceptual similarities with AngularJS, Google called this new framework Angular.

The team at Google, willing to take advantage of the most advanced technologies in Angular, decided to start with a solid, statically typed foundation in the face of TypeScript. On top of that, they considered variety of different ways for the improvement of Angular's performance in order to help developers deliver lightning fast experience to the users of our applications.

Given the learned lesson from AngularJS about the constantly evolving browser APIs, the Angular team developed the framework with a small core and a lot of different libraries surrounding it, providing extra features. This way, the framework's foundational APIs will be able to stay as immutable as possible and the entire infrastructure surrounding Angular's core will evolve following the well-defined release process of semantic versioning. You can see some of the modules developed around Angular core in the following figure:

We'll describe some of these modules in the upcoming chapters.

Before going any further, let's have an overview of what semantic versioning actually means.

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 Specification (also known as SemVer).

SemVer defines the version of a 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 impacting the public API surface 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, changing 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, predictable 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 6 months. This means that by the end of 2018, there will be Angular 7. However, this doesn't mean that every 6 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.

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!

In this chapter, we made an introduction of what Angular is. We explained that Angular and AngularJS are entirely different frameworks.

After that, we went through the basics of the structure of the framework: having a core with a minimalistic, immutable API and building on top of it with different modules in order to provide the best development experience possible.

Finally, we explained how Angular follows semantic versioning, which helps us understand why and when we should expect incompatible API changes in Angular.

In the next chapter, we'll focus on why AngularJS couldn't keep up with the constant evolution of the web, how Angular took advantage of the new, powerful browser API, and how it makes the development of large scale applications easier.