To answer this heading, no, we don't have backward compatibility. If you have some Angular projects implemented with the previous version, depending on the complexity of the project, I wouldn't recommend migrating to the new version. Most likely, you will end up hammering a lot of changes into your migrated Angular project and in the end, you will realize it was more cost effective to just create a new project based on Angular from scratch.

Please keep in mind that the previous versions of Angular and Angular share a name, but they have huge differences in their nature and that is the price we pay for a better performance.

You might be wondering if you need to know AngularJS 1.x before diving into Angular. Absolutely not. To be more specific, it might be even better if you don't have any experience using Angular at all. This is because your mind wouldn't be preoccupied with obsolete rules and syntax. For example, we will see a lot of annotations in Angular that might make you uncomfortable if you come from an Angular 1 background. Also, there are different types of dependency injections and child injectors, which are totally new concepts introduced in Angular. Moreover, there are new features for templating and data binding, which help to improve loading time by asynchronous processing.

The current edition of ECMAScript (ES5) is the one that is widely accepted among all well-known browsers. You can think of it as the traditional JavaScript; whatever code is written in ES5 can be executed directly in the browsers. The problem is that most modern JavaScript frameworks contain features that require more than the traditional JavaScript capabilities. That is the reason ES6 was introduced. With this edition, and any future ECMAScript editions, we will be able to empower JavaScript with the features we need.

Now, the challenge is in running the new code in the current browsers. Most browsers nowadays recognize standard JavaScript codes only. So, we need a mediator to transform ES6 to ES5. That mediator is called a transpiler and the technical term for transformations is transpiling. There are many good transpilers out there and you are free to choose whatever you feel comfortable with.

Google originally planned to use AtScript to implement Angular; later they joined forces with Microsoft and introduced TypeScript as the official transpiler for Angular.

The following figure summarizes the relationship between various editions of ECMAScript, AtScript, and TypeScript.

It is important to get the foundation right before installing anything else. Depending on your operating system, install Node.js and its package manager, npm. You can find a detailed installation manual on the Node.js official website, at https://nodejs.org/en/.

At the time of writing this book, npm comes with Node.js out-of-the-box. However, in case their policy changes in the future, you can always download the npm and follow the installation process from https://npmjs.com.

The next stop would be the IDE; feel free to choose anything that you are comfortable with. Even a simple text editor will do. In this book, I will use WebStorm because of its embedded TypeScript syntax support and Angular features, which speeds up the development process. Moreover, it is lightweight enough to handle the project we are about to develop. You can download it from https://jetbrains.com/webstorm/download.

During the first few chapters, we will use simple objects and arrays as placeholders for the data. However, at some stage, we will need to persist the data in our application. This means we need a database. In this book we are going to use Firebase Realtime Database. It is a free NoSQL cloud database provided by Google which come with whatever we need from a real-time and secure database.

For now, just leave the database subject. You don't need to create any connections or database objects for the first few chapters. We will revisit this later in Chapter 4, The Rating Service - Data Management.

The final requirement to get started would be an Angular seed project to shape the initial structure of our project. If you look at the public source code repositories, you can find several versions of these seeds. I prefer the official one for the following two reasons:

Speaking about packages, you might be wondering what happened to the other JavaScript packages we needed for this application; we didn't install anything other than Node and NPM. The next section will answer this question.

Assuming that you installed WebStorm, fire the IDE and check out a new project from a Git repository.

Now, set the repository URL to https://github.com/angular/angular2-seed.git and save the project in a folder called the sherlock project, as shown:

Click on the Clone button and open the project in WebStorm. Next, click on the packages.json file and observe the dependencies. As you can see, this is a very lean seed with minimal configurations. It contains the Angular release candidate 2, plus the required modules to get the project up and running.

As you see in the following screenshot, apart from main Angular modules, we have the rxjs library, which is the Reactive eXtension for JS and we will use it for transforming, composing, and querying streams of data.

The first thing we need to do is install all the required dependencies defined inside the package.json file. Right-click on the file and select the run npm install option.

Installing the packages for the first time will take a while. In the meantime, explore the devDependencies section of package.json in the editor. As you see, we have all the required bells and whistles to run the project, including TypeScript and web server to start the development:

