Before we start talking about what Node is and why it's useful, you need to first install Node on your machine, because in the next couple of sections, we'll want to run a little bit of Node code.

Now, to get started, we just need two programs—a browser, I'll be using Chrome throughout the book, but any browser will do, and Terminal. I'll use Spotlight to open up Terminal, which is what it's known as on my operating system.

If you're on Windows, look for the Command Prompt, you can search using the Windows key and then by typing command prompt, and on Linux, you're looking for the command line, although depending on your distribution it might be called Terminal or Command Prompt.

Now, once you have that program open, you'll see a screen, as shown in the following screenshot:

Essentially, it's waiting for you to run a command. We'll run quite a few commands from Terminal throughout the book. I'll discuss it in a few sections later, so if you've never used this before, you can start navigating comfortably.

In the browser, we can head over to nodejs.org to grab the installer for the latest version of Node(as shown here). In this book, we'll use the most recent version, version 9.3.0:

ES6 is the next version of JavaScript and it comes with a lot of great enhancements we'll be using throughout the book. If you look at the following image, Node.js Long Term Support Release Schedule (https://github.com/nodejs/LTS), you can see that the current Node version is V8, out in April 2017:

Before going further, I would like to talk about the Node release cycle. What I have in the preceding image is the official release cycle, this is released by Node. You'll notice that only next to the even Node numbers do you find the active LTS, the blue bar, and the maintenance bar. Now, LTS stands for long-term support, and this is the version that's recommended for most users. I'd recommend that you stick with the currently offered LTS option (Node v 8.9.4 LTS), though anything on the left-hand side will do, this is shown as the two green buttons on nodejs.org.

Now, as you can see, the major version numbers, bump every six months. Regardless of any sort of big overarching change, this happens like clockwork even if nothing drastic has changed. It's not like Angular where jumping from 1.0 to 2.0 was almost like using a completely different library. This is just not the case with Node, what you're getting from this book is the latest and greatest Node has to offer.

Once the version is confirmed and selected, all we have to do is to click the required version button on the Node website (nodejs.org) and download the installer. The installer is one of those basic click Next a few times and you're done type of installers, there's no need to run any fancy commands. I'll start the installer. As shown in the following screenshot, it'll just ask a few questions, then let's click on Next or Continue through all of them:

You might want to specify a custom destination, but if you don't know what that means, and you don't usually do it when installing programs, skip that step too. Here, in the next screenshot, you can see that I'm using just 58.6 MB, no problem.

I'll run the installer by entering my password. And once I enter my password, it should really only take a couple of seconds to get Node installed:

As shown in the following screenshot, we have a message that says The installation was completed successfully, which means we are good to go:

Now that Node has been installed successfully, we can go ahead and verify that by running Node from Terminal. Inside Terminal, I'll shut it down by going to Quit Terminal and open it up again:

In our case, we restarted things and we can run our brand new command so, we'll type it:

node -v

What we're doing in this command is we're running the Node command, and we're passing in what's called a flag, a hyphen sign followed by a letter. It could be a, it could be j, or in our case it's v. This command will print the version of Node currently installed.

We might get an error like this:

If you try to run a command that doesn't exist, such as nodeasdf, you'll see command not found. If you see this, it usually means the Node installer didn't work correctly, or you haven't run it in the first place.

In our case though, running Node with the v flag should result in a number. In our case, it's version 9.3.0. If you do have Node installed, and you see something like the following screenshot, then you are done. In the next section, we'll start exploring exactly what Node is.

Node came about when the original developers took JavaScript, something you could usually only run inside the browser, and they let it run on your machine as a standalone process. This means that we could create applications using JavaScript outside the context of the browser.

Now, JavaScript previously had a limited feature set. When I used it in the browser, I could do things such as update the URL and remove the Node logo, adding click events or anything else, but I couldn't really do much more.

With Node, we now have a feature set that looks much more similar to other languages, such as Java, Python, or PHP. Some of these are as follows:

• We can write Node applications using the JavaScript syntax
• You can manipulate your filesystem, creating and removing folders
• You can create query databases directly
• You can even create web servers using Node

