Exploring Node.js: Release Cycles, Versions, REPL, and more

Welcome to my Node.js blog series! Today, we'll be exploring some key topics that every Node.js developer should know, including the Release Cycle, deciding which version to use, the REPL mode, running code outside of the REPL, Node.js vs the browser, and the global Object of Node.js. Whether you're a seasoned pro or just getting started, this post is sure to have something for everyone. Let's dive in!

??The Release Cycle in Node.js

The Node team always gives us two main versions or variants of the node runtime that we can download and run from the official node page. As you might know, we have two types of versions -

1. LTS Version (long-term support)
2. Current Version

So why do we need this LTS version? Isn't it always better to have the very latest version of Node with the latest features, bug fixes, and performance increases? Well, the truth is, oftentimes new features introduce new bugs and other changes that can break our existing code.

The stability of long-term support allows developers time to create stable versions of their code when necessary, such as for production software, where an update to NodeJS that breaks your code could cost you or the company where you work significant time and money.

If we go to the About tab on the Node.js site under releases, we can find a chart of the scheduled node releases.

This is the plan of the development cycle for every version of Node going forward into the future. It's updated as new versions of Node are released.

All of the even-numbered versions of Node currently are or will eventually become an LTS version. While odd-numbered versions will only ever be current versions, they'll never have those extra stability guarantees that LTS versions give us.

So what guarantees do LTS versions give us? Well, each LTS version is separated into two phases -

1. Active: When an LTS version is in the active phase, most changes are accepted as long as they don't break existing code.
2. Maintenance: Later, when an LTS version gets promoted to maintenance, only important bug fixes and security updates will make it into updates for that version.

If you're more OK with issues and just want the latest greatest features, the latest current version should be OK for you.

??How to decide which version to use

Just a little tip on how I decide which version to use, if I know I'll be deploying an application to production within a few weeks or months, I'll go with the even-numbered LTS versions. This gives me extra confidence that my code won't break when I update my node runtime, so get the latest security updates and bug fixes.

On the other hand, if I'm writing code that won't be deployed to production for, say, a year by which time I know that there's going to be a new LTS version released, I'll often go with the current latest version of Node so that when I do update to the LTAs version, once it's released, that upgrade will go a little bit smoother. It'll be a little bit easier because there have been fewer changes between the current version and the newly active LTS version. That's about it.

??The REPL mode in NodeJS

So what happens when I run a node program inside of the terminal?

So “Hi” is treated as JavaScript code in this case, as a variable that hasn't been defined yet, which causes Node to give us a ReferenceError when we run "node" and don't type anything after it, Not passing in any arguments.

We're running the node in a mode that's called the REPL. That's our REPL, which stands for Read-Eval-Print-Loop.

Before we dig into that, let's think about what would happen if we typed in some code here,

So what exactly is going on here when we run node and we're in our REPL,

The REPL responds to this input in the following way -

1. Read step: It includes reading in our code that we type with the keyboard but also parsing that code. Parsing means that the V8 JavaScript engine will break down our line of code and understand the role of all the different parts of it. So, for example, it will understand that we have ‘Hi’, ‘ ‘, and ‘there!’ here as a string. We have the plus signs (+) where they're being concatenated. We have an equal sign (=) where the result of this, whatever that is and hasn't been evaluated yet. But the parser will now know that this equal sign means that the left side here is being assigned whatever is on the right side.
2. Eval step: This past code will then be run and evaluated by V8, then it will add these three strings and assign them to the hi constant.
3. Print step: Finally, the results will be printed to the console in our terminal. So in the first line, when we concatenated those strings, we added them together and the result of the expression ‘Hi there!’ was printed. In the next line, when we defined our constant, we got back undefined because when we assign a constant, nothing is returned in JavaScript.
4. Loop step: So first we perform all of these actions in sequence and then we loop back to the start where our REPL environment will be ready to read in the next line of JavaScript. And this will continue until we exit the program in the terminal.

But if we close our REPL and then reopen it. We lose track of what we were doing. REPL tends to be good for quick testing of little bits of code in isolation and experimenting with how node behaves.

For example, if we're curious about what happens when we try to add a number to a string? We could test that out in REPL. But nobody would use a rappel to write a large application. It's just not the right tool for the job. It doesn't provide a way for us to save our code or separate it into different files.

??The Process module in NodeJS

Let’s create something simple and a little silly in your code editor. So create a JS file - test.js and write the following code there.

Now if you want to run the file, you need to do this in the terminal,

Now you might be thinking that we can run that code easily inside the browser. Then why do need NodeJS? It doesn't really make sense to have a node, but we have other features like the process object.

If you hit enter, you’ll get a whole bunch of different information about the process, which is just the node program that's currently running here. One of the features in this node object that I want us to take a look at right now is this argv property that we can see contains an array,

right now it just contains the path to our node executable. So this will be different on your system, depending on where NodeJS has been installed and depending on which operating system you're running Node on. But it always contains that path to Node.

??So what's argv used for?

Before that, you need to know a little about the process object. It is an object available on the global object that provides information about and control over the current Node.js process. And argv is one of the properties of the process object.

The?process.argv property returns an array containing the command-line arguments passed when the Node.js process was launched. The first element will be the?execPath i.e. the absolute path to the NodeJS executable. The second element will be the path to the JavaScript file being executed. The remaining elements will be any additional command-line arguments.

So with the help of the argv array, we can pass arguments into the node process. Let's see.

Using the process module, this script can get access to the arguments that were passed to it.

So instead of hard coding, the var mission is going to get the string ‘NodeJS’ from the process running. In fact, you can see each item in the process.argv by doing this -

and then passing arguments while executing the file,

??Node.js VS Browser

So how is NodeJS different than a Browser? Well, we know that JavaScript is a programming language, and any time you want to run some JavaScript code or a file on your computer, you send it to a JavaScript engine like Chrome's V8. This engine then converts those JavaScript instructions to those that the hardware on your computer understands.

What's the difference to us as developers when running JavaScript code and Node compared to when we run it in the browser? If we go into our trusty REPL,

In NodeJS, the window object and all of the global functions that it provides in the browser are not defined. This makes sense because there's no browser or browser window that's currently running.

Instead, Node has its own version called global, which like the window object, has a bunch of things that we can use.

For example, the process object which we saw earlier and the argv property that has the list of arguments that were passed into our node program. We can access things like global.process.argv, but we don't need to import them from elsewhere. In fact, we don't even need to specify that they come from the global object, it's already in scope.

global has all of the functionality that we can use directly, even the console.log function that we're so familiar with is actually global, that console, that log a string.

We don't have access to browser-specific things like window or the document object, but we do have access to some very useful node-specific things. Let’s explore more about the global object.

??The global Object

For a second, let's compare our browser’s APIs available via the window object with our Node’s APIs available through the global object. In the browser, whether we're using the V8 engine like Chrome or something different like Firefox or Safari, we tend to deal with different things than Node.

• So while we have global in NodeJS, We have a window in the browser. In the browser, we tend to deal with HTML and browsing documents instead of processes like node script or a node server that are running on your system.
• So on the browser, we have things that help us interact with our browsing history and figure out our location. The current address or URL our browser is pointed to, and there's a navigator object, which gives us access to data about the browser that we're currently using. These things don't make very much sense in NodeJS
• But on the other hand, we have access to things like the arguments that were passed into our process. We have information about modules that we've loaded with code and functions that we want to reuse. And because our node scripts run on our computer and tend to live in files when we're running node scripts, we can get the file name of that script using __filename. And there's also __dirname for the directory in which your script lives.
• Probably the most important one is the require function here, it is built into Node’s global, and it allows us to import functions and modules, many of which allow us to do things that browsers wouldn't allow us to do, for example, to read and write files on your system and even to create a server that serves those files over the internet.

These things will all be very useful for us when writing Node applications. There’re also many things available on global, this is just a breakdown of some of the more common globals that node provides for us and compare them to what we have in the browser.