I have to write a lot of scripts. A lot of scripts. Oftentimes this is because there are a lot of tasks that are too complex to do by hand, or too massive to be done by hand. So I turn to writing scripts for everything that takes too long. It reduces errors and increases performance. As my peers hate me for always saying;

If you do it more than once, write a script.

Some common tasks are:

• find matches or x, y, z in these giant arrays.
• remove all instances of this value, but only under these conditions.
• compare x and y and then output z.

And I know most programmers are thinking how well Python or even C# or Go would be suited to these tasks, but there are three key reasons why I always choose NodeJS.

It is not I/O blocking

By default, NodeJS can read a file, parse the content into the database, and write new content to the file, without even thinking about it. While there are libraries for Python and similar to add asynchronous abilities, by default Python is not asynchronous, one function must always execute before the next function can occur.

NodeJS doesn’t suffer from this problem, as it is designed to handle requests flowing constantly from web traffic, and also designed to handle everything in the background (file serving, mail etc).

This makes it perfect for my kind of tasks — I often extract the information I’m after, and store it in a database for later recall. I do this to both persist my data, and to free up memory by not having to hold the entire array. I can then be calling information back from the database, manipulating it and altering it, all the while it is running away in the background, storing more information in the database.

I/O requests are also handled on a separate thread in NodeJS from the main thread of execution. What this means, is that a particularly large or troublesome file being read in will not hinder the performance of the main program (providing the content of the file is not immediately necessary of course).

It takes care of itself

When writing a throwaway script that I will only use a handful of times, optimising that code isn’t necessarily high on my priority list. The priority is to get it written, and get it running. That’s where the V8 (C++) engine that NodeJS is compiled into throws you a bone.

When you have no choice but to call arrays into memory and manipulate them, sometimes very very large arrays, you can begin to worry about the state of your machine and the amount of memory that is being used. Luckily, V8 handles automatic garbage collection.

What this means is that whenever I have disregarded a block of information, say removed an index from an array, then that memory is automatically cleared and freed back up on the next sweep. While the process of collection and actually checking can be a bit intensive, it means when I am quickly iterating through code I don’t need to pay a tremendous amount of attention to my memory management, and I can entrust V8 to handle all the little nuances.

Oh, you want interactive results?

One of the main reasons why NodeJS was built was to serve websites (to put it very simply). So when I have to show or share the results of my scripts, such as giving others the option to view the output and even change the parameters of a script, I can do so by invoking the true purpose of NodeJS.

The ease of serving my results directly on a server using a templating language in NodeJS is something I feel I take for granted. The template I tend to use is EJS because, like the script itself, it’s straight to the point. It has a job, and it will do it well.

Now I know other scripting languages can serve web pages and I know it doesn’t take substantially more energy to do than it is does in say, Python, but there is a certain majesty in being able to write the (intensive) script and serve it all on the same execution, without ever having to leave the NodeJS ecosystem.