Waiting for the Next Big Language (
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
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
Let’s go back a bit. The
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.
To summarize Node.js in a few sentences:
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 I / O requests.