node.js‘s popularity isn’t without it’s reasons. node.js is lightweight, it’s mature and it has enough packages in the npm repository to make you start wondering if you’ll ever learn enough tools to become a half decent developer.

If you know JavaScript, you just need to know a bit about the node.js event loop and the node.js standard library and maybe express and you’re pretty much a decent node.js developer.

But it’s definitely not without it’s drawbacks.

Problems with node.js

1. Everything Is Async

The fact that any io operation is async may be a good thing – but wait… now, I have Promise everywhere. I find this as a small annoyance than an issue, but it adds up and takes just that bit more precious cognitive effort to understand the sequence of execution.

Maybe async and await in ES2017 or if you’re using TypeScript now, then this might get better.

I find however, that async await has it’s own issues.

For example:

async await

var result1 = await getSomeResult()
var result2 = await getSomeOtherResult(result1) 
return await getFinalResult(result2)


return getSomeResult()

With async await, You’ve now just made your code longer, harder to comprehend, and you’ve had to create a bunch of temp variables to make your code more readable as opposed to the Promise alternative.

2. First-class Functions

Support for first-class function is great!! I’m a great advocate of functional programming, but this has it’s drawbacks. Functional programming has its merits, and if used wisely, it works amazingly well, but going function crazy can cause some issues. Object-Oriented Programming as an abstraction has worked well, and it still does.

The amount of time it takes to comprehend how a function is composed using other functions can sometimes be nigh-impossible. Instead of seeing a clear separation of what you’re looking at does by its method name, you now have to work out what the function composition is to understand what it does.

I find a good balance of OO and FP to be the most effective way of getting the benefits of both without too much of the downsides.

3. Common Practices

Related to point 2, node.js doesn’t really have any common best practices as such, so you’re left to try and understand the reasoning behind the varying designs and how to do certain things such as mocking for tests, how to change behaviour etc.

4. Debugging Experience

Debugging experience in node.js reminds me of the days of debugging in PHP when xdebug was first introduced. The amount of setup involved if the project isn’t yet setup for debugging can range from mildly annoying to “OMG, can I just rewrite to whole solution” kind of situation. Once you’re all set, you’re as happy as someone who just got a promotion with a title “CTO/Next Steve Jobs/Second Coming” with a 7 figure salary, which sadly has yet to happen to me.

5. Everything Is Moving Faster Than You

The fact that JavaScript in general is moving quite quickly is great for a lot of us. This can only mean more innovation, everything is going to just get better and better, there is a lot of support etc.

The main issue with this though, is that if you leave your code for half a year, and you try to update all the packages you’re currently using, it’s more likely than not that your application is going to break. The cost of upgrading can be quite big, but also essential to get all sorts of issues fixed, whether it be minor bugs and major security wholes that you absolutely have to have.

So when does node.js work well?

Web front-end applications. I’ve actually not yet managed to find any other sane way of creating manageable SPA that’s highly dynamic, feature-rich FE applications without node.js. Although, I would argue, a lot of Front-end don’t really need to be that dynamic SPA‘s – most stuff that you see on the web can be done just fine in good ol’ javascript enhancement in a plain ol’ html + css.

node.js also works great for fake API’s and simple proxy applications for development and testing if you’re using Docker.