These were things that were not possible in the past, and they are because of Node.

Now, both Node and the JavaScript that gets executed inside of your browser, they're both running on the exact same engine. It's called the V8 JavaScript runtime engine. It's an open source engine that takes JavaScript code and compiles it into much faster machine code. And that's a big part of what makes Node.js so fast.

Machine code is low-level code that your computer can run directly without needing to interpret it. Your machine only knows how to run certain types of code, for example, your machine can't run JavaScript code or PHP code directly without first converting it into low-level code.

Using this V8 engine, we can take our JavaScript code, compile it to much quicker machine code, and execute that. This is where all those new features come in. The V8 engine is written in a language called C++. So if you want to extend the Node language, you don't write Node code, you write C++ code that builds off of what V8 already has in place.

Speaking of JavaScript code, let's start writing some inside Terminal. Now, throughout the book, we'll be creating files and executing those files, but we can actually create a brand new Node process by running the node command.

Referring to the following screenshot, I have a little right caret, which is waiting for JavaScript Node code, not a new command-prompt command:

This means that I can run something like console.log, which, as you probably already know, logs a message to the screen. log is a function, so I'll call it as such, opening and closing my parentheses, and passing in a string inside two single quotes, a message Hello world!, as shown in the following command line:

console.log('Hello world!');

This will print Hello world to the screen. If I hit enter, Hello world! prints just like you'd expect, as shown in the following code output:

Now, what actually happened behind the scenes? Well, this is what Node does. It takes your JavaScript code, it compiles it into machine code, and executes it. In the preceding code, you can see it executed our code, printing out Hello world!. Now, the V8 engine is running behind the scenes when we execute this command, and it's also running inside the Chrome browser.

If I open up the developer tools in Chrome by going to Settings | More Tools | Developer Tools:

I can ignore most of the things. I'm just looking for the Console tab, as shown in the following screenshot:

The preceding screenshot showing the console is a place where we can run some JavaScript code. I can type the exact same command, console.log('Hello world!'); and run it:

As you can see in the preceding screenshot, Hello world! prints to the screen, which is the exact same result we got when we ran it up earlier using Terminal. In both cases, we're running it through the V8 engine, and in both cases the output is the same.

Now, we already know that the two are different. Node has features such as filesystem manipulation, and the browser has features such as manipulating what's shown inside the window. Let's take a quick moment to explore their differences.

Inside the browser, you've probably used window if you've done any JavaScript development:

Window is the global object, it stores basically everything you have access to. In the following screenshot, you can see things such as array, we have all sorts of CSS manipulation and Google Analytics keywords; essentially every variable you create lives inside Window:

We have something similar inside Node called global, as shown here:

It's not called window because there is no browser window in Node, thus it is called global. The global object stores a lot of the same things as window. In the following screenshot, you can see methods that might be familiar, such as setTimeout and setInterval:

If we look at this code screenshot, we have most of the things that are defined inside the window, with some exceptions, as shown in the following screenshot:

Now, inside the Chrome browser, I also have access to document:

The document object stores a reference to the Document Object Model (DOM) in the Node website. The document object shows exactly what I have inside the browser's viewport, as shown in the following screenshot:

I can make changes to the document to update what gets shown up on the browser's viewport. Now, obviously we don't have this HTML document inside Node, but we do have something similar, which is called process. You can view it by running process from Node, and in the following screenshot, we have a lot of information about the specific Node process that's being executed:

There's also methods available here to shut down the current Node process. What I'd like you to do is run the process.exit command, passing in as an argument the number zero, to say that things exited without error:

process.exit(0);

When I run this command, you can see I'm now back at the command prompt, as shown in the following screenshot:

I've left Node, and I'm at a place where I can run any regular command prompt command, such as checking my Node version. I can always get back into Node by running node, and I can leave it without using the process.exit command by using control + C twice.

Now, I'm back at my regular command prompt. So, these are the notable differences, obviously inside the browser you have the viewable area, window gets changed to global, and a document basically becomes process. Now, obviously that's a generalization, but those are some of the big picture changes. We'll be exploring all the minutiae throughout the book.

