Around IT in 256 seconds

#45: Node.js: running JavaScript on the server (!)

June 22, 2021 | 3 Minute Read

JavaScript language is primarily used inside your web browser. Your computer downloads a JavaScript file and executes it on your machine. But if you want to build a dynamic website, you need a server-side language. Like PHP, Java, Python, etc. Programs written in these languages handle incoming requests and produce dynamic HTML. HTML that varies, depending on the request, who is asking and what data is available in the underlying database. But for more than a decade we can also use JavaScript on the server. The same language can be used for a very different purpose. Namely, listening and handling web requests. But also implementing command-line utilities and one-off scripts. This became possible after extracting the JavaScript engine from Chrome browser.

But first things first. A JavaScript engine is a piece of every web browser, responsible for running JavaScript. It’s actually a fairly complex language, so understanding it and running it fast is quite challenging. Turns out you can take Google Chrome’s JavaScript engine out and run it standalone, without Chrome! Google’s engine is called V8 and is the foundation of a project called Node.js. Node can run JavaScript code without a browser. Together with a bunch of libraries we can easily build HTTP server and much more. Clients don’t really knopw they are running JavaScript. All they see is request and response. It could just as well be Python or Ruby on Rails. OK, so why not use them in the first place?

Well, JavaScript is so pervasive and rather easy to learn at first that running it on the server was a quick win. Especially for web developers, already familiar with the language. But more importantly, Node.js has some really neat performance tricks under the hood. As a matter of fact, it was built out of frustration that traditional web frameworks are so slow and not scalable. OK, JavaScript is probably the last language to use when we are chasing performance. Yet, Node.js delivered its promises. It’s especially surprising knowing that JavaScript is inherently single-threaded!

How’s all that possible? Well, in Node.js virtually any long-running code is asynchronous. For example, loading a file, making an HTTP request or database query. All such operations are callback-based. When the result is ready, our code is notified. In the meantime, CPU is free to handle other requests. Modern CPUs are faster than I/O by several order of magnitude. So you can easily handle tens of thousands of concurrent requests in Node.js. On a single core! That’s way better than traditional Python, PHP or .NET web frameworks. They wait for pretty much any I/O, consuming precious memory.

To be honest, in Node.js you can’t even use more than one core. So it’s not a good choice for CPU-intensive applications. But most of the applications these days spent the majority of their time… waiting. Waiting for a database or other services. So this design choice seems to pay off.

I mentioned briefly about libraries. There are millions of them! Before Node.js there was no central repository for JavaScript libraries. Now we have npm, node package manager. It hosts packages along with their dependencies. Node community is known for creating tiny libraries with a large number of dependencies. This ecosystem is quite brittle and vulnerable. But it also enabled thousands of developers to share their code.

That’s it, thanks for listening, bye!

More materials

Tags: chrome, javascript, node_modules, nodejs, npm, php, python, ruby-on-rails, v8

Be the first to listen to new episodes!

To get exclusive content: