Hello Node.js#

Node.js was first released in 2009 by Ryan Dahl as a reaction to how slow web servers were at the time. Most web servers would block for any I/O task, such as reading from the file system or accessing the network, and this would dramatically lower their throughput. For example, if a server was receiving a file upload, it would not be able to handle any other request until the upload was finished.

At that time, Dahl mostly worked with Ruby, and the dominant model for web applications was to have a pool of ruby processes that a web server (e.g. Ngninx) would proxy to. If one Ruby process was blocked with an upload, Nginx served the request to another.

Node.js changed this model by making all I/O tasks non-blocking and asynchronous. This allowed web servers written in Node.js to serve thousands of requests concurrently -- subsequent requests didn't have to wait for previous ones to complete.

The first demo of Node.js generated so much interest because it was the first time that a developer could create their own web server easily and have it work so well.

Over time Node.js became good at system tasks other than web serving and started to shine as a flexible yet lower level server-side language. It could do anything typically done with Python, Ruby, Perl, and PHP, and it was faster, used less memory, and in most cases had better APIs for the system calls.

For example, with Node.js we can create HTTP and TCP servers with only a few lines of code. We'll dive in and build one together soon, but just to show what we mean, here's a functioning Node.js web server in only 80 characters:

A Rich Module Ecosystem#

Node.js began to shine with the introduction of npm, the package manager bundled with Node.js. A core philosophy of Node.js is to have only a small collection of built-in modules that come preinstalled with the language.

Examples of these modules are fs, http, tcp, dns, events, child_process, and crypto. There's a full list in the Node.js API documentation.

This may seem to be a bad thing. Many people would be puzzled as why Node.js would choose not to have a large collection of standard modules preinstalled and available to the user. The reason is a bit counterintuitive, but has ultimately been very successful.

Node.js wanted to encourage a rich ecosystem of third-party modules. Any module that becomes a built-in, core module will automatically prevent competition for its features. In addition, the core module can only be updated on each release of Node.js.

This has a two-fold suppression effect on module authorship. First, for each module that becomes a core module in the standard library, many third-party modules that perform a similar feature will never be created. Second, any core modules will have development slowed by the Node.js release schedule.

This strategy has been a great success. npm modules have grown at an incredible pace, overtaking all other package managers. In fact, one of the best things about Node.js is having access to a gigantic number of modules.

When To Use Node.js#

Node.js is a great choice for any task or project where one would typically use a dynamic language like Python, PHP, Perl, or Ruby. Node.js particularly shines when used for:

  • HTTP APIs,

  • distributed systems,

  • command-line tools, and

  • cross-platform desktop applications.

Node.js was created to be a great web server and it does not disappoint. In the next section, we'll see how easy it is to build an HTTP API with the built-in core http module.

Web servers and HTTP APIs built with Node.js generally have much higher performance than other dynamic languages like Python, PHP, Perl, and Ruby. This is partly because of its non-blocking nature, and partly because the Node.js V8 JavaScript interpreter is so well optimized.

There are many popular web and API frameworks built with Node.js such as express, hapi, and restify.

Distributed systems are also very easy to build with Node.js. The core tcp module makes it very easy to communicate over the network, and useful abstractions like streams allow us to build systems using composable modules like dnode.

Command-line tools can make a developer's life much easier. Before Node.js, there wasn't a good way to create CLIs with JavaScript. If you're most comfortable with JavaScript, Node.js will be the best way to build these programs. In addition, there are tons of Node.js modules like yargs, chalk, and blessed that make writing CLIs a breeze.

Electron, allows us to build cross-platform desktop applications using JavaScript, HTML, and CSS. It combines a browser GUI with Node.js. Using Node.js we're able to access the filesystem, network, and other operating system resources. There's a good chance you use a number of Electron apps regularly (both Visual Studio Code and Slack have been built using Electron).

When Node.js May Not Be The Best Choice#

Node.js is a dynamic, interpreted language. It is very fast compared to other dynamic languages thanks to the V8 JIT compiler. However, if you are looking for a language that can squeeze the most performance out of your computing resources, Node.js is not the best.

CPU-bound workloads can typically benefit from using a lower-level language like C, C++, Go, Java, or Rust. As an extreme example, when generating fibonacci numbers Rust and C are about three times faster than Node.js. If you have a specialized task that is particularly sensitive to performance, and does not need to be actively developed and maintained, consider using a lower-level level language.

Certain specialized software communities like machine learning, scientific computing, and data science have traditionally used languages other than JavaScript. Over time they have created many packages, code examples, tutorials, and books using languages like Python, R, and Java that either do not exist in JavaScript, are not at the same level of maturity, or do not have the same level of optimization and performance. Node.js might become more popular for these tasks in the future as more flagship projects like TensorFlow.js are developed. However, at this current time, fewer people in these disciplines have much Node.js experience.

Front-end Vs. Back-end JavaScript#

If you're more familiar with using JavaScript in the browser than you are with using it in Node.js, there a few differences worth paying attention to.

The biggest difference between Node.js and running JavaScript in the browser is the lack of globals and common browser APIs. For example, window and document are unavailable in Node.js. Of course, this should not be not surprising; Node.js does not need to maintain a DOM or other browser-related technologies to function. For a list of global objects that browsers and Node.js share, see MDN's list of Standard Built-in Objects.

Both Node.js and browser-based JavaScript can perform many of the same functions such as access the network or filesystem. However, the way these functions are accomplished will be different. For example, in the browser one will use the globally available fetch() API to create an HTTP request. In Node.js, this type of action would be done by first using const http = require('http') to load the built-in core http module, and afterwards using http.get('http://www.fullstack.io/', function (res) { ... }).

Diving In: Your First Node.js API#

We're going to start off by creating our own web server. At first, it will be very simple; you'll be able to open your browser and see some text. What makes this impressive is just how little code is required to make this happen.

Before moving forward, be sure that you have Node.js installed and ready to use. Visit the official Node.js Downloads Page to download the installer for your operating system. To be sure that everything is installed correctly, run node -v from your terminal and verify that you see your installed version number (e.g. v12.14.1).


This page is a preview of Fullstack Node.js

Start a new discussion. All notification go to the author.