Now, when someone asks you what is Node? You can say Node's a JavaScript runtime that uses the V8 engine. When they ask you what the V8 engine is, you can say the V8 engine is an open source JavaScript engine written in C++ that takes JavaScript code and compiles it to machine code. It's used inside Node.js and it's used in the Chrome browser.

In this section, we'll cover the why behind Node.js. Why is it so good at creating backend apps? And why is it becoming so popular with companies such as Netflix, Uber and Walmart, who are all using Node.js in production?

As you might have noticed since you're taking this course, when people want to learn a new backend language, more and more they're turning to Node as the language they want to learn. The Node skillset is in hot demand, for both frontend developers who need to use Node day to day to do things such as compile their applications, to engineers who are creating applications and utilities using Node.js. All of this has made Node the backend language of choice.

Now, if we look at the homepage of Node, we have three sentences, as shown in the following screenshot:

In the previous section, we addressed the first sentence. We took a look at what Node.js is. There's only three sentences in the image, so in this section, we'll take a look at the second two sentences. We'll read them now, then we'll break it down, learning exactly why Node is so great.

The first sentence, Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient; we'll explore all of this now. The second sentence we'll explore at the end of the section—Node.js' packaged ecosystem, npm, is the largest ecosystem of open source libraries in the world. Now, these two sentences have a ton of information packed into them.

We'll go over a few code examples, we'll dive into some charts and graphs, and we'll explore what makes Node different and what makes it so great.

Node is an event-driven, non-blocking language. Now, what is I/O? I/O is something that your application does all of the time. When you're reading or writing to a database, that is I/O, which is short form for input/output.

This is the communication from your Node application to other things inside of the Internet of Things. This could be a database read and write request, you may be changing some files on your filesystem, or you may be making an HTTP request to a separate web server, such as a Google API for fetching a map for the user's current location. All of these use I/O, and I/O takes time.

Now, the non-blocking I/O is great. That means while one user is requesting a URL from Google, other users can be requesting a database file read and write access, they can be requesting all sorts of things without preventing anyone else from getting some work done.

Let's go ahead and take a look at the differences between blocking and non blocking software development:

In the preceding screenshot, I have two files that we'll be executing. But before going to that, first let's explore how each of these files operates, the steps that are required in order to finish the program.

This will help us understand the big differences between blocking, which I have on the left side of the image, which is not what Node uses, and non-blocking is on the right side, which is exactly how all of our Node applications in the book are going to operate.

You don't have to understand the individual details, such as what require is, in order to understand what's going on in this code example. We'll be breaking things down in a very general sense. The first line on each code is responsible for fetching a function that gets called. This function will be our simulated I/O function that is going to a database, fetching some user data and printing it to the screen.

Refer to the preceding code image. After we load in the function, both files try to fetch a user with an ID of 123. When it gets that user, it prints it to the screen with the user1 string first, and then it goes on and it fetches the user with 321 as the ID. And it prints that to the screen. And finally both files add up 1 + 2, storing the result, which is 3, in the sum variable and print it to the screen.

Now, while they all do the same thing, they do it in very different ways. Let's break down the individual steps. In the following code image, we'll go over what Node executes and how long it takes:

You can consider the seconds shown in the preceding screenshot; it doesn't really matter, it's just to show the relative operating speed between the two files.

The blocking example can be illustrated as follows:

The first thing that happens inside our blocking example, as shown in the preceding screenshot, is that we fetch the user on line 3 in the code:

var user1 = getUserSync('123');

Now, this request requires us to go to a database, which is an I/O operation to fetch that user by ID. This takes a little bit of time. In our case, we'll say it takes three seconds.

Next, on line 4 in the code, we print the user to the screen, which is not an I/O operation and it runs right away, printing user1 to the screen, as shown in the following code:

console.log('user1', user1); 

As you can see in the following screenshot, it takes almost no time at all:

Next up, we wait on the fetching of user2:

var user2 = getUserSync('321');

