How to build a JavaScript Command Line Interface (CLI) with Node.js

How to build a JavaScript Command Line Interface (CLI) with Node.js

Another area where Node.js is really useful is for building command-line applications — and that’s what we’re going to be doing in this article - build a JavaScript Command Line Interface (CLI) with Node.js

As great as Node.js is for “traditional” web applications, its potential uses are far broader. Microservices, REST APIs, tooling, working with the Internet of Things and even desktop applications: it’s got your back.

Another area where Node.js is really useful is for building command-line applications — and that’s what we’re going to be doing in this article. We’re going to start by looking at a number of third-party packages designed to help work with the command line, then build a real-world example from scratch.

What we’re going to build is a tool for initializing a Git repository. Sure, it’ll run git init under the hood, but it’ll do more than just that. It will also create a remote repository on GitHub right from the command line, allow the user to interactively create a .gitignore file, and finally perform an initial commit and push.

As ever, the code accompanying this tutorial can be found on our GitHub repo.

Why Build a Command-line Tool with Node.js?

Before we dive in and start building, it’s worth looking at why we might choose Node.js to build a command-line application.

The most obvious advantage is that, if you’re reading this, you’re probably already familiar with it — and, indeed, with JavaScript.

Another key advantage, as we’ll see as we go along, is that the strong Node.js ecosystem means that among the hundreds of thousands of packages available for all manner of purposes, there are a number which are specifically designed to help build powerful command-line tools.

Finally, we can use npm to manage any dependencies, rather than have to worry about OS-specific package managers such as Aptitude, Yum or Homebrew.

Tip: that isn’t necessarily true, in that your command-line tool may have other external dependencies.

What We’re Going to Build: ginit

For this tutorial, We’re going to create a command-line utility which I’m calling ginit. It’s git init, but on steroids.

You’re probably wondering what on earth that means.

As you no doubt already know, git init initializes a Git repository in the current folder. However, that’s usually only one of a number of repetitive steps involved in the process of hooking up a new or existing project to Git. For example, as part of a typical workflow, you may well:

  1. initialise the local repository by running git init
  2. create a remote repository, for example on GitHub or Bitbucket — typically by leaving the command line and firing up a web browser
  3. add the remote
  4. create a .gitignore file
  5. add your project files
  6. commit the initial set of files
  7. push up to the remote repository.

There are often more steps involved, but we’ll stick to those for the purposes of our app. Nevertheless, these steps are pretty repetitive. Wouldn’t it be better if we could do all this from the command line, with no copy-pasting of Git URLs and such like?

So what ginit will do is create a Git repository in the current folder, create a remote repository — we’ll be using GitHub for this — and then add it as a remote. Then it will provide a simple interactive “wizard” for creating a .gitignore file, add the contents of the folder and push it up to the remote repository. It might not save you hours, but it’ll remove some of the initial friction when starting a new project.

With that in mind, let’s get started.

The Application Dependencies

One thing is for certain: in terms of appearance, the console will never have the sophistication of a graphical user interface. Nevertheless, that doesn’t mean it has to be plain, ugly, monochrome text. You might be surprised by just how much you can do visually, while at the same time keeping it functional. We’ll be looking at a couple of libraries for enhancing the display: chalk for colorizing the output and clui to add some additional visual components. Just for fun, we’ll use figlet to create a fancy ASCII-based banner and we’ll also use clear to clear the console.

In terms of input and output, the low-level Readline Node.js module could be used to prompt the user and request input, and in simple cases is more than adequate. But we’re going to take advantage of a third-party package which adds a greater degree of sophistication — Inquirer. As well as providing a mechanism for asking questions, it also implements simple input controls: think radio buttons and checkboxes, but in the console.

We’ll also be using minimist to parse command-line arguments.

Here’s a complete list of the packages we’ll use specifically for developing on the command line:

  • chalk — colorizes the output
  • clear — clears the terminal screen
  • clui — draws command-line tables, gauges and spinners
  • figlet — creates ASCII art from text
  • inquirer — creates interactive command-line user interface
  • minimist — parses argument options
  • configstore — easily loads and saves config without you having to think about where and how.

Additionally, we’ll also be using the following:

  • @octokit/rest — a GitHub REST API client for Node.js
  • lodash — a JavaScript utility library
  • simple-git — a tool for running Git commands in a Node.js application
  • touch — a tool for implementating the Unix touch command.
Getting Started

Although we’re going to create the application from scratch, don’t forget that you can also grab a copy of the code from the repository which accompanies this article.

Create a new directory for the project. You don’t have to call it ginit, of course:

mkdir ginit
cd ginit

Create a new package.json file:

npm init -y

And edit it to look like so:

  "name": "ginit",
  "version": "1.0.0",
  "description": "'git init' on steroids",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  "keywords": [
  "author": "<YOUR NAME>",
  "license": "ISC"

Now install the dependencies:

npm install chalk clear clui figlet inquirer minimist configstore @octokit/rest lodash simple-git touch

Now create an index.js file in the same folder and require the following dependencies:

const chalk = require('chalk');
const clear = require('clear');
const figlet = require('figlet');

Adding Some Helper Methods

We’re going to create a lib folder where we’ll split our helper code into modules:

  • files.js — basic file management
  • inquirer.js — command-line user interaction
  • github.js — access token management
  • repo.js — Git repository management.

Let’s start with lib/files.js. Here, we need to:

  • get the current directory (to get a default repo name)
  • check whether a directory exists (to determine whether the current folder is already a Git repository by looking for a folder named .git).

This sounds straightforward, but there are a couple of gotchas to take into consideration.

Firstly, you might be tempted to use the fs module’s realpathSync method to get the current directory:


This will work when we’re calling the application from the same directory (e.g. using node index.js), but bear in mind that we’re going to be making our console application available globally. This means we’ll want the name of the directory we’re working in, not the directory where the application resides. For this purpose, it’s better to use process.cwd:


Secondly, the preferred method of checking whether a file or directory exists keeps changing. The current way is to use existsSync. This returns true if the path exists, false otherwise.

Finally, it’s worth noting that when you’re writing a command-line application, using the synchronous version of these sorts of methods is just fine.

Putting that all together, let’s create a utility package in lib/files.js:

const fs = require('fs');
const path = require('path');

module.exports = {
  getCurrentDirectoryBase: () => {
    return path.basename(process.cwd());

  directoryExists: (filePath) => {
    return fs.existsSync(filePath);

Go back to index.js and ensure you require the new file:

const files = require('./lib/files');

With this in place, we can start developing the application.

Initializing the Node CLI

Now let’s implement the start-up phase of our console application.

In order to demonstrate some of the packages we’ve installed to enhance the console output, let’s clear the screen and then display a banner:

// index.js


    figlet.textSync('Ginit', { horizontalLayout: 'full' })

You can run the application using node index.js. The output from this is shown below.

Next up, let’s run a simple check to ensure that the current folder isn’t already a Git repository. That’s easy: we just check for the existence of a .git folder using the utility method we just created:


if (files.directoryExists('.git')) {
  console.log('Already a Git repository!'));

Tip: notice we’re using the chalk module to show a red-colored message.

Prompting the User for Input

The next thing we need to do is create a function that will prompt the user for their GitHub credentials.

We can use Inquirer for this. The module includes a number of methods for various types of prompts, which are roughly analogous to HTML form controls. In order to collect the user’s GitHub username and password, we’re going to use the input and password types respectively.

First, create lib/inquirer.js and insert this code:

const inquirer = require('inquirer');

const files = require('./files');

module.exports = {
  askGithubCredentials: () => {
    const questions = [
        name: 'username',
        type: 'input',
        message: 'Enter your GitHub username or e-mail address:',
        validate: function( value ) {
          if (value.length) {
            return true;
          } else {
            return 'Please enter your username or e-mail address.';
        name: 'password',
        type: 'password',
        message: 'Enter your password:',
        validate: function(value) {
          if (value.length) {
            return true;
          } else {
            return 'Please enter your password.';
    return inquirer.prompt(questions);

As you can see, inquirer.prompt() asks the user a series of questions, provided in the form of an array as the first argument. Each question is made up of an object which defines the name of the field, the type (we’re just using input and password respectively here, but later we’ll look at a more advanced example), and the prompt (message) to display.

The input the user provides will be passed in to the calling function as a Promise. If successful, we’ll end up with a simple object with two properties; username and password.

You can test all of this out by adding the following to index.js:

const inquirer  = require('./lib/inquirer');

const run = async () => {
  const credentials = await inquirer.askGithubCredentials();


Then run the script using node index.js.

Tip: When you’re done testing, don’t forget to remove the line const inquirer = require('./lib/inquirer'); from index.js, as we won’t actually need it in this file.

Dealing With GitHub Authentication

The next step is to create a function to retrieve an OAuth token for the GitHub API. Essentially, we’re going to “exchange” the username and password for a token.

Of course, we don’t want users to have to enter their credentials every time they use the tool. Instead, we’ll store the OAuth token for subsequent requests. This is where the configstore package comes in.

Storing Config

Storing config is outwardly quite straightforward: you can simply read and write to/from a JSON file without the need for a third-party package. However, the configstore package provides a few key advantages:

  1. It determines the most appropriate location for the file for you, taking into account your operating system and the current user.
  2. There’s no need to explicitly read or write to the file. You simply modify a configstore object and that’s taken care of for you in the background.

To use it, simply create an instance, passing it an application identifier. For example:

const Configstore = require('configstore');
const conf = new Configstore('ginit');

If the configstore file doesn’t exist, it’ll return an empty object and create the file in the background. If there’s already a configstore file, the contents will be decoded into JSON and made available to your application. You can now use conf as a simple object, getting or setting properties as required. As mentioned above, you don’t need to worry about saving it afterwards. That gets taken care of for you.

Tip: on macOS, you’ll find the file in /Users/[YOUR-USERNME]/.config/configstore/ginit.json, on Linux it’s in /home/[YOUR-USERNME]/.config/configstore/ginit.json

Communicating with the GitHub API

Let’s create a library for handling the GitHub token. Create the file lib/github.js and place the following code inside it:

const CLI = require('clui');
const Configstore = require('configstore');
const Octokit = require('@octokit/rest');
const Spinner = CLI.Spinner;

const inquirer = require('./inquirer');
const pkg = require('../package.json');

const conf = new Configstore(;

Now let’s add the function that checks whether we’ve already got an access token. We’ll also add a function that allows other libs to access octokit(GitHub) functions:

module.exports = {
  getInstance: () => {
    return octokit;

  getStoredGithubToken: () => {
    return conf.get('github.token');

If a conf object exists and it has github.token property, this means that there’s already a token in storage. In this case, we return the token value back to the invoking function. We’ll get to that later on.

If no token is detected, we need to fetch one. Of course, getting an OAuth token involves a network request, which means a short wait for the user. This gives us an opportunity to look at the clui package which provides some enhancements for console-based applications, among them an animated spinner.

Creating a spinner is easy:

const status = new Spinner('Authenticating you, please wait...');

Once you’re done, simply stop it and it will disappear from the screen:


Tip: you can also set the caption dynamically using the update method. This could be useful if you have some indication of progress, for example displaying the percentage complete.

Here’s the code to authenticate with GitHub:


let octokit;

module.exports = {


  setGithubCredentials: async () => {
    const credentials = await inquirer.askGithubCredentials();
    octokit = new Octokit({
      auth: {
        username: credentials.username,
        password: credentials.password,

  registerNewToken: async () => {
    const status = new Spinner('Authenticating you, please wait...');

    try {
      const response = await octokit.oauthAuthorizations.createAuthorization({
        scopes: ['user', 'public_repo', 'repo', 'repo:status'],
        note: 'ginit, the command-line tool for initalizing Git repos'
      const token =;
      if(token) {
        conf.set('github.token', token);
        return token;
      } else {
        throw new Error("Missing Token","GitHub token was not found in the response");
    } catch (err) {
      throw err;
    } finally {

Let’s step through this:

  1. we declare an octokit variable in the module’s upper scope
  2. we prompt the user for their credentials using the askGithubCredentials method we defined earlier
  3. we pass an auth option to the Octokit constructor to enable authenticated requests
  4. the result is assigned to the octokit variable so that it is available throughout the module
  5. we attempt to register a new access token for our application
  6. if we manage to get an access token, we set it in the configstore for next time.
  7. we then return the token.

Any access tokens you create, whether manually or via the API as we’re doing here, you’ll be able to see them here. During the course of development, you may find you need to delete ginit’s access token — identifiable by the note parameter supplied above — so that you can re-generate it.

Tip: if you have two-factor authentication enabled on your GitHub account, the process is slightly more complicated. You’ll need to request the confirmation code — for example, one sent via SMS — then supply it using the X-GitHub-OTP header. See the documentation for further information.

If you’ve been following along and would like to try out what we have so far, you can update index.js as follows:

const github = require('./lib/github');


const run = async () => {
  let token = github.getStoredGithubToken();
  if(!token) {
    await github.setGithubCredentials();
    token = await github.registerNewToken();

Please note you may get a Promise error if something goes wrong, such as inputting the wrong password. I’ll show you the proper way of handling such errors later.

Creating a Repository

Once we’ve got an OAuth token, we can use it to create a remote repository with GitHub.

Again, we can use Inquirer to ask a series of questions. We need a name for the repo, we’ll ask for an optional description, and we also need to know whether it should be public or private.

We’ll use minimist to grab defaults for the name and description from optional command-line arguments. For example:

ginit my-repo "just a test repository"

This will set the default name to my-repo and the description to just a test repository.

The following line will place the arguments in an array indexed by an underscore:

const argv = require('minimist')(process.argv.slice(2));
// { _: [ 'my-repo', 'just a test repository' ] }

Tip: this only really scratches the surface of the minimist package. You can also use it to intepret flags, switches and name/value pairs. Check out the documentation for more information.

We’ll write code to parse the command-line arguments and ask a series of questions. First, update lib/inquirer.js by inserting the following code right after askGithubCredentials function:

askRepoDetails: () => {
  const argv = require('minimist')(process.argv.slice(2));

  const questions = [
      type: 'input',
      name: 'name',
      message: 'Enter a name for the repository:',
      default: argv._[0] || files.getCurrentDirectoryBase(),
      validate: function( value ) {
        if (value.length) {
          return true;
        } else {
          return 'Please enter a name for the repository.';
      type: 'input',
      name: 'description',
      default: argv._[1] || null,
      message: 'Optionally enter a description of the repository:'
      type: 'list',
      name: 'visibility',
      message: 'Public or private:',
      choices: [ 'public', 'private' ],
      default: 'public'
  return inquirer.prompt(questions);

Next, create the file lib/repo.js and add this code:

const CLI = require('clui');
const fs = require('fs');
const git = require('simple-git/promise')();
const Spinner = CLI.Spinner;
const _ = require('lodash');

const inquirer = require('./inquirer');
const gh = require('./github');

module.exports = {
  createRemoteRepo: async () => {
    const github = gh.getInstance();
    const answers = await inquirer.askRepoDetails();

    const data = {
      description: answers.description,
      private: (answers.visibility === 'private')

    const status = new Spinner('Creating remote repository...');

    try {
      const response = await github.repos.createForAuthenticatedUser(data);
    } catch(err) {
      throw err;
    } finally {

Once we have that information, we can simply use the GitHub package to create a repo, which will give us a URL for the newly created repository. We can then set that up as a remote in our local Git repository. First, however, let’s interactively create a .gitignore file.

Creating a .gitignore File

For the next step, we’ll create a simple command-line “wizard” to generate a .gitignore file. If the user is running our application in an existing project directory, let’s show them a list of files and directories already in the current working directory, and allow them to select which ones to ignore.

The Inquirer package provides a checkbox input type for just that.

The first thing we need to do is scan the current directory, ignoring the .git folder and any existing .gitignore file (we do this by making use of lodash’s without method):

const filelist = _.without(fs.readdirSync('.'), '.git', '.gitignore');

If there’s nothing to add, there’s no point in continuing, so let’s simply touch the current .gitignore file and bail out of the function:

if (filelist.length) {
} else {

Finally, let’s utilize Inquirer’s checkbox “widget” to list the files. Insert the following code in lib/inquirer.js:

askIgnoreFiles: (filelist) => {
  const questions = [
      type: 'checkbox',
      name: 'ignore',
      message: 'Select the files and/or folders you wish to ignore:',
      choices: filelist,
      default: ['node_modules', 'bower_components']
  return inquirer.prompt(questions);

Notice that we can also provide a list of defaults. In this case, we’re pre-selecting node_modules and bower_components, should they exist.

With the Inquirer code in place, we can now construct the createGitignore() function. Insert this code in lib/repo.js:

createGitignore: async () => {
  const filelist = _.without(fs.readdirSync('.'), '.git', '.gitignore');

  if (filelist.length) {
    const answers = await inquirer.askIgnoreFiles(filelist);

    if (answers.ignore.length) {
      fs.writeFileSync( '.gitignore', answers.ignore.join( '\n' ) );
    } else {
      touch( '.gitignore' );
  } else {

Once “submitted”, we then generate a .gitignore by joining up the selected list of files, separated with a newline. Our function now pretty much guarantees we’ve got a .gitignore file, so we can proceed with initializing a Git repository.

Interacting with Git from Within the App

There are a number of ways to interact with Git, but perhaps the simplest is to use the simple-git package. This provides a set of chainable methods which, behind the scenes, run the Git executable.

These are the repetitive tasks we’ll use it to automate:

  1. run git init
  2. add the .gitignore file
  3. add the remaining contents of the working directory
  4. perform an initial commit
  5. add the newly-created remote repository
  6. push the working directory up to the remote.

Insert the following code in lib/repo.js:

setupRepo: async (url) => {
  const status = new Spinner('Initializing local repository and pushing to remote...');

  return git.init()
    .then(git.commit('Initial commit'))
    .then(git.addRemote('origin', url))
    .then(git.push('origin', 'master'))

Putting It All Together

First, let’s set a helper function in lib/github.js for setting up an oauth authentication:

githubAuth: (token) => {
  octokit = new Octokit({
    auth: token

Next, we create a function in index.js for handling the logic of acquiring the token. Place this code before the run() function’:

const getGithubToken = async () => {
  // Fetch token from config store
  let token = github.getStoredGithubToken();
  if(token) {
    return token;

  // No token found, use credentials to access GitHub account
  await github.setGithubCredentials();

  // register new token
  token = await github.registerNewToken();
  return token;

Finally, we update the run() function by writing code that will handle the main logic of the app:

const repo = require('./lib/repo');


const run = async () => {
  try {
    // Retrieve & Set Authentication Token
    const token = await getGithubToken();

    // Create remote repository
    const url = await repo.createRemoteRepo();

    // Create .gitignore file
    await repo.createGitignore();

    // Set up local repository and push to remote
    await repo.setupRepo(url);
    console.log('All done!'));
  } catch(err) {
      if (err) {
        switch (err.status) {
          case 401:
            console.log('Couldn\'t log you in. Please provide correct credentials/token.'));
          case 422:
            console.log('There already exists a remote repository with the same name'));

As you can see, we ensure the user is authenticated before calling all of our other functions (createRemoteRepo(), createGitignore(), setupRepo()) sequentially. The code also handles any errors and offers the user appropriate feedback.

You can check out the completed index.js file on our GitHub repo.

At this point you should have a working app. Give it a try and satisfy yourself that it works as expected.

Making the ginit Command Available Globally

The one remaining thing to do is to make our command available globally. To do this, we’ll need to add a shebang line to the top of index.js:

#!/usr/bin/env node

Next, we need to add a bin property to our package.json file. This maps the command name (ginit) to the name of the file to be executed (relative to package.json).

"bin": {
  "ginit": "./index.js"

After that, install the module globally and you’ll have a working shell command:

npm install -g

Tip: this will also work on Windows, as npm will helpfully install a cmd wrapper alongside your script.

If you want to confirm the install worked, you can list your globally installed Node modules using:

npm ls --depth=0

Taking it Further

We’ve got a fairly nifty, albeit simple command-line app for initializing Git repositories. But there’s plenty more you could do to enhance it further.

If you’re a Bitbucket user, you could adapt the program to use the Bitbucket API to create a repository. There’s a Node.js API wrapper available to help you get started. You may wish to add an additional command-line option or prompt to ask the user whether they want to use GitHub or Bitbucket (Inquirer would be perfect for just that) or merely replace the GitHub-specific code with a Bitbucket alternative.

You could also provide the facility to specify your own set of defaults for the .gitgnore file, instead of a hardcoded list. The preferences package might be suitable here, or you could provide a set of “templates” — perhaps prompting the user for the type of project. You might also want to look at integrating it with the command-line tool/API.

Beyond all that, you may also want to add additional validation, provide the ability to skip certain sections, and more. If you have any other ideas, do let us know in the comments.

Top 7 Most Popular Node.js Frameworks You Should Know

Top 7 Most Popular Node.js Frameworks You Should Know

Node.js is an open-source, cross-platform, runtime environment that allows developers to run JavaScript outside of a browser. In this post, you'll see top 7 of the most popular Node frameworks at this point in time (ranked from high to low by GitHub stars).

Node.js is an open-source, cross-platform, runtime environment that allows developers to run JavaScript outside of a browser.

One of the main advantages of Node is that it enables developers to use JavaScript on both the front-end and the back-end of an application. This not only makes the source code of any app cleaner and more consistent, but it significantly speeds up app development too, as developers only need to use one language.

Node is fast, scalable, and easy to get started with. Its default package manager is npm, which means it also sports the largest ecosystem of open-source libraries. Node is used by companies such as NASA, Uber, Netflix, and Walmart.

But Node doesn't come alone. It comes with a plethora of frameworks. A Node framework can be pictured as the external scaffolding that you can build your app in. These frameworks are built on top of Node and extend the technology's functionality, mostly by making apps easier to prototype and develop, while also making them faster and more scalable.

Below are 7of the most popular Node frameworks at this point in time (ranked from high to low by GitHub stars).


With over 43,000 GitHub stars, Express is the most popular Node framework. It brands itself as a fast, unopinionated, and minimalist framework. Express acts as middleware: it helps set up and configure routes to send and receive requests between the front-end and the database of an app.

Express provides lightweight, powerful tools for HTTP servers. It's a great framework for single-page apps, websites, hybrids, or public HTTP APIs. It supports over fourteen different template engines, so developers aren't forced into any specific ORM.


Meteor is a full-stack JavaScript platform. It allows developers to build real-time web apps, i.e. apps where code changes are pushed to all browsers and devices in real-time. Additionally, servers send data over the wire, instead of HTML. The client renders the data.

The project has over 41,000 GitHub stars and is built to power large projects. Meteor is used by companies such as Mazda, Honeywell, Qualcomm, and IKEA. It has excellent documentation and a strong community behind it.


Koa is built by the same team that built Express. It uses ES6 methods that allow developers to work without callbacks. Developers also have more control over error-handling. Koa has no middleware within its core, which means that developers have more control over configuration, but which means that traditional Node middleware (e.g. req, res, next) won't work with Koa.

Koa already has over 26,000 GitHub stars. The Express developers built Koa because they wanted a lighter framework that was more expressive and more robust than Express. You can find out more about the differences between Koa and Express here.


Sails is a real-time, MVC framework for Node that's built on Express. It supports auto-generated REST APIs and comes with an easy WebSocket integration.

The project has over 20,000 stars on GitHub and is compatible with almost all databases (MySQL, MongoDB, PostgreSQL, Redis). It's also compatible with most front-end technologies (Angular, iOS, Android, React, and even Windows Phone).


Nest has over 15,000 GitHub stars. It uses progressive JavaScript and is built with TypeScript, which means it comes with strong typing. It combines elements of object-oriented programming, functional programming, and functional reactive programming.

Nest is packaged in such a way it serves as a complete development kit for writing enterprise-level apps. The framework uses Express, but is compatible with a wide range of other libraries.


LoopBack is a framework that allows developers to quickly create REST APIs. It has an easy-to-use CLI wizard and allows developers to create models either on their schema or dynamically. It also has a built-in API explorer.

LoopBack has over 12,000 GitHub stars and is used by companies such as GoDaddy, Symantec, and the Bank of America. It's compatible with many REST services and a wide variety of databases (MongoDB, Oracle, MySQL, PostgreSQL).


Similar to Express, hapi serves data by intermediating between server-side and client-side. As such, it's can serve as a substitute for Express. Hapi allows developers to focus on writing reusable app logic in a modular and prescriptive fashion.

The project has over 11,000 GitHub stars. It has built-in support for input validation, caching, authentication, and more. Hapi was originally developed to handle all of Walmart's mobile traffic during Black Friday.

Node.js Tutorial for Beginners | Node.js Crash Course | Node.js Certification Training

This courseis designed for professionals who aspire to be application developers and gain expertise in building real-time, highly-scalable applications in Node.js. The following professionals can go for this course :

Why learn Node.js?

Node.js uses JavaScript - a language known to millions of developers worldwide - thus giving it a much lower learning curve even for complete beginners. Using Node.js you can build simple Command Line programs or complex enterprise level web applications with equal ease. Node.js is an event-driven, server-side, asynchronous development platform with lightning speed execution. Node.js helps you to code the most complex functionalities in just a few lines of code...

Thanks for reading :heart: If you liked this post, share it with all of your programming buddies! Follow me on Facebook | Twitter

Learn More

The Complete Node.js Developer Course (3rd Edition)

Angular & NodeJS - The MEAN Stack Guide

NodeJS - The Complete Guide (incl. MVC, REST APIs, GraphQL)

Docker for Node.js Projects From a Docker Captain

Intro To MySQL With Node.js - Learn To Use MySQL with Node!

Node.js Absolute Beginners Guide - Learn Node From Scratch

React Node FullStack - Social Network from Scratch to Deploy

Selenium WebDriver - JavaScript nodeJS webdriver IO & more!

Complete Next.js with React & Node - Beautiful Portfolio App

Build a Blockchain & Cryptocurrency | Full-Stack Edition

A Beginner Guide To Node.js (Basic Introduction To Node.js)

Node.js is a very popular javascript free and open source cross-platform for server-side programming built on Google Chrome’s Javascript V8 Engine. It is used by thousands of developers around the world to develop mobile and web applications. According to StackOverflow survey, Node.js is one of most famous choice for building the web application in 2018.


Node.js is a very popular javascript free and open source cross-platform for server-side programming built on Google Chrome’s Javascript V8 Engine. It is used by thousands of developers around the world to develop mobile and web applications. According to StackOverflow survey, Node.js is one of most famous choice for building the web application in 2018.

In this article, you will gain a deep understanding of node, learn how node.js works and why it is so popular among the developers and startups. Not In startup even big companies like eBay, Microsoft, GoDaddy, Paypal etc.

Why is Node.js so much popular

It is fast very fast

It’s a javascript runtime built on google chrome javascript v8 engine which means both node js and js executed in your browser running in the same engine that makes it very fast in comparison to any other server-side programming language.

It uses event-driven and non-blocking model

Node.js uses the event-driven, non-blocking I/O model that makes it very lightweight and efficient.
Now let’s understand the above statement in more details. Here I/O refers to Input /Output.

Event Driven Programming is a paradigm in which control flow of any program is determined by the occurrence of the events. All these events monitor by the code which is known as an event listener. If you are from javascript background then most probably you know what is event-listeners. In short, event-listener is a procedure or function that waits for an event to occurs. In javascript, onload, onclick, onblur most common event-listener.

**Blocking I/O **takes time and hence block other function. Consider the scenario where we want to fetch data from the database for two different users. Here we can not get the data of the second user until we did not complete the first user process. Since javascript is a single threaded and here we would have to start a new thread every time we want to fetch user data. So here Non-Blocking I/O parts come in.

Example of Blocking I/O operation

<span class="hljs-keyword">const</span> fs = <span class="hljs-built_in">require</span>(‘fs’);
<span class="hljs-keyword">var</span> contents = fs.readFileSync(<span class="hljs-string">'package.json'</span>).toString();
<span class="hljs-built_in">console</span>.log(contents);

In** Non-blocking I/O **operations, you can get the user2 data without waiting for the completion of the user1 request. You can initiate both requests in parallel. **Non-blocking I/O **eliminates the need for the multi-threaded, since the system can handle multiple requests at the same time. That is the main reason which makes it very fast.

Example of Non-blocking I/O operation

<span class="hljs-keyword">const</span> fs = <span class="hljs-built_in">require</span>(‘fs’);
fs.readFile(<span class="hljs-string">'package.json'</span>, <span class="hljs-function"><span class="hljs-keyword">function</span> (<span class="hljs-params">err, buf</span>)</span>{
    <span class="hljs-built_in">console</span>.log(buf.toString());

Note: You can learn more about the event loop and other things by going through this link.

What is Node Package Manager ( NPM )

It is is the official package manager for the node. It bundles automatically installed when you install node in your system. It is used to install new packages and manage them in useful ways. NPM install packages in two modes local and global. In the local mode, NPM installs packages in the node_module directory of the current working directory which location is owned by current user. Global packages installed in the directory where the node is installed and the location is owned by the root user.

What is the package.json

package.json is a plain JSON text file which manages all the packaged which you installed in your node application. Every Node.js applications should have this file at the root directory to describe the application metadata. A simple package.json file looks like below

    <span class="hljs-string">"name"</span> : <span class="hljs-string">"codesquery"</span>,
    <span class="hljs-string">"version"</span> : <span class="hljs-string">"1.0.0"'
    "repository": {
	"type" : "git",
	"url" : "github_repository_url"
    "dependencies": {
	"async": "0.8.0",
	"express": "4.2.x"

In the above file, name and versions are mandatory for the package.json file and rest is optional.

Installing Node.js

  • In Windows, you can install the node.js by using the installer provided by the official node.js website. Follow the installer instruction and node.js will be installed in your windows system.
  • In Linux OS, you can install the node.js by adding the PPA in your system and then install node js. Run the below command the terminal to install node js
sudo apt-get install curl python-software-properties
curl -sL https:<span class="hljs-comment">// | sudo -E bash -</span>
sudo apt-get install nodejs

  • In macOS, download the macOS installer from the official node.js website. Now run the installer by accepting the license and selecting the destination.

Test Node.js Installation

You can test the node.js installation by typing below command in the terminal

node -v

If node.js was installed successfully then you will see the installed version of the node in the terminal.

Frameworks and Tools

After gaining the popularity among the developers, there are so many frameworks built for the node js for the different type of uses. Here, I will tell you some of the most famous node js frameworks in the market

  • Express.js is the most popular framework for node.js development. A lot of popular websites is powered by express.js due to its lightweight.
  • Hapi.js is a powerful and robust framework for developing the API. This framework has features like input validation, configuration based functionality, error handling, caching and logging.
  • Metor.js is one of the most used frameworks in the node js web application development. This framework is backed by a huge community of developers, tutorials and good documentation.
  • is used to build a real-time web application like chat system and analytics. Its allow the bi-direction data flow between the web client and server.
  • Koa.js is yet another most used framework to build the web application using the node js. This framework is backed by the team behind Express.js. It allows you to ditch callbacks and increase error handling.


Today, Node.js shaping the future of web and application development technology. This is the just the basic of how node js works. If you want to build a scalable web application using the node js then you need to know more then this.

Till now, you have got the basic idea of node.js and now it is time to build something using the node.js. You can start with first by create a simple server using the node.js and then connect your node with MongoDB to perform the basic crud operation.