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.
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.
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.