The Strengths and Weaknesses of Node JS In a Nutshell
by Ben Shirk
Node.js is a relatively new programming platform (2009) that is becoming increasingly popular. In fact, it has recently been picked up and implemented by some major name-brand companies such as Dow Jones, PayPal, LinkedIn and The New York Times. Additionally, Node is getting a significant amount of positive feedback in a number of different areas. For instance, it is often reported to be fast and flexible while scaling to millions of online users. It seems to be well suited for building mobile applications. It unifies JavaScript on both the client and server. And finally, it has a very active user community supporting it.
So why not rush out today and start building your next killer application with Node? Well, it's quite possible that this is not a terrible idea, but before you jump in headfirst it's worth taking a moment to understand the areas where Node really shines as well as where it does not. First let's discuss the situations where it shines.
In a nutshell, Node.js is great at handling tasks that involve real-time, network input-output (I/O). This is its bread-and-butter scenario. At its core Node was designed to be a highly scalable network platform with the intent of solving a few specific challenges. In particular it does very well at handling multi-user environments with very high numbers of concurrent connections.
The classic example of an application that leverages the strengths that Node has to offer is the multi-user chat application. This type of application is network based and involves potentially thousands, if not millions, of simultaneous connections. Moreover, it utilizes the push-pull, two-way communications capabilities that Node.js offers. It's quite possible that true two-way communications is nothing short of a complete game changer in terms of the way applications are built. Let's take a quick look at why this is the case.
Before Node.js came onto the scene, applications were restricted to a one-way communications paradigm inherent in the Hypertext Transfer Protocol (HTTP), the dominant protocol of the web. In this paradigm, the client always initiates communications with the server, thereby making a pull request. In contrast, it was not possible for the server to push information to the client. This fact was a major limitation in the way applications worked, and this is one of the primary challenges that the creator of Node was trying to solve. With Node, it is now finally possible to have true two-way communications between client and server, with the client initiating communications and pulling information from the server, and the server initiating communications and pushing information to the client.
These then are some of the main strengths of Node.js. However, while Node is good at a number of things including those just discussed here, it is also true that it was not intended to solve every problem. In particular Node is not very good at performing tasks that involve a high degree of raw computation or number crunching. Node applications are single-threaded, which is perfectly fine for handling network and I/O tasks where its asynchronous nature can be put to good use. However, if a section of Node.js application code winds up performing a task that involves heavy computation, this will have the effect of tying up the single thread, which in turn will prevent other events from getting the attention they need. This dramatically decreases the responsive characteristics that make Node so powerful. As such, this kind of use case should be avoided.
In conclusion, Node.js is great at real-time, network applications involving a high degree of concurrency within a multi-user environment. In contrast, it is not so great at pure number crunching. So if your next killer application does not involve a ton of number crunching, you might want to take a serious look at Node.js.
No comments:
Post a Comment