When user2 comes back, as you might expect, we print it to the screen, which is exactly what happens on line 7:

console.log('user2', user2);

Finally, we add up our numbers and we print it to the screen:

var sum = 1 + 2; 
console.log('The sum is ' + sum); 

None of this is I/O, so right here we have our sum printing to the screen in barely any time.

This is how blocking works. It's called blocking because while we're fetching from the database, which is an I/O operation, our application cannot do anything else. This means our machine sits around idle waiting for the database to respond, and can't even do something simple like adding two numbers and printing them to the screen. It's just not possible in a blocking system.

In our non-blocking example, this is how we'll be building our Node applications.

Let's break this code example down line by line. First up, things start much the same way as we discussed in the blocking example. We'll start the getUser function for user1, which is exactly what we did earlier:

But we're not waiting, we're simply kicking off that event. This is all part of the event loop inside Node.js, which is something we'll be exploring in detail.

Notice it takes a little bit of time; we're just starting the request, we're not waiting for that data. The next thing we do might surprise you. We're not printing user1 to the screen because we're still waiting for that request to come back, instead we start the process of fetching our user2 with the ID of 321:

In this part of the code, we're kicking off another event, which takes just a little bit of time to do-it is not an I/O operation. Now, behind the scenes, the fetching of the database is I/O, but starting the event, calling this function is not, so it happens really quickly.

Next up, we print the sum. The sum doesn't care about either of the two user objects. They're basically unrelated, so there's no need to wait for the users to come back before I print that sum variable, as shown in the following screenshot:

What happens after we print the sum? Well, we have the dotted box, as shown in the following screenshot:

This box signifies the simulated time it takes for our event to get responded to. Now, this box is the exact same width as the box in the first part of the blocking example (waiting on user1), as shown here:

Using non-blocking doesn't make our I/O operations any faster, but what it does do is it lets us run more than one operation at the same time.

In the non-blocking example, we start two I/O operations before the half second mark, and in between three and a half seconds, both come back, as shown in the following screenshot:

Now, the result here is that the entire application finishes much quicker. If you compare the time taken in executing both the files, the non-blocking version finishes in just over three seconds, while the blocking version takes just over six seconds. A difference of 50%. This 50% comes from the fact that in blocking, we have two requests each taking three seconds, and in non-blocking, we have two requests each taking three seconds, but they run at the same time.

Using the non-blocking model, we can still do stuff like printing the sum without having to wait for our database to respond. Now, this is the big difference between the two; blocking, everything happens in order, and in non-blocking we start events, attaching callbacks, and these callbacks get fired later. We're still printing out user1 and user2, we're just doing it when the data comes back, because the data doesn't come back right away.

Inside Node.js, the event loop attaches a listener for the event to finish, in this case for that database to respond back. When it does, it calls the callback you pass in the non-blocking case, and then we print it to the screen.

In a blocking context, we could handle two requests on two separate threads, but that doesn't really scale well, because for each request we have to beef up the amount of CPU and RAM resources that we're using for the application, and this sucks because those threads, are still sitting idle. Just because we can spin up other threads doesn't mean we should, we're wasting resources that are doing nothing.

In the non-blocking case, instead of wasting resources by creating multiple threads, we're doing everything on one thread. When a request comes in, the I/O is non-blocking so we're not taking up any more resources than we would be if it never happened at all.

Let's run these examples in real time and see what we get. And we have the two files (blocking and non-blocking files) that we saw in the previous section.

We'll run both of these files, and I'm using the Atom editor to edit my text files. These are things we'll be setting up later in the section, this is just for your viewing purpose, you don't need to run these files.

Now, the blocking and non-blocking files, will both get run and they'll do similar things to those we did in the previous section, just in a different way. Both use I/O operations, getUserSync and getUser, that take five seconds apiece. The time is no different, it's just the order they execute in that makes the non-blocking version much quicker.

Now, to simulate and show how things work, I'll add a few console.log statements as shown in the following code example, console.log('starting user1'), console.log('starting user2').

This will let us visualize how things work inside Terminal. By running node blocking.js, this is how we run files. We type node and we specify the filename, as shown in the following code:

 node blocking.js 

