Since Node.js spiraled into the limelight, there’s been a lot of heated debates about just how good it is in comparison with the most popular web programming language*, PHP.
If you haven’t yet tried creating a simple application in Node, I strongly recommend you do. With everything new, there’s pros and cons, but you won’t know if it’s for you unless you actually dive in and get your hands dirty.
We’ve ran Tumblr Stalkr now for what’s quickly approaching 5 years. We’ve collected terabytes of data and we actively process well into a million requests every month. It’s really given us some pretty impressive data sets to analyse and with such a large influx of traffic, we’ve learnt how to tackle problems that most digital agencies won’t ever mention to their clients, nor ever have to worry about. One of those being performance.
Performance is a huge topic, one that every developer often shy’s away from. We’ve built full web applications and bespoke software with PHP for years and I’ve never really felt the need to move away from it. With the most recent changes in PHP 5.5 and the to-be PHP 7, it’s really starting to shape into the language most developers sought it to be years ago. So, why should you concern yourself with Node if you’re a PHP programmer?
Learning is the sole purpose as you’re in education for a fifth of your life. Learning is what defies the current boundaries of what is possible and crafts out the next generation of what’s to be. Now, I’m not saying Node will bring any miracles in the years to come... but Node brings a wrath of performance boosts and solidarity across your backend and frontend code (hey, you’ve only got one language to deal with now!) You really can’t roll out code that’s not production ready - as we will see - which strongly encourages better testing and code verification, helping to eliminate bugs before they’re put up live (well, some!).
Undoubtedly, there’s a huge codebase of awesome open source PHP projects out there with thousands being actively developed each day (just check GitHub) but there’s also projects that have laid to rest and been untouched for years. What happens if that’s just the code you’re looking for? Do you really want to bolt on something that old?
Node.js code is fresh. It’s newer and has been developed by programmers who have full knowledge and understanding of modern web applications, from the server to the client. Node.js is different to PHP in that you can push your logical processing to the client. There’s no more request-response interaction, it’s event driven and your client is always in the loop.
Node is quick, very quick. Node is built on a computationally sound core system that’s been constructed with modern web servers and their interactions in consideration. Node consumes far less CPU resources on high demand and can easily respond to more requests in less time. That all being said, we’ve spent years optimising our PHP setup and if you’ve teamed up with Nginx, Varnish, Memacched and PHP OpCache - you really won’t notice much difference in processing / event times, but you’ll be stung on the multi-threaded setup of PHP.
This is where Node really kicks ass. At high levels of concurrency (thousands of connections) your server needs to go to asynchronous non-blocking and if any part of your code blocks (something I/O based) you’re going to need a thread which carries a huge overhead in terms of speed and resources. And at these levels of concurrency, you can’t go creating threads for every connection. In contrast, the entire core of Node is non-blocking and asynchronous, not just the I/O layer.
If you're still running Apache, here's how you can switch over to your own Nginx and Varnish setup.
Node uses a callback structure to pass logic from one asynchronous call to the next meaning we never have to worry about spawning new threads or even considering the deadlock process. Almost no function in Node directly performs I/O, so the process never block which is a major implication for scalable systems.
With all that being said, it wouldn’t be fair if I didn’t tell you what may take some time getting used to...
Unlike PHP, your code isn’t executed on a one line-basis. It’s entirely asynchronous and if you don’t handle it properly you can end up with a callback haven where you loop further and further into a callback chain.
SQL is PHP’s best friend. They were built hand-in-hand and sit alongside each other seamlessly. This isn’t the exact case for Node which is a powerhouse for JSON. Accessing SQL is possible and there’s plenty of plugins out there (we’re using Knex) that make it possible, but JSON is the lingua franca for interacting with many of the latest NoSQL databases. If you’ve got a very SQL-heavy project or you’re not quite ready to adopt the NoSQL approach, you may need to spend more time re-writing your query logic to make your calls handle asynchronous blocks accordingly.
Separation of Concerns.
PHP is the perfect language for quickly putting a project together. There’s a lot of frameworks out there that adopt the MVC structure, but, there’s nothing stopping you from quickly bashing out a file that contains some logic, some database calls and some HTML output. This is obviously not the case with Node which separates our fundamental components up giving us a clear separation of concern across our controllers / routes, models and views.
At the end of the day, the choice is completely yours but I’d strongly recommend biting the bullet and learning something new. There’s always demand in new and upcoming markets and with Node being a huge success in the developer industry it’s definitely a skill you want to put in the bag.
As a disclaimer, my assumption of ‘Speed’ being a pro for Node is entirely subjective on my part. There’s plenty of articles on Google for and against the performance of Node compared to a PHP and Nginx LEMP stack. But as fundamental principles go, removing any I/O blocking will give you a performance boost in the long-run regardless of the situation but whether your code compensates for that in complex callback loops and deferred promises.. that’s another story!
* Hard to produce any real trends in web programming language popularity, but the data sets I used are based off the PYPL (PopularitY of Programming Language) results by Pierre Carbonelle.