"devDependencies": { 
    "awesome-typescript-loader": "~0.16.2", 
    "es6-promise": "3.0.2", 
    "es6-shim": "0.35.0", 
    "reflect-metadata": "0.1.2", 
    "source-map-loader": "^0.1.5", 
    "typescript": "~1.8.9", 
    "typings": "~1.0.3", 
    "webpack": "^1.12.9", 
    "webpack-dev-server": "^1.14.0", 
    "webpack-merge": "^0.8.4" 
  }, 

We also have some nifty scripts defined inside package.json that automate useful processes. For example, to start a web server and see the seed in action, we can simply execute the following command in a terminal. (These scripts are shipped with the seed project and they are located inside the package.json file, under the script property. There is nothing special about them, they are just simple npm commands and you are more than welcome to add your commands if you like):

$ npm run server 

Alternatively, we can right-click on the package.json file and select Show npm Scripts. This will open another side tab in WebStorm and show all the available scripts inside the current file:

Double-click on the start script and it will run the web server and load the seed application on port 3000. This means that if you visit http://localhost:3000 , you will see the seed application in your browser, as illustrated:

There is one more thing before we move on to the next topic. If you open any .ts file, WebStorm will ask you if you want it to transpile the code to JavaScript. If you say no once, it will never show up again. 

In the following screenshot, below the tabs we can see the question (Compile TypeScript to JavaScript?) and possible answers (OK, No, Configure):

Choose No because we don't need WebStorm to transpile for us because the start script already contains a transpiler that takes care of all the transformations for us.

Recently, I had an interesting conversation with a couple of colleagues of mine, which is worth sharing here in this chapter. One of them is an avid frontend developer and the other is a seasoned backend developer. You guessed what I'm going to talk about--the debate between backend/frontend developers and who is better. We saw these kind of debates between backend and frontend people in development communities long enough.

However, the interesting thing, which, in my opinion, will show up more often in the next few months (years), is a fading border between the ends (frontend/backend).

It feels like the reason that some traditional frontend developers are holding up their guard against new changes in Angular is not just because the syntax has changed, thus causing a steep learning curve, but mostly because they now have to deal with concepts that have existed natively in backend development for many years. Hence, the reason that backend developers are becoming more open to the changes introduced in Angular is that these changes seem natural to them.

Annotations or child dependency injections, for example, is not a big deal to backenders as much as it bothers the frontenders. I won't be surprised to see a noticeable shift in both the camps in the years to come. Probably, we will see more backenders who are willing to use Angular as a good candidate for some, if not all, of their backend projects and probably we will see more frontenders taking object-oriented concepts and best practices more seriously. Given that JavaScript was originally a functional scripting language, they will probably try to catch up with the other camp as fast as they can.

There is no comparison here and I am not saying which camp has an advantage over the other one. My point is, before modern frontend frameworks, JavaScript was open to be used in a quick and dirty inline script to solve problems quickly.

While this is a very convenient approach, it causes serious problems when you want to scale a web application. Imagine the time and effort you might have to make finding all of those dependent codes and refactoring them to reflect the required changes.

When it comes to scalability, we need a full separation between layers and that requires developers to move away from traditional JavaScript and embrace more OOP best practices in their day-to-day development tasks.

That's what has been practiced in all modern frontend frameworks and Angular takes it to the next level by completely restructuring the model-view-* concept and opening doors to the future features, which will eventually be a native part of any web browser.

During the course of this journey, we will dive into all new Angular concepts by implementing a semi-AI project, called The Sherlock Project.

This project will basically be about collecting facts, evaluating and ranking them, and making a decision about how truthful they are.

To achieve this goal, we will implement a couple of services and inject them to the project wherever they are needed. Each chapter will discuss one aspect of the project and will focus on one related service. At the end, all services will come together to act as one big project.

This chapter covered a brief introduction to Angular. We saw where Angular comes from, what problems it will solve, and how we can benefit from it.

We talked about the project that we will be creating with Angular. We also saw which other tools are needed for our project and how to install and configure them. Finally, we cloned an Angular seed project, installed all its dependencies, and started a web server to examine the application output in a browser.

In the next chapter, we will create all the required wireframes for this project and use them as a base structure for the rest of the book.