When I run the file, we get some output. starting user1 prints to the screen and then it sits there:

Now, we have the user1 object printing to the screen with the name Andrew, and starting user2 prints to the screen, as shown in the following code output:

After that, the user2 object comes back around five seconds later with the name of Jen.

As shown in the preceding screenshot, our two users have printed to the screen, and at the very end our sum, which is 3, prints to the screen; everything works great.

Notice that starting user1 was immediately followed by the finishing of user1, and starting user2 was immediately followed by the finishing of user2 because this is a blocking application.

Now, we'll run the non-blocking file, which I've called non-blocking.js. When I run this file, starting user1 prints, starting user2 prints, then the sum prints all back to back:

Around 5 seconds later, at basically the same time, user1 and user2 both print to the screen.

This is how non-blocking works. Just because we started an I/O operation doesn't mean we can't do other things, such as starting another one and printing some data to the screen, in this case just a number. This is the big difference, and this is what makes non-blocking apps so fantastic. They can do so many things at the exact same time without having to worry about the confusion of multi-threading applications.

Let's move back into the browser and take a look at those sentences again in the Node website:

Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, and we saw that in action.

Because Node is non-blocking, we were able to cut down the time our application took by half. This non-blocking I/O makes our apps super quick, this is where the lightweight and efficient comes into play.

Now, let's go to the last sentence on the Node website, as shown in the following screenshot:

Node.js' package ecosystem, npm, is the largest ecosystem of open-source libraries in the world. This is what really makes Node fantastic. This is the cherry on top-the community, the people every day developing new libraries that solve common problems in your Node.js applications.

Things such as validating objects, creating servers, and serving up content live using sockets. There's libraries already built for all of those so you don't have to worry about this. This means that you can focus on the specific things related to your application without having to create all this infrastructure before you can even write real code, code that does something specific to your apps use case.

Now, npm, which is available on npmjs.org, is the site we'll be turning to for a lot of third-party modules:

If you're trying to solve a problem in Node that sounds generic, chances are that someone's already solved it. For example, if I want to validate some objects, let's say I want to validate that a name property exists and that there's an ID with a length of three. I could go into Google or go into npm; I usually choose Google, and I could Google search npm validate object.

When I google that, I'll just look for results from npmjs.com, and you can find the first three or so are from that:

I can click the first one, and this will let me explore the documentation and see if it's right for me:

This one looks great, so I can add it to my app without any effort.

Now, we'll go through this process. Don't worry, I'm not going to leave you high and dry on how to add third-party modules. We'll be using a ton of them in the book because this is what real Node developers do. They take advantage of the fantastic community of developers, and that's the last thing that makes Node so great.

This is why Node has come to the position of power that it currently sits at, because it's non-blocking, meaning it's great for I/O applications, and it has a fantastic community of developers. So, if you ever want to get anything done, there's a chance someone already wrote the code to do it.

This is not to say you should never use Rails or Python or any other blocking language again, that is not what I'm getting at. What I'm really trying to show you is the power of Node.js and how you can make your applications even better. Languages like Python have things such as the library Twisted, which aims to add non-blocking features to Python. Though the big problem is all of the third-party libraries, as they are still written in a blocking fashion, so you're really limited as to which libraries you can use.

Since Node was built non-blocking from the ground up, every single library on npmjs.com is non-blocking. So you don't have to worry about finding one that's non blocking versus blocking; you can install a module knowing it was built from the ground up using a non blocking ideology.

In the next couple of sections, you'll be writing your very first app and running it from Terminal.

In this section, I want to give you a tour of the various text editors you can use for this book. If you already have one you love using, you can keep using the one you have. There's no need to switch editors to get anything done in this book.

Now, if you don't have one and you're looking for a few options, I always recommend using Atom, which you can find at atom.io. It's free, open source, and it's available on all operating systems, Linux, macOS, and Windows. It's created by the folks behind GitHub and it's the editor that I'll be using inside of this book. There's an awesome community of theme and plug-in developers so you really can customize it to your liking.

