Node.js, JavaScript on the server side

Node.js, JavaScript on the server side

David WORMS

By David WORMS

Jun 12, 2010

Categories
Front End
Node.js
Tags
HTTP
Server
JavaScript
Node.js
[more]
Do you like our work......we hire!

Never miss our publications about Open Source, big data and distributed systems, low frequency of one email every two months.

Waiting for the Next Big Language (NBL for Next Big Language), this is now 3 years or more since I predict to my customers a bright future for JavaScript as a programming language for server applications. My argument was based primarily on its aesthetics, simplicity and dynamic nature. Designed in 1995 by Sun Microsystems (acquired by Oracle) and Netscape (bought by AOL), its integration into Internet browsers has widely spread the language but it is only from around 2004 through the AJAX generation and web applications such as Gmail and Google Maps that the language received its nobility title and gained the attention of professionals.

Despite some unsuccessful efforts, its use was confined to Frontend, meaning web browsers in which it can animate web pages. In recent years, solutions have appeared in the Open Source community. I am thinking in particular of Helma, operating within a Java virtual machine and therefore easily integrable with the wider Java ecosystem, but also with more innovative solutions like Jaxer, whose peculiarity is to create a browser-like environment (like DOM manipulation) ) on the server. Of all, it is probably Narwhal which left me the strongest impression by its simple architecture and the modularity of the JavaScript interpreter.

In recent years, I have been closely following news about server solutions, testing each one of them and analyzing their approaches. Regarding the traffic generated by each article covering the subject, I realized on this occasion that I was not isolated. But none of the projects was able to convince me to give up that bad guy that PHP is. Until a few months ago with the appearance of NodeJs.

Let’s go back a bit. The AJAX mark the importance and the need for performance inside web browsers and the JavaScript interpreter is an essential data for so-called Rich Internet Applications (RIA). The Mozilla and Microsoft editors joined by Apple with Safari and more recently Google with Chrome have embarked on a race for optimization. This healthy competition gave birth to new generations of interpreters such as TraceMonkey for Firefox 3.6, SquirrelFish for Safari 5, Carakan for Opera and V8 for Chrome. For a long time lagging behind, even Microsoft is gambling with version 9 of Internet Explorer. Today, JavaScript is without a doubt the language that focuses the bulk of development efforts.

But there is another reason why JavaScript is fast and an excellent server-side choice. By nature, it is an event-oriented language as opposed to thread-oriented servers. This feature of the language comes from its origins where it was intended to work inside Internet browsers and it was essential to support user events without saturating the entire browser with each action. Traditionally, server applications are written in a so-called blocking thread mode. This is the case for PHP and CGI applications and most Python, Ruby or Java applications.

I will try to be as clear as possible. When a server receives a request, for example sending a form, the server makes a thread available and starts the application that performs its operations one after the other (connection to a database to validate the name and password of the user, write to a log file, …) before finally returning the response to the form and closing the thread. But the number of threads is limited and these applications quickly generate errors when they arrive at saturation of the memory. Each thread is monopolized until the end of all operations. These operations like writing a file take a lot of time compared to the speed of a CPU and it’s just a waste. For applications with high traffic volumes, each request must be coded to be as short as possible. On the other hand, in an event environment, these same operations are called non-blocking because, while waiting to query on a database or write to a file, the server can continue to perform other tasks in the same thread.

The absence of a non-blocking alternative can even become a no-go for certain scenarios such as the downloading of large files, the grouping of results from several backends and, not least, the support of the Bayeux protocol (Comet) opening the road to HTTP push.

Starting from the assumption that most of the time server applications is spent waiting for the results of I/O operations (network access to databases, reading and writing on the file system, …), event programming is particularly adapted to the server environment. Twisted in Python and EventMachine in Ruby provide answers to this problem but none benefits from the strength of a language integrating these functionalities natively.

Let’s go back to Node. Described by its author as an excellent foundation for developing web applications, it is based on the V8 JavaScript engine developed, used and open-sourced by Google for its Chrome browser. It is one of the fastest on the market (not to say the fastest) and improves with each new version. Everything in the development of Node is built and optimized in an event optics which considerably reduces the possibilities of writing a slow applications because calling on blocking I/O operations. Quickly, the Open Source community has recognized the potential of this platform and a rich ecosystem is built around including drivers (CouchDB, MongoDB, Redis, …), libraries (Haml, Sass, Expresso, …) and frameworks (Connect , Express, …).

On behalf of a client, I have prototyped an application and the handling is fast, simple and intuitive. The code is elegant, short and legible. All I expected were server-side JavaScript promises. For the realization of the proto and despite the youth of the ecosystem, I had to miss nothing. Seeing this allowed me to use concepts borrowed from the Ruby and Python universes that are lacking in PHP (a particular thought for SASS). For those familiar with developing JavaScript-rich client applications, the transition will be almost instantaneous.

To summarize Node.js in a few sentences:

  • JavaScript is made for events: callback programming is familiar to AJAX application developers and, to do so, the syntax of anonymous functions and closures support is adapted and elegant.
  • Node is built on Javascript: by its presence in browsers, it is perhaps the most programmed language in the world and has 15 years of experience.
  • Node stabilizes: the API matures and is close to finalizing.
  • Node has an ecosystem: many libraries are available, all in open source, news appear and all share a good quality of realization.
  • Node is simple and small: the documentation is at a glance and allows to quickly know its features.
  • Node is fast: the V8 engine and non-blocking architecture make it one of the most powerful architectures on the market, especially for long and intensive IO requests.
Share this article

Canada - Morocco - France

We are a team of Open Source enthusiasts doing consulting in Big Data, Cloud, DevOps, Data Engineering, Data Science…

We provide our customers with accurate insights on how to leverage technologies to convert their use cases to projects in production, how to reduce their costs and increase the time to market.

If you enjoy reading our publications and have an interest in what we do, contact us and we will be thrilled to cooperate with you.

Support Ukrain