11 02 2015
Why is Node.js so popular?
This is interesting because often a new kid on the tech block gets much attention from small businesses and startups (look at Rails) but here established brands shift services to a new technology and even replace existing stacks built in Java or Ruby with it.
Somehow there must be something special about- and good reasons to use it.
In this blog post I’ll summarize why it is my platform of choice but also discuss downsides, pitfalls and reasons not to use it.
Performance (non blocking I/O)
Node doesn’t need much server resources while providing great performance by using a single thread that executes your code and delegates input/output (I/O) tasks like database or file access to a thread pool.
This is a important asset for modern rich internet applications and high loads and I’ll explain this in more detail in another post soon but please have a look at the Node vs Java benchmarks PayPal did.
No boundaries – one stack to rule them all
If the backend coders are working with Ruby and the frontend crew is using Angular there will always be room for misunderstandings and tension because reasoning about code across language boundaries and technology stacks is hard.
So what if the frontend programmer could simply look into the backend code and instantly understand what it is doing?
And what if if you could even re-use code parts in every layer of the application?
This is possible with Node.
Large module ecosystem
Node.js has its own module repository along with a great package manager called npm.
At the time of writing there were over 124.000 packages available. While not all being super stable and well maintained many of them really are.
Great module loader and isolated scope
Nodes module loading mechanism (CommonJS) provides highly isolated scopes by exporting the whole logic of a module into a single variable. This makes code very easy to understand and you have to work hard to not structure your code into small reusable, orthogonal units.
Self contained projects
This is something I really love about node.
Using php I often had hard times deploying a project to a new server because it comes with a bunch of modules that may or may not be installed on the target host.
With node all modules needed by a project are distributed with it and in most cases you’ll get along with no dependencies to the underlying system. For instance: I develop on OS X and if I want to publish a project I simply copy it to a webserver and start it.
Having solid http support built in most node sites even act as their own webserver which is also a great asset for local development.
Cool and modern
Granted – this is no hard fact. But every good developer loves to improve and extend her knowledge and with Node you will enter a modern application stack that can deal with web sockets, NoSQL databases and spits out complicated datastructures as json to be seamlessly consumed by your shiny new AngularJS app.
So start using Node and all currently hyped technologies are at your fingertips
After all this praises let’s talk about things that may be a good reason not to use node.
It doesn’t support static types
Because no compiler will save you, testing is really crucial here. There are many good testing frameworks out there but you need to be disciplined and we alle know that writing proper tests is the first thing to get dumped when a deadline is near.
Especially for large projects with many developers involved you really have to put much effort into automated testing routines and coding standards and maybe you should think about still using a statically typed language like Java in the backend and let Node act as middleware to your frontend as the graphic below shows.
You have to care about memory leaks
If you’re doing php development this problem will be new to you, because every time you access a page the whole application is bootstraped. The only state php maintains is your session. After the page is flushed to the browser all resources and data structures you used will be freed (I’m leaving persistent database connections out here for simplicity).
Node is a completely different game.
It does all the bootstrapping when started the first time. Then it will indefinitely process new requests.
If you decide that you want to add an item to a global data structure for every request – maybe you wanted to store all users that connected since the last start – you have crafted a perfect memory leak that won’t be harmful with 10 users per day but will slightly eat up all your memory as soon as your app was featured on TechCrunch.
Callback hell and lines of code
Node is about asynchronous programming, so many operations take a callback as parameter that takes a callback as parameter that takes … this is called ‘callback hell’ and looks like this:
There are ways to flatten out things like that, but after all your will still need more lines of code to do things like a database query than in a traditional linear control flow
When using callbacks, it is also very easy to introduce hard to find errors like this one:
As you see by not returning or using an if/else construct both callbacks will be executed.
Maybe this is obvious to you but it happened to me several times with unpredictable side effects.
Everything is asynchronous – except your code
Your code will be executed synchronously in one single thread – only I/O calls will be handled asynchronously by Node and its event-loop machinery.
So for writing a web based prime number calculator Node is not the tool of choice because while the prime number calculation runs no other requests can be served. To understand that completely we have to discuss Nodes event loop mechanism – this will be the topic of my next post.
What comes next?
Next we will look under Nodes hood to fully understand how code is executed. Expect this post in a few days.
I hope this post was useful to some – feel free to comment or follow me on twitter @dkhan – thank you