Now, aside from Atom there are a few other options. I've heard a lot of people talking about Visual Studio Code. It is also open source, free, and available on all operating systems. If you don't like Atom, I highly recommend you check this out, because I've heard so many good things by word of mouth.

Next up, we always have Sublime Text, which you can find at sublimetext.com. Now, Sublime Text is not free and it's not open source, but it's a text editor that a lot of folks do enjoy using. I prefer Atom because it's very similar to Sublime Text, though I find it snappier and easier to use, plus it's free and open source.

Now, if you are looking for a more premium editor with all of the bells and whistles in IDE as opposed to a text editor, I always recommend JetBrains. None of their products are free, though they do come with a 30-day free trial, but they really are the best tools of the trade. If you find yourself in a corporate setting or you're at a job where the company is willing to pay for an editor, I always recommend that you go with JetBrains. All of their editors come with all of the tools you'd expect, such as version control integration, debugging tools, and deploying tools built in.

So, take a moment, download the one you want to use, play around with it, make sure it fits your needs, and if not, try another one.

In this section, you will be creating and running your very first Node app. Well, it will be a simple one. It'll demonstrate the entire process, from creating files to running them from Terminal.

The first step will be to create a folder. Every project we create will go live inside of its own folder. I'll open up the Finder on macOS and navigate to my desktop. What I'd like you to do is open up the desktop on your OS, whether you're on Linux, Windows, or macOS, and create a brand new folder called hello-world.

Now I'll use command + O (Ctrl + O for Windows users) to open up, and I'll navigate to the desktop and double-click my hello-world folder, as shown here:

On the left I have my files, which are none. So, let's create a new one. I'll make a new file in the root of the project, and we'll call this one app.js, as shown here:

This will be the only file we have inside our Node application, and in this file we can write some code that will get executed when we start the app.

In the future, we'll be doing crazy stuff like initializing databases and starting web servers, but for now we'll simply use console.log, which means we're accessing the log property on the console object. It's a function, so we can call it with parentheses, and we'll pass in one argument as string, Hello world!. I'll toss a semicolon on the end and save the file, as shown in the following code:

console.log('Hello world!');

This will be the first app we run.

Now that we have our app.js file, the only thing left to do is to run it, and we'll do that over in Terminal. Now, to run this program, we have to navigate into our project folder. If you're not familiar with Terminal, I'll give you a quick refresher.

You can always figure out where you are using pwd on Linux or macOS, or the dir command on Windows. When you run it, you'll see something similar to the following screenshot:

I'm in the Users folder, and then I'm in my user folder, and my user name happens to be Gary.

We can use cd to navigate into the desktop, and here we are:

Now we're sitting in the desktop. The other command you can run from anywhere on your computer is cd /users/Gary/desktop. And this will navigate to your desktop, no matter what folder you're located in. The command cd desktop, requires you to be in the user directory to work correctly.

Now we can start by cd-ing into our project directory, which we called hello-world, as shown in the following command:

cd hello-world

With the following screenshot:

Once we're in this directory, we can run at the ls command on Linux or Mac (which is the dir command on Windows) to see all of our files, and in this case we just have one, we have app.js:

This is the file we'll run.

Now, before you do anything else, make sure you are in the hello-world folder and you should have the app.js file inside. If you do, all we'll do is run the node command followed by a space so we can pass in an argument, and that argument will be the filename, app.js as shown here:

node app.js

Once you have this in place, hit enter and there we go, Hello world! prints to the screen, as shown here:

And that is all it takes to create and run a very basic Node application. While our app doesn't do anything cool, we'll be using this process of creating folders/files and running them from Terminal throughout the book, so it's a great start on our way to making real-world Node apps.

In this chapter, we touched base with the concept of Node.js. We took a look at what Node is and we learned that it's built on top of the V8 JavaScript engine. Then we explored why Node has become so popular, its advantages and its disadvantages. We took a look at the different text editors we can choose from and, at the end, you created your very first Node application.

In the next chapter, we'll dive in and create our first app. I am really excited to start writing real-world applications.