Member preview

Installing Node.js On PC, Mac and Linux — Getting Started With React (From Scratch)

In this tutorial we’ll go over the details of working with Node.js server, install it on any operating system and play around with some of its settings. This Node tutorial was taken from an unreleased book. It can be used as an introduction to getting started with React from scratch.

We’ve come to a point in my Medium tutorial series where we can start learning JavaScript programming with React. But we are not fully ready until we can reconcile front-end and back-end JavaScript development. Over the last few years a bit of a cognitive dissonance has formed in the web development community over the subject.

What does it mean to program in JavaScript? Typing commands into a text editor and executing them by feeding the file into a browser? Or bundling multiple modules of your JavaScript into one .js file using helper server-side packages (Node.js, Webpack, Babel, JSX, etc.)? This latter one is for those who treat JavaScript as a back-end language.

At first all this lingo may cause a temporary setback. Do you really have to know all of those? It seems like a tall order. No matter how cute the package names sound. I mean Babel. Really? And moreover what in the world are they? They all aid the server-side process in one way or another. You can use them individually or all of them together in combination. This is almost like asking if you want ketchup or mustard on your Wiener Würstchen.

In order to begin looking at React we must become familiar with building a development environment and at least some of the tools used in working with one. This is unusual for many JavaScripters because for ages JavaScript has been a strictly front-end language.

And yes, you can run React and even Babel by simply adding them into your page via the traditional <script> tag. It’ll still work and it’s great for practice. But these types of “builds” are not taken seriously by web development community, especially in a professional environment. Besides Babel added via <script> tag is incredibly slow because they are processed by the browser’s JIT compiler. But what we want is for these types of tools to run directly on our server. And that’s what installing Node.js allows us to do.

This chapter will help you make the transition from front-end JavaScript to the back-end. Follow examples, but also do a little research on your own. The text that follows will provide a starting point and teach you basic principles of setting up a development environment on Windows, OSX and Linux.

So how do we make that transition? The purpose of this chapter is to guide the reader through this sometimes awfully painful process (If you’ve never done this before.) Hopefully, it accomplishes that task. To guide. No to inflict pain.

Development environments are not limited to working with React, of course. Even other libraries or frameworks like Vue can utilize this type of a build. It’s just a different way of thinking of building your application. We are no longer tied to browser’s Just In Time compiler alone. But in many cases this provides a high performance base on which to run your application. It’s all about moving JavaScript into the back end.

If you already have experience with setting up a development environment, you can skip forward to the next chapter where we will be actually building applications with React. If not, let’s move forward…

Crafting a custom development environment is what makes server-side programming distinct from its front-end counterpart. Reconciling the two is the goal of this chapter. Of course the glue between the two will be Node.js and npm. Which allows us not only run JavaScript in your console on Windows (cmd.exe), Terminal on Mac OSX and/or bash on Linux, but acts as a repository of many available “pre-baked” packages that can be installed or uninstalled from your build. We will perform the said reconciliation by exploring the process from start to finish. But you might still have to look some things up online. Because there isn’t any one formula for this process. Installation of Node and a few helper tools for building and maintaining our application will be required.

The Times They Are A-Changin’

If you are someone who enjoys writing JavaScript in a text file and feeding it to the browser that’s fine. And you might even find these extra steps a bit frustrating. But if you plan on professionally working in the web development industry you are going to have to learn the server-side setup. An employer already expects that you know all of these things. And often, lack of knowledge about what Node.js, JSX and Babel are, is the reason many people don’t pass web development job interviews. It’s the nitty gritty details of server-side. At an interview you’ll be drilled on all of these subjects. And if your plan is to pursue web development as a career, there is simply no way around this.

Sure, it makes JavaScript a bit more cryptic and complicated. But authentic programmers care about these things. And if you can learn to love the build process, and fiddle with the server side of things for a while, you will understand its significance. But I alone cannot make this happen for you.

In this tutorial, I can only guide you through the process by bringing up some of the most important aspects of server-side programming with JavaScript. I can’t actually gain experience for you. Many hours will be spent learning how to build apps. But I guarantee that if you take this extra step you will not regret it. Intimately understanding the server side build challenges you to not only become a much more skilled programmer but it can help you secure a job.

— -

The line it is drawn. The curse it is cast. The slow one now will later be fast. As the present now will later be past. The order is Rapidly fadin’. And the first one now will later be last for the times they are a-changin’. The Times They Are A-Changin’ — Bob Dylan

Node, NPM, Babel, JSX, Yarn and WebPack

In the past, you could get away with adding a few <.js> files to your project and starting to work on your application with newly added features from the library. And this is still the way many applications and websites are built. But times are a-changing, Bob.

Many of us started learning JavaScript from personal interest in building websites, or perhaps becoming a freelance web designer or developer.

If you are a WordPress developer, for example, you must be familiar with adding plugins that ultimately depend on a <.js> file of some sorts. They are often added via <script> tags by internals of the WordPress platform. Today even WordPress is trying to decide its future between React and Vue framework to catch up with rapid changes in web development industry. If not, it risks being seen as an outdated platform. That’s how significant these changes are that have been taking place since 2015. A lot is still sinking in. It’s a slow change. But it would be nice if we could sort of “ease into it” by focusing on the the things that are fundamentally changing and are here to stay with us for years to come.

Adding <.js> files to your project is no longer enough. Don’t get me wrong, those libraries are still important. If anything, jQuery has become a household name. And documentation of frameworks like Vue even recommend adding jQuery to your project in certain situations.

In those days of the old you could add jQuery.js, Modernzr.js and/or Backbone.js (or many other libraries) to help you perform specific tasks. This way, for example, you could figure out what browser version is used for accessing your app and deliver content based on that information without having to write your own browser-detection code.

All that was done in pre-2015 JavaScript.

Installing Node.js and NPM

When JavaScript code began migrating toward server-side many developers started to rely on Node.js and its npm client. NPM stands for Node Package Manager. NPM (often referred to as just “npm” in lower-case letters) helps you install and uninstall packages containing pre-baked functionality. It’s a client program for installing and managing packages.

In the following section we will take a look at how to install node and npm in your local environment on Windows, Linux or OSX. The installation process for each is slightly different. Once installed, however you can use the npm command just the same across any OS.

Installing Node on Windows

First, you just install Node application by downloading it from the “official” website. Google is your friend. If you are on Windows, simply download it from there and go through the installation steps.

Then open your command line console (by holding down Windows-key and pressing “R”, then typing “cmd” and pressing Enter.) Type “node” into your Windows command line client to start an instance:

C:\node

>

The console will turn into node execution mode indicated by > character and stall until something is typed.

Type console.log(“hello”) for example and you will be greeted by following output:

> console.log(“hello”);

> hello

> undefined

Looks good. We typed a JavaScript statement. It executed and logged the text “hello”. But what about undefined? Still the result of this statement is indeed undefined. This is reminiscent of typing the same commands into Chrome Developer’s Console. Except now running directly in your Windows OS. What this means is that you can now execute JavaScript on server-side!

If you typed a more meaningful JavaScript statement, such as var a = 1; followed by a + 1; Instead of undefined you would accurately >2. The evaluated result of a JavaScript statement. At one point you’d have to exit the Node shell to continue installing the rest of packages. Just press Ctrl-C twice. Either on OSX or Windows.

Note the Windows node installation has already installed npm client, as well as few other tools by default. You just have to make sure it is “checked” during one of the installation screens as you hit “Next” button. To install npm on a Linux web server there is one extra step.

Now just to double check if node is installed, execute the following command:

node -v

And the output will be something like:

v7.1.0

Of course by the time you are reading this tutorial Node must have already moved on a few versions up. Don’t be surprised by its changing nature. Most updates are minor, but large upgrades can break your build. This is why some builds are based around a specific version of node.

Whenever you install node or any other package, by default the latest version that currently exists will be installed. Note that there is nothing to download manually from sites. Installation of packages takes place directly from the shell.

Managing Node Version

You might also want to install Node’s NVM. Which stands for Node Version Manager. However there is no official support for it on Windows. The nvm package is not developed by Node and is biased toward Linux development.

For more information on the issue I recommend visiting the following URL:

https://github.com/creationix/nvm/issues/284

You can still install it on Windows via curl or wget.

On Linux (Let’s say Ubuntu) you can install nvm as follows:

curl -sL URL -o install_nvm.sh

Replace URL with:

https://raw.githubusercontent.com/creationix/nvm/v0.32.0/install.hs

If you don’t have curl installed you can get it from here: https://curl.haxx.se/download.html

Then inspect installation script with nano editor (you might have to install it first):

$ nano install_nvm.sh

To finalize installation:

$ bash install_nvm.sh

Doing this will install the software to your home directory at ~/.nvm and automatically add necessary bash configuration to your ~/.profile page.

I purposely won’t go into the rest of possibilities of working with Linux shell here. You can safely look them up online. It would take an entire book in itself just to describe working with Linux shell. However in the next section I’ll talk a bit more about configuration files with an example of installing nvm on OSX, which is also an almost entirely different type of beast.

On OSX you can pop open Terminal and execute the following commands:

brew update

brew install nvm

mkdir ~/.nvm

nano ~/.bash_profile

