This is not a lecture about javascript. It has served us well in the browser over the years, and it has also served us well on the server.
With the wide use of javascript, it’s understandable that many people use it to construct their backends.
Why JavaScript is bad for server-side programming
CPU
The most significant disadvantage with javascript on the server is that it is single-threaded. This means it cannot evenly distribute the workload over the server’s cores.
To get javascript to use more bodies, you will need to manually transfer some work out to the workers; but, getting this to be as efficient as other platforms is hard.
The second and most usual approach is to launch multiple instances of your program, letting the operating system schedule your work on a separate core from the one on which your other instances are working. In general, you should start as many instances as there are cores in your system, so that you may use all of your CPU.
Web developers using Rust, Go, or.net do not need to worry about this because the chosen async runtime will handle it for them.
Memory
Another disadvantage that you may not be aware of is that V8 (the javascript engine that runs node) has a heap size limit of 2Gb/4Gb (differs between versions).
No matter how much RAM you have in your pc, if you hit this heap size use, your program will crash. This might be terrible if the crash is due to excessive usage rather than a memory leak.
To counter this, set the max-old-space-size setting on your node process to a value fit for your server.
There is no hidden program crashing memory limit in Rust, Go, or .NET, so developers don’t have to worry about this.
Performance
We’ve come to a point where the performance of javascript can be pretty fantastic thanks to years of competition to create the fastest browser. But, it is not guaranteed to be running at peak performance.
Javascript, you see, has two problems: first, it needs to have a fast “start from source”-time, and second, it needs to be able to perform the real application logic quickly.
This is addressed via a multi-step compilation process in which the first pass just gets the code up and running without spending much effort on optimizations.
When the program has been running for a while, V8 will judge where it is worth spending time optimizing and will send the work to its optimizing compiler.
This is usually good since, after your node process has started up, it becomes optimized, and servers have historically been long-running processes.
So far, things have changed in the age of serverless computing.
When code starts up, it only performs one run of the code; this is not ideal for the V8 engine because it never has a chance to apply its optimizations. That being said, it would be much worse if it did do its improvements, as it would mean it used a lot of CPU cycles to optimize something that would be destroyed moments later.
A Rust developer does not have to worry about this as the optimization happens at compile time, and the application runs at peak performance from the start.
I hope you found this useful and is always appreciated; thank you!
Watch the following video for some added context:
Also published here.