Can We Use JavaScript Server-Side? Sure!

We don't typically think of JavaScript existing server-side, as the majority of its history has only been client-side in a browser. However, at the end of the day, JavaScript is a language—and languages can be agnostic to their application (to an extent). While it was possible to use JavaScript server-side since its beginning with a few different tools, the introduction of Node.js brought using JavaScript on the server-side into the mainstream. There are more similarities between Python and JavaScript here than on the frontend, but there are still significant differences between how each technology is used in practice. Let's take a look at Node.js and how we can leverage its power on the server-side—and why we would want to!

The following topics will be covered in this chapter:

• Why use JavaScript on the server-side...

Technical requirements

You can find the code files present in this chapter on GitHub at https://github.com/PacktPublishing/Hands-on-JavaScript-for-Python-Developers.

Why use JavaScript on the server side?

There are many server-side languages: Java, PHP, Ruby, Go, and our friend Python, just to name a few. So, why would we want to use JavaScript as a server-side language? One answer is to reduce context switching. In theory, the same developer can write both the front- and backend of a web application with a minimum of mental changes. The research behind the cost of switching programming languages is light so far and tends to be highly anecdotal, but some studies have shown that the cognitive overhead of switching from one task to another and back again reduces productivity and increases the length of time it takes to complete a task. By extension, switching from JavaScript to Python requires a few mental gymnastics. Of course, with practice, this mental overhead becomes unimportant (think of a translator who can in real time listen to one language and translate this to a different language). However, with the speed at which technology changes, reaching...

The Node.js ecosystem

Most languages aren't of the paradigm: of just writing self-contained code. Independent modules of code, called packages, are widely used in software engineering and development. To think of this in another way, even a fresh web server doesn't have software on it to serve a site out of the box. You have to install a package of software, such as Apache or nginx, to even get to the "Hello World!" step of a website. Node.js is no different. It has a number of tools to make the process of getting these packages simpler, though. Let's take a look from the ground up at a basic "Hello World!" example of a server using Node.js. We'll be discussing these concepts in more detail later, so, for now, let's just go through the basic setup.

Node.js

Of course, the first thing we need is access to the language itself. There are a few methods by which you can get Node.js on your machine, including package managers, but the most straightforward...

Threading and asynchronicity

As with traditional web architectures, it's important to understand the why of using Node.js on the backend.

We've taken a look at the how of running Node.js, so now, let's take a look at how Node's client-server architecture differs from the traditional paradigm.

Traditional client-server architecture

To understand how Node.js differs from traditional architectures, let's look at the following request diagram:

Figure 2.4 - Traditional client-server diagram

In a traditional setup, each request (or connection) to the server spawns a new thread in memory on the server, taking up system random-access memory (RAM) until the number of possible threads is reached. After that, some requests must wait until more memory is available. If you're not familiar with the concept of threads, they're basically a small sequence of commands to run on a computer. What this multithreaded paradigm implies is that for each new request received...

Summary

While the concept of running JavaScript on a server isn't new, its popularity, stability, and features are greatly expanded with Node.js. Early on, server-side JavaScript was abandoned but came to light again in 2009 with the creation of Node.js.

Node.js reduces the context-switching mental overhead for developers by working with the same fundamental grammar on both the client and server side. The same developer can work through the whole stack rather seamlessly because there are considerable similarities between the client-side work and how to operate with Node.js on the server. Along with a difference in approach also comes a different fundamental paradigm for handling requests to the server, compared to other more traditional implementations.

JavaScript: it's not just client-side anymore!

In the next chapter, we're going to take a deep dive into the grammar of JavaScript: syntax, semantics, and best practices.

Questions

Try your hand at answering the following questions to test your knowledge:

1. True or false: Node.js is single-threaded.
2. True or false: The architecture of Node.js makes it impervious to Distributed Denial of Service (DDoS) attacks.
3. Who originally created Node.js?
   1. Brendan Eich
   2. Linux Torvalds
   3. Ada Lovelace
   4. Ryan Dahl
4. True or false: JavaScript on the server side is inherently insecure because the code is exposed on the frontend.
5. True or false: Node.js is inherently superior to Python.

Further reading

Refer to the following links to get more information on this topic:

• Why The Hell Would I Use Node.js? A Case-by-Case Tutorial: https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js
• Event-driven architecture: https://en.wikipedia.org/wiki/Event-driven_architecture