We updated brew and used it to install nvm. Sounds easy. But what is this .bash_profile file? This is a hidden file on your OSX. This file is loaded before shell environment is loaded into Terminal. It contains all startup configuration preferences. You can even use it to change the color of text in your terminal prompt. These types of hidden files are often called “dot files” because they are preceded with a dot (.) character. If you’ve ever worked with Linux web (especially Apache) then you may have already seen another “dot file” called .htaccess for Apache server config. Same thing here, only for Terminal. Think of it as “bash profile” (duh) or bash config. But what is bash you may ask? Bash is the standard shell in Linux. A shell is a user program or an environment provided for user interaction. Shell is a command language interpreter that executes commands read from user input. Terminal is the program that gives you access to the shell.

Anyway, this file can also be called .profile. Or named something else. But regardless of what it is called on your machine, you have to modify it with a text editor such as nano or vim. (In the example above we used nano.) We have to update the bash config file because after the server restarts it unsets nvm. This means you will have to enable it again and again just because you restarted your host. But if we add it to .bash_profile it will be automatically reloaded.

After opening the file with nano ~/.bash_profile add the following lines to the bottom of the file (you might already have a couple of exports defined in there):

export NVM_DIR=~/.nvm

source $(brew — prefix nvm)/nvm.sh

Save the file with those changes and type in the following commands into the shell:

source ~/.bash_profile

echo $NVM_DIR

You can now install node via nvm. (not with brew install node which is an alternative) But brew installs the latest version automatically. Whereas nvm allows you to choose a version.

Also nvm is a package that itself has a version. As any other Node package would. And we can install a particular version of any package with npm as well. We’ll see how in just a bit.

So we installed nvm. But how do you manage Node version with nvm? We have 3 common parameters that help us do maintenance on the Node version itself: install, use and ls.

nvm install <version> Download and install a <version>

nvm use <version> Modify PATH to use <version>

nvm ls List versions (installed versions are blue)

Where <version> of node being references could be 7.1.0 for example.

Installing Node on Debian Linux (Ubuntu and Mint)

Node installation on Linux is trivial. In this tutorial I will use a Ubuntu example. Covering multiple Linux versions would create too much overwhelm. Let’s keep things simple. If you’re on a different version of a Linux OS you’ll have to look up how to install node and npm on your particular build.

On Ubuntu you can use Aptitude package manager to install Node package called which is traditionally called nodejs.

Log into your Ubuntu web server and type:

apt-get install nodejs

Of course installing nodejs with Aptitude installer assumes that you have apt-get installed as well. Your command line will also complain about it if you’re trying to type it on your Mac OSX via Terminal:

-bash: -apt-get: command not found

But there’s a small problem. If you are on Mac OSX you cannot install and use apt-get via Terminal (easily). The apt-get command works and should mainly be used on a Linux web server. Otherwise use brew. We’ll see below how that’s done. But there is one more thing.

Depending on your favorite (or an installed) text editor type one of the following commands:

nano ~/.bashrc
edit ~/.bashrc
vim ~/.bashrc

And anywhere in the file add the line:

alias node=”nodejs”

Hold “Control” key and press X to exit the editor.

I used nano editor, so on my screen I was shown this message:

Save modified buffer (ANSWERING “No” WILL DESTROY CHANGES) ?

Press Y.

File Name to Write: /root/.bashrc

Press Enter.

You have just added an alias to nodejs command and in your operating system it has become synonymous with node. You can use node / nodejs interchangeably.

Installing Node on OSX

One common tool for installing node directly on your OSX via Terminal is called homebrew. We’ve already used in one of the sections above to install nvm. And then we installed node via nvm. But you don’t always need to use nvm, especially in simpler builds or ones that rely on the most recent version of every package. In this case, you can use brew command to install node.

brew install node

Node installation automatically includes npm package manager.

Node installs directly on top of your operating system. Using our newly node installation we can now use npm to install any package by its name. For example calling:

npm install yarn

Will begin yarn installation.

Simply install any package and you’re ready to use them in your own application right away. There are thousands, if not millions (by now) of packages available for download as part of the global Node repository which seems to be always growing.

Think of packages as separate applications written in JavaScript that you can add to your project in much the same way as you usually add jQuery via the script tag.

You can also uninstall packages by issuing the following command:

npm uninstall yarn

And the package will be removed.

Installing Particular Version of a Package

If you want to install a particular version of yarn (or any other package) via npm you can concatenate the version number using the @ character.

For example, if you want to explicitly install yarn version 0.24.5 you would run the following command:

npm install yarn@0.24.5

You can check version of yarn by typing the following command:

yarn — version

And now of course to actually use yarn (which takes your package.json file and builds and links everything on it) you would issue the following command:

yarn install

This will bundle your build.

Global and Local installation

You have a choice between package installation in global and local mode.

You might see a npm “WARN” message if you execute the yarn installation we have just seen in the previous section.

WARN messages are not fatal errors. You can get away with them. But it’s always nice to follow their instructions. For example the yarn installation command above will produce an npm warning:

npm WARN prefer global yarn@0.24.5 should be installed with -g

This can be easily cured by installing yarn globally. This is achieved by including -g flag right before the package name:

npm install -g yarn

This will install yarn globally.

Yarn is a supporting library that makes building your project easier.

With no arguments, the yarn command will read your package.json, fetch packages from the npm registry, and populate your node_modules folder. It is equivalent to running npm install.

After yarning your dependencies (which will also download and link them to your project) you are ready to build your project. If you have webpack installed you can issue the following command from the root directory of your application:

webpack — config webpack.config.js

Here webpack.config.js is yet another configuration file specifically for building with webpack.

After executing that command and a wall of scrolling lines and loading bars consisting of ASCII characters bundle.js file will be produced which basically includes your entire JavaScript application in one <.js> file (even if it was created with multiple import/export files.) Simply include this bundle file in your main HTML file and your application is ready to execute in the browser.

Wow. What? All of this just to build a JavaScript application? Indeed. And there might be a lot more to the process. This is the way server-side JavaScript is built. But there is one more thing…

Local installation

If you want to depend on the package from your own module, you can install the package locally. For example, when your application needs to require the installed package as in:

var lodash = require(“lodash”);

You want to install it (Lodash in this case) locally.

Lodash is a JavaScript library which provides utility functions for common programming tasks.

Global installation

When you want the package to be available from the command line you will want to install it globally. And this is why yarn is complaining about this in our previous example. Yarn is used as a maintenance tool for managing configuration of your entire project from command line.

Cognitive Dissonance

Perhaps server-side programming with JavaScript is not really new to anyone who has been dabbling with EcmaScript 6 since it came out in 2015. Or even since the dawn of JavaScript in Netscape Navigator days. Yes it’s been a while. But a large majority of JavaScript programmers are still not familiar with server-side programming.

But then again, anyone who comes to web development for the first time, not just Millennials will be eventually faced with learning server-side programming. That is, if one has any sort of more than veneer-thin interest in web application development in JavaScript.

Chances are if you are studying JavaScript in post-2015 world (This writing came out in 2017, but you know what I mean… Most of the major changes in JavaScript specification started to take place in 2015) you began your journey by focusing on React, Vue and Angular. You may have even found yourself looking into GraphQL and TypeScript.

Because these libraries and frameworks were popular. They are in active competition among each other as they are being fiercely marketed by Google, Facebook and Evan You (the creator of Vue framework). For these reasons you may have become familiar with those libraries and frameworks before studying fundamentals of JavaScript (like closures, prototype, event listeners and so on.)

That is at the core of why this tutorial was written. Because you might be studying JavaScript from a higher level down. First the popular libraries and only then plain vanilla JavaScript itself. If that works for you, that’s great. But so many web developers have given up exactly for this reason. It’s like trying to learn how to drive a car by trying to understand how transmission works.

The transmission box just works. You just use the stick shift to switch gears. In the same way fully understanding a library like React, for example, already assumes that you understand the basics of JavaScript. This is the point at which many will side with different views.

My personal guess is that the difference here is between the Web Development community and that of Software Engineers that come to JavaScript from the era when programming in C++ for desktop applications was the norm. C++ has always been at the core a compiled, server-side language.

This division between front-end and server-side JavaScript has resulted in formation of two distinct groups of web developers:

  1. Front-end bias. Web developers from the glorious days of jQuery. No configuration files or development environment required. Just run code on the front end in your browser.
  2. Back-end bias. Software engineers who are taking C++-like principles to the web. Usually requires setting up a development environment. Project configuration files are considered to be a “must have”.

A circumstantial bias may develop.

You might be coming from front-end development to JavaScript from the vantage point of back-end programming (like React). Or the other way around. It just depends on how and what lured you into the world of web development. JavaScript is no longer as easy as it once was. Things like these are exactly what creates confusion for JavaScript programmers in the post-modern world.

You might get excited about React. And think that this is the coolest JavaScript library there is. You might be right about that. But making a choice to learn React as your starting point with JavaScript in general might not be a great idea. Because setting up development environment, which is the only reasonable way of even wanting to write React apps, can be a lot of hassle for newcomers.

I am not saying that either way is right or better. They both have their merits. But it’s nice to be aware that they exist. Because if you are going to learn either, it’s nice to think about each distinct side (front-end, back-end) of web development from a proper perspective.