In this article by Harry Cummings, author of the book Learning Node.js for .NET Developers For those with web development experience in .NET or Java, perhaps who’ve written some browser-based JavaScript in the past, it might not be obvious why anyone would want to take JavaScript beyond the browser and treat it as a general-purpose programming language. However, this is exactly what Node.js does.

What’s more, Node.js has been around for long enough now to have matured as a platform, and has sustained its impressive growth in popularity well beyond any period that could be attributed to initial hype over a new technology.

In this introductory article, we’ll look at why Node.js is a compelling technology worth learning more about, and address some of the common barriers and sources of confusion that developers encounter when learning Node.js and JavaScript.

(For more resources related to this topic, see here.)

Why use Node.js?

The execution model of Node.js follows that of JavaScript in the browser. This might not be an obvious choice for server-side development. In fact, these two use cases do have something important in common. User interface code is naturally event-driven (for example, binding event handlers to button clicks). Node.js makes this a virtue by applying an event-driven approach to server-side programming.

Stated formally, Node.js has a single-threaded, non-blocking, event-driven execution model. We’ll define each of these terms.

Non-blocking

Put simply, Node.js recognizes that many programmes spend most of their time waiting for other things to happen. For example, slow I/O operations such as disk access and network requests. Node.js addresses this by making these operations non-blocking. This means that program execution can continue while they happen.

This non-blocking approach is also called asynchronous programming. Of course, other platforms support this too (for example, C#’s async/await keywords and the Task Parallel Library). However, it is baked in to Node.js in a way that makes it simple and natural to use. Asynchronous API methods are all called in the same way: They all take a callback function to be invoked (“called back”) when the execution completes. This function is invoked with an optional error parameter and the result of the operation.

The consistency of calling non-blocking (asynchronous) API methods in Node.js carries through to its third-party libraries. This consistency makes it easy to build applications that are asynchronous throughout.

Other JavaScript libraries, such as bluebird (http://bluebirdjs.com/docs/getting-started.html), allow callback-based APIs to be adapted to other asynchronous patterns. As an alternative to callbacks, you may choose to use Promises (similar to Tasks in .NET or Futures in Java) or coroutines (similar to async methods in C#) within your own codebase. This allows you to streamline your code while retaining the benefits of consistent asynchronous APIs in Node.js and its third-party libraries.

Event-driven

The event-driven nature of Node.js describes how operations are scheduled. In typical procedural programming environments, a program has some entry point that executes a set of commands until completion or enters a loop to perform work on each iteration.

Node.js has a built-in event loop, which isn’t directly exposed to the developer. It is the job of the event loop to decide which piece of code to execute next. Typically, this will be some callback function that is ready to run in response to some other event. For example, a filesystem operation may have completed, a timeout may have expired, or a new network request may have arrived.

This built-in event loop simplifies asynchronous programming by providing a consistent approach and avoiding the need for applications to manage their own scheduling.

Single-threaded

The single-threaded nature of Node.js simply means that there is only one thread of execution in each process. Also, each piece of code is guaranteed to run to completion without being interrupted by other operations. This greatly simplifies development and makes programmes easier to reason about. It removes the possibility for a range of concurrency issues. For example, it is not necessary to synchronize/lock access to shared in-process state as it is in Java or .NET. A process can’t deadlock itself or create race conditions within its own code. Single-threaded programming is only feasible if the thread never gets blocked waiting for long-running work to complete. Thus, this simplified programming model is made possible by the non-blocking nature of Node.js.

Writing web applications

The flagship use case for Node.js is in building websites and web APIs. These are inherently event-driven as most or all processing takes place in response to HTTP requests. Also, many websites do little computational heavy-lifting of their own. They tend to perform a lot of I/O operations, for example:

• Streaming requests from the client
• Talking to a database locally or over the network
• Pulling in data from remote APIs over the network
• Reading files from disk to send back to the client

These factors make I/O operations a likely bottleneck for web applications. The non-blocking programming model of Node.js allows web applications to make the most of a single thread. As soon as any of these I/O operations starts, the thread is immediately free to pick up and start processing another request. Processing of each request continues via asynchronous callbacks when I/O operations complete. The processing thread is only kicking off and linking together these operations, never waiting for them to complete. This allows Node.js to handle a much higher rate of requests per thread than other runtime environments.

How does Node.js scale?

So, Node.js can handle many requests per thread, but what happens when we reach the limit of what one thread can handle? The answer is, of course, to use more threads!

You can achieve this by starting multiple Node.js processes, typically, one for each web server CPU core. Note that this is still quite different to most Java or .NET web applications. These typically use a pool of threads much larger than the number of cores, because threads are expected to spend much of their time being blocked.

The built-in Node.js cluster module makes it straightforward to spawn multiple Node.js processes. Tools such as PM2 (http://pm2.keymetrics.io/) and libraries such as throng (https://github.com/hunterloftis/throng) make it even easier to do so.

This approach gives us the best of all worlds:

• Using multiple threads makes the most of our available CPU power
• By having a single thread per core, we also save overheads from the operating system context-switching between threads
• Since the processes are independent and don’t share state directly, we retain the benefits of the single-threaded programming model discussed above
• By using long-running application processes (as with .NET or Java), we avoid the overhead of a process-per-request (as in PHP)

Do I really have to use JavaScript?

A lot of web developers new to Node.js will already have some experience of client-side JavaScript. This experience may not have been positive and might put you off using JavaScript elsewhere.

You do not have to use JavaScript to work with Node.js. TypeScript (http://www.typescriptlang.org/) and other compile-to-JavaScript languages exist as alternatives. However, I do recommend learning Node.js with JavaScript first. It will give you a clearer understanding of Node.js and simplify your tool chain. Once you have a project or two under your belt, you’ll be better placed to understand the pros and cons of other languages. In the meantime, you might be pleasantly surprised by the JavaScript development experience in Node.js.

There are three broad categories of prior JavaScript development experience that can lead to people having a negative impression of it. These are as follows:

• Experience from the late 90s and early 00s, prior to MV* frameworks like Angular/Knockout/Backbone/Ember, maybe even prior to jQuery. This is the pioneer phase of client-side web development.
• More recent experience within the much more mature JavaScript ecosystem, perhaps as a full-stack developer writing server-side and client-side code. The complexity of some frameworks (such as the MV* frameworks listed earlier), or the sheer amount of choice in general, can be overwhelming.
• Limited experience with JavaScript itself, but exposure to some its most unusual characteristics. This may lead to a jarring sensation as a result of encountering the language in surprising or unintuitive ways.

We’ll address groups of people affected by each type of experience in turn. But note that individuals might identify with more than one of these groups. I’m happy to admit that I’ve been a member of all three in the past.

The web pioneers

These developers have been burned by worked with client-side JavaScript in the past. The browser is sometimes described as a hostile environment for code to execute in. A single execution context shared by all code allows for some particularly nasty gotchas. For example, third-party code on the same page can create and modify global objects.

Node.js solves some of these issues on a fundamental level, and mitigates others where this isn’t possible. It’s JavaScript, so it’s still the case that everything is mutable. But the Node.js module system narrows the global scope, so libraries are less likely to step on each other’s toes. The conventions that Node.js establishes also make third-party libraries much more consistent. This makes the environment less hostile and more predictable.

The web pioneers will also have had to cope with the APIs available to JavaScript in the browser. Although these have improved over time as browsers and standards have matured, the earlier days of web development were more like the Wild West. Quirks and inconsistencies in fundamental APIs caused a lot of hard work and frustration. The rise of jQuery is a testament to the difficulty of working with the Document Object Model of old. The continued popularity of jQuery indicates that people still prefer to avoid working with these APIs directly.

Node.js addresses these issues quite thoroughly:

• First of all, by taking JavaScript out of the browser, the DOM and other APIs simply go away as they are no longer relevant.
• The new APIs that Node.js introduces are small, focused, and consistent.
• You no longer need to contend with inconsistencies between browsers. Everything you write will execute in the same JavaScript engine (V8).

The overwhelmed full-stack developers

Many of the frontend JavaScript frameworks provide a lot of power, but come with a great deal of complexity. For example, AngularJS has a steep learning curve, is quite opinionated about application structure, and has quite a few gotchas or things you just need to know.

JavaScript itself is actually a language with a very small surface area. This provides a blank canvas for Node.js to provide a small number of consistent APIs (as described in the previous section). Although there’s still plenty to learn in total, you can focus on just the things you need without getting tripped up by areas you’re not yet familiar with.

It’s still true that there’s a lot of choice and that this can be bewildering. For example, there are many competing test frameworks for JavaScript. The trend towards smaller, more composable packages in the Node.js ecosystem—while generally a good thing—can mean more research, more decisions, and fewer batteries-included frameworks that do everything out of the box. On balance though, this makes it easier to move at your own pace and understand everything that you’re pulling into your application.

The JavaScript dabblers

It’s easy to have a poor impression of JavaScript if you’ve only worked with it occasionally and never as the primary (or even secondary) language on a project.

JavaScript doesn’t do itself any favors here, with a few glaring gotchas that most people will encounter. For example, the fundamentally broken == equality operator and other symptoms of type coercion. Although these make a poor first impression, they aren’t really indicative of the experience of working with JavaScript more regularly.

As mentioned in the previous section, JavaScript itself is actually a very small language. Its simplicity limits the number of gotchas there can be. While there are a few things you “just need to know”, it’s a short list. This compares well against the languages that offer a constant stream of nasty surprises (for example, PHP’s notoriously inconsistent built-in functions).

What’s more, successive ECMAScript standards have done a lot to clean up the JavaScript language. With Node.js, you get to take advantage of this, as all your code will run on the V8 engine, which implements the latest ES2015 standard.

The other big that reason JavaScript can be jarring is more a matter of context than an inherent flaw. It looks superficially similar to the other languages with a C-like syntax, like Java and C#. The similarity to Java was intentional when JavaScript was created, but it’s unfortunate. JavaScript’s programming model is quite different to other object-oriented languages like Java or C#. This can be confusing or frustrating, when its syntax suggests that it may work in roughly the same way. This is especially true of object-oriented programming in JavaScript, as we’ll discuss shortly. Once you’ve understood the fundamentals of JavaScript though, it’s very easy to work productively with it.

Working with JavaScript

I’m not going to argue that JavaScript is the perfect language. But I do think many of the factors that lead to people having a bad impression of JavaScript are not down to the language itself. Importantly, many factors simply don’t apply when you take JavaScript out of the browser environment.

What’s more, JavaScript has some really great extrinsic properties. These are things that aren’t visible in the code, but have an effect on what it’s like to work with the language. For example, JavaScript’s interpreted nature makes it easy to set up automated tests to run continuously and provide near-instant feedback on your code changes.

How does inheritance work in JavaScript?

When introducing object-oriented programming, we usually talk about classes and inheritance. Java, C# and numerous other languages take a very similar approach to these concepts. JavaScript is quite unusual in that; it supports object-oriented programming without classes. It does this by applying the concept of inheritance directly to objects.

Anything that is not one of JavaScript’s built-in primitives (strings, number, null, and so on) is an object. Functions are just a special type of object that can be invoked with arguments. Arrays are a special type of object with list-like behavior. All objects (including these two special types) can have properties, which are just names with a value. You can think of JavaScript objects as a dictionary with string keys and object values.

Programming without classes

Let’s say you have a chart with a very large number of data points. These points may be represented by objects that have some common behavior. In C# or Java, you might create a Point class. In JavaScript, you could implement points like this:

function create Point(x, y) {

    return {

        x: x,

        y: y,

        isAboveDiagonal: function() {

            return this.y > this.x;

        }

    };

}

 

var myPoint = createPoint(1, 2);

console.log(myPoint.isAboveDiagonal()); // Prints "true"

The createPoint function returns a new object each time it is called (the object is defined using JavaScript’s object-literal notation, which is the basis for JSON). One problem with this approach is that the function assigned to the isAboveDiagonal property is redefined for each point on the graph, thus taking up more space in memory.

You can address this using prototypal inheritance. Although JavaScript doesn’t have classes, objects can inherit from other objects. Each object has a prototype. If the interpreter attempts to access a property on an object and that property doesn’t exist, it will look for a property with the same name on the object’s prototype instead. If the property doesn’t exist there, it will check the prototype’s prototype, and so on. The prototype chain will end with the built-in Object.prototype.

You can implement point objects using a prototype as follows:

var pointPrototype = {

    isAboveDiagonal: function() {

        return this.y > this.x;

    }

};

 

function createPoint(x, y) {

    var newPoint = Object.create(pointPrototype);

    newPoint.x = x;

    newPoint.y = y;

    return newPoint;

}

 

var myPoint = createPoint(1, 2);

console.log(myPoint.isAboveDiagonal()); // Prints "true"

The Object.create method creates a new object with a specified prototype. The isAboveDiagonal method now only exists once in memory on the pointPrototype object. When the code tries to call isAboveDiagonal on an individual point object, it is not present, but it is found on the prototype instead.

Note that the preceding example tells us something important about the behavior of the this keyword in JavaScript. It actually refers to the object that the current function was called on, rather than the object it was defined on.

Creating objects with the ‘new’ keyword

You can rewrite the previous code example in a more compact form using the new operator:

function Point(x, y) {

    this.x = x;

    this.y = y;

}

 

Point.prototype.isAboveDiagonal = function() {

    return this.y > this.x;

}

 

var myPoint = new Point(1, 2);

By convention, functions have a property named prototype, which defaults to an empty object. Using the new operator with the Point function creates an object that inherits from Point.prototype and applies the Point function to the newly created object.

Programming with classes

Although JavaScript doesn’t fundamentally have classes, ES2015 introduces a new class keyword. This makes it possible to implement shared behavior and inheritance in a way that may be more familiar compared to other object-oriented languages.

The equivalent of the previous code example would look like the following:

class Point {

    constructor(x, y) {

        this.x = x;

        this.y = y;

    }

   

    isAboveDiagonal() {

        return this.y > this.x;

    }

}

 

var myPoint = new Point(1, 2);

Note that this really is equivalent to the previous example. The class keyword is just syntactic sugar for setting up the prototype-based inheritance already discussed.

Once you know how to define objects and classes, you can start to structure the rest of your application.

How do I structure Node.js applications?

In C# and Java, the static structure of an application is defined by namespaces or packages (respectively) and static types. An application’s run-time structure (that is, the set of objects created in memory) is typically bootstrapped using a dependency injection (DI) container. Examples of DI containers include NInject, Autofac and Unity in .NET, or Spring, Guice and Dagger in Java. These frameworks provide features like declarative configuration and autowiring of dependencies.

Since JavaScript is a dynamic, interpreted language, it has no inherent static application structure. Indeed, in the browser, all the scripts loaded into a page run one after the other in the same global context. The Node.js module system allows you to structure your application into files and directories and provides a mechanism for importing functionality from one file into another.

There are DI containers available for JavaScript, but they are less commonly used. It is more common to pass around dependencies explicitly. The Node.js module system and JavaScript’s dynamic typing makes this approach more natural. You don’t need to add a lot of fields and constructors/properties to set up dependencies. You can just wrap modules in an initialization function that takes dependencies as parameters.

The following very simple example illustrates the Node.js module system, and shows how to inject dependencies via a factory function:

We add the following code under /src/greeter.js:

module.exports = function(writer) {

    return {

        greet: function() { writer.write('Hello World!'); }

    }

};

We add the following code under /src/main.js:

var consoleWriter = {

    write: function(string) { console.log(string); }

};

var greeter = require('./greeter.js')(consoleWriter);

greeter.greet();

In the Node.js module system, each file establishes a new module with its own global scope. Within this scope, Node.js provides the module object for the current module to export its functionality, and the require function for importing other modules.

If you run the previous example (using node main.js), the Node.js runtime will load the greeter module as a result of the main module’s call to the require function. The greeter module assigns a value to the exports property of the module object. This becomes the return value of the require call back in the main module. In this case, the greeter module exports a single object, which is a factory function that takes a dependency.

Summary

In this article, we have:

• Understood the Node.js programming model and its use in web applications
• Described how Node.js web applications can scale
• Discussed the suitability of JavaScript as a programming language
• Illustrated how object-oriented programming works in JavaScript
• Seen how dependency injection works with the Node.js module system

Hopefully this article has given you some insight into why Node.js is a compelling technology, and made you better prepared to learn more about writing server-side applications with JavaScript and Node.js.

Resources for Article:

---

Further resources on this subject:

• Web Components [article]
• Implementing a Log-in screen using Ext JS [article]
• Arrays [article]

---