Node.js (or Node to its friends) isn’t new. The project started in mid-2009 and I first heard of it early in 2010. At that point the idea of running JavaScript on a server was a bit of a novelty to me, having recently started working on server software after years of ActionScript (JavaScript’s sibling that powers Adobe Flash). So new was it that it was only available to build from source code – prebuilt binaries were some time away, as was Windows support – but even in its rough, early state I could see potential. Google Chrome was the new browser on the block and brought with it a blazingly fast JavaScript engine in the form of V8; coupling this with some neat server hardware looked like it could result in stupidly powerful code that I felt at home with.

For me, this was followed by four years of programming in PHP for server software. People don’t choose PHP for its elegance or performance, but for its ubiquity and maturity – indeed, it was these features that made me decide to learn it. But what if it didn’t have to be like that – what if we could kick PHP to one side and see how something a bit more… ‘interesting’, perhaps?… see how something more interesting could perform.

Enter Node

Recently Node has started making its presence known in the server rooms of some big players. ‘Non-tech’ companies like Walmart and the Daily Mail are pushing masses of data through Node as part of their daily business, and Microsoft now supports it as part of their Azure cloud services and through Visual Studio. I happened to have some time between projects and decided that, if these companies were willing to invest time and money in Node, they clearly considered it stable and mature. So I decided to reproduce something I had just done for a project in PHP as completely as possible in Node. The project happened to be an API, which I’d heard was Node’s forte, so I selected an endpoint and started coding one Thursday afternoon.

Amazingly, I had a comparable API endpoint, together with a documentation page, working by the end of the day. More than that, I understood completely how it worked (which, when you work with large PHP frameworks, rarely happens – there’s always a layer of ‘magic’ that ‘just works’). It was written in a language that I felt at home with, in a logical way.

Best of all, the endpoint I’d just written in Node outperformed the PHP ‘master’. Massively. On identical hardware I was consistently seeing a response time of 28ms instead of 150-180ms.

Real World

Fired up by the ease of development, which was an absolute joy, and the insane performance, I decided to spend a bit more time researching Node. In particular, I wanted to know how best to deploy a Node application for the real world, away from my Mac.

I quickly found advice on ‘hardening’ Node – using the (excellent) web server Nginx as a proxy and load balancer, which lets you deal with otherwise tricky situations like SSL security, caching and serving static content through a package that does this day in, day out. I also found how to ensure that an application stays up and running – unlike PHP, Node is a single process running continuously, so if there’s a problem with your code you can effectively bring down your server. Finally, something that should help reduce the chances of bringing down your server – testing frameworks. There’s several to choose from, such as Mocha and Jasmine, which cover both functional and unit testing, and the simple syntax shared among them makes the tests readable and comprehensible.


Naturally there’s going to be drawbacks to using Node, and I’ve touched on two already – a lack of ubiquity and maturity. With it being less mature than something longer in the tooth – PHP is now about 19 years old and Rails about 10 – features haven’t really plateaued. Things are still being added and features tweaked, although to a far lesser extent than in the past few years.

This rapid development means that packages available in official repositories for Linux distros can be pretty stale, and lacking critical fixes. This is a problem for lots of bleeding-edge software and there’s generally a way around things – there are often unofficial channels that hold the packages for people willing to trust them, and that’s certainly true for the big Linux distros. In a production environment though, security is going to trump convenience – I know I wouldn’t be prepared to allow a client’s server to be pulling in packages from who knows where.

It’s not all doom and gloom though. A lot has changed since my first experiences, and the Node project has binaries for the most common architectures ready and waiting to be downloaded. Fetching these could easily be incorporated into deployment scripts, sidestepping the official distro versions.

To be honest, from a development point of view, the biggest problem for Node isn’t anything to do with software. There’s a vibrant developer community pushing the boundaries of what can be achieved, and a community is essential for anything to gain traction. The biggest problem I can sense comes from in-fighting at the top of the tree between various interested parties, the politics of which bubble under, sometimes threatening to splinter the community as what would be a petty “he-said-she-said” disagreement spills out of control. There’s also the fact that Node has gotten quite big very quickly, and there’s a sense that the powers that be make decisions that a larger or more experienced team might handle slightly differently – such as rolling out a critical release on a Friday afternoon or invalidating security certificates used by the package manager, in both cases with no prior warning. Fortunately it seems that the most recent of these chastened the team enough to avoid making that mistake again.


So in conclusion, is Node worth using? In short: yes. With caveats.

Node is absolutely perfect for some sorts of projects – such as the API example I did. I’m not sure I’d want to use it for a full CMS, though – not because it couldn’t be done, but because there are better matches for this style of project. Its comparative youth shouldn’t go against it, as the community that has sprung up around it is, frankly, brilliant. The issues within the Node project themselves are occasionally annoying, but they’re more an issue during development than once deployed, and any developer with an ounce of sense will be able to find fixes and workarounds armed only with Google and Twitter Search, such is the way the community supports itself. The underlying technology is extremely impressive and, with the attention being given to it from the likes of Facebook, Yahoo and Microsoft, will only get better.

For me personally, Node has become my development tool of choice. It’s now installed on my gaggle of Raspberry Pis, laptops and server, and is likely to be the first stop for any of my own projects. Professionally, it complements PHP and Ruby on Rails well and should certainly be up for consideration on all future projects.

About the author

Steve Anderson

Steve Anderson

Steve has been programming computers since the mid-1980s and has spent the last four years principally in web development. Outside of Box UK Steve is also a hardware hacker, and has accidentally become a consultant for "Internet of Things" research and development as a result of his interest in this field.



May 21st, 2014

I too used Node quite a while ago and was fairly impressed. Haven’t touched it since then though, I may consider giving it another go.


Jul 20th, 2014

I agree with most of what you write but the fact that writing the smallest of code snippet just feels “backwards” with all callbacks that needs to be there, is a warning signal to me. When you find yourself spending three hours on making a call to redis with a fallback to mysql, something that takes about a minute to do in any other language, you just know that either you are doing something extremely wrong or the language isn’t really there yet. Mentioning this to ppl that have been “touched” by Node is like cursing in church, of course. They start shouting about promises (Q etc) and the likes of it. My feeling is still that if you need something like Q to make an asynchronous network behave in synchronous, then maybe the idea of having it async in the first place wasn’t that great. Thoughts?

Steve Anderson

Jul 21st, 2014

I’m probably not the best person to comment about these things due to the way I headed towards Node, not from server software but from client software. ActionScript remains my favourite programming language to date (despite not having touched it for about four years), and the synchronicity of animation in Flash resulted in me being quite used to queues and callbacks to line up behaviour in the way that I needed. As a result my opinion is quite tainted – promises and callback feel like a natural thing to me due to my background.

Dave Laursen

Jul 21st, 2014

I’ve used Node quite a bit over the past year and a half and I really enjoyed it, but I’ve recently switched to Google’s Go language ( and I have no intention of switching back. Go has the Node’s strengths – i.e. concise syntax, built-in support for creating containerless web servers, functional language features (closures, anonymous functions, ), good community. But it also has many of the strengths of a static language – i.e. compile-time checking, built-in concurrency, no callbacks. And as a bonus, I enjoy writing Go code more than I’ve enjoyed programming in any other language since I started my career 15 years ago. Go was open sourced in 2009, and version 1.0 was released in 2012. It’s at version 1.3, is extremely stable, and no breaking changes have been introduced since it was open sourced. I highly recommend taking a look at it if you haven’t already.

Jan 1st, 0001

Jan 1st, 0001

Jan 1st, 0001

Jan 1st, 0001

Jan 1st, 0001

Jan 1st, 0001

Jan 1st, 0001

Jan 1st, 0001

Add Your Comment

Related content

Unboxing: Vogue

By Luke Quinnell

We're hiring. Let's talk. View available roles