PHP vs Node.js Smackdown: Right of Reply
In SitePoint's recent PHP vs Node.js Smackdown, Craig Buckler pitted these development disciplines against each other over a series of ten challenges, to determine which is the overall winner.
Here's their blow-by-blow assessment …
Round 1: Getting Started
Round 1's challenge was to see how quickly you can build a “Hello World” web page in each language. This included the time taken to set up a server environment.
In Craig's estimation, PHP won the round, partly because it's "conceptually simpler" and "less daunting to new developers".
PHP wins in "getting started" purely because more hosts have made it so easy to get started. It's a matter of adoption rather than anything else. If more hosts bypassed the need to use the command line with Node and went straight to file uploads and a simple "reload app" button in a control panel, they would be equal. The actual syntax of getting something to display on screen, however, is much simpler in PHP — especially to those new to programming.
When developing locally, I don't see a huge difference between the two. To run a PHP script in your browser, you need to have some kind of server stack installed; to run a Node script, you need to have installed Node, and preferably a web framework such as express. However, as Craig says, PHP is conceptually simpler. Node's barrier to entry is higher. No debate there.
Round 2: Help and Support
Round 2 looked at how easy it is to get help and support with each language. PHP wins this round, mainly because of its longevity.
Bruno kept silent on this one.
I agree with this. Node.js is a younger technology, so currently, there is less help available. This will, however, become less and less of a consideration as Node matures.
Round 3: Language Syntax
I strongly disagree on this point. While PHP does have its quirks, many of them have been corrected in recent times and many oddities will be removed in the newest release. On the other hand, there's this and this in the JS world.
Regarding bullet 3 (that your brain doesn’t need to switch modes because you can use JS on the client and server), I disagree. The server environment is completely different from the client one, and a switching of brain modes is required. There's also new syntax that you can't use in the browser, and vice versa, so it's kind of like switching languages.
Bullet 4 (that understanding JS makes you want to use it more) is also something I disagree with. Having worked with both JS and PHP for years, the more I work with JS, the less I like it — though that's purely personal preference.
Round 4: Development Tools
Round 4 considered the tools available to each technology, with Node winning by a nose thanks to npm.
While Composer was originally inspired by npm, it's now leaps and bounds better than it and won't break your system if you have to install two versions of the same library, unlike npm. Also unlike npm, Composer can install recursive dependencies, something npm simply cannot do — yet something that is absolutely essential, and should be the very first thought in the head of someone setting out to build a package manager.
npm also has downright awful error messages that are what I like to call "core-developer friendly" — in that only those who wrote them can understand them. Finally, npm doesn't play well with Vagrant, and effectively hinders you in getting started properly — not to mention that they don't pay attention to their users' desires. Here is a bug that's been open for years, making it basically unusable on Windows — hardly a trivial user base. PHP has its share of stupid bugs too, but those don't alienate an entire OS for years.
True, Composer isn't bundled with PHP, but I don't think it should be. Such favor shouldn't be given to a package manager which is, literally, a separate app. If someone, some day, actually makes a good package manager for Node, it'll be bureaucratic hell to switch it out for the current one, let alone get people to transition. Besides, installing it is literally one line in a terminal, or downloading an installer.
The statement that Composer has had less of an impact is plain wrong. Composer has influenced all of the new PHP devs coming on board the PHP train since it was developed, and most of the good ones who had to add it into their current workflow. Just because there were a lot of PHP users before Composer existed, doesn't mean its impact is smaller. Ever since it was made, it has had a tremendous impact. Absolutist statements like "has made less of an impact within the community" shouldn't be made without a factual backing.
I can't argue with the fact that most PHP devs will install Node at one point, that's true. Sadly, a lot of the good tools are being developed Node-first, but I remain hopeful for a Node-free development environment due to projects like BowerPHP.
I'm glad this one went to Node.
I love npm. It's easy to install, easy to use, and there are thousands of packages available for almost any need. I also like the fact that npm lets you choose between the global and local installation of packages (in contrast to languages such as Ruby, where it's standard for your gems to be installed alongside your Ruby version). The tooling is also fantastic. Tools such as Bower and Grunt have a regular place in my workflow, and have increased my productivity many times over.
It's also worth mentioning that npm v3 is out in beta. This addresses many of the points that Bruno raises, such as the nested node_modules approach bug.
Quote of the entire smackdown:
PHP developers will probably want/need to install Node.js at some point. The reverse isn’t true.
Round 5: Environments
Round 5 touched on where the technologies can be used and deployed, and which platforms and ecosystems are supported. Craig wasn't explicit about his call on this one, but it looks like a wet sail for Node.
Craig said he would compare PHP's and Node's web strengths (general web development challenge) and then says JS is everywhere. Firstly, we're comparing Node.js, not JS itself. Secondly, we're comparing the languages and environments where they can run. Saying a monkey is better than a fish because the fish has failed to climb the tree is just silly. But both the monkey and the fish can swim, so let's compare how well they do that.
In a web development environment, PHP wins hands down. There are tools for desktop development in PHP — and yes, true, you probably won't use them. But you definitely will use the command line aspect of PHP.
Again, I agree with Craig. Several of the features that are making Node.js so popular (speed, scalability, affinity with JSON, low resource usage) also make it well-suited for many other kinds of applications, for example powering IoT devices. I mean, who doesn't love robots?
Round 6: Integration
Round 6 looked at integration with databases and drivers, and PHP wins mainly because of its age.
Integration is a draw. PHP has an age advantage in this, giving it more options, but this also means it suffers from some severely outdated integrations like the
mysql extension — which we've only managed to get rid of in PHP7, but which has been unusable for years.
Round 7: Hosting and Deployment
Round 7 looked at how easy it is to deploy new apps to a live web server, and in Craig's view, PHP is the clear winner on this count.
Again, Bruno keeps quiet, having nothing to add.
This is one area where Node has got a lot of catching up to do. Every budget web hosting company offers a PHP packet with MySQL thrown in. To see some kind of output, all you've got to do is create a file with a
.php extension, shove some valid statements between <? and ?>, upload the file and point your browser at it. The same cannot be said for Node. There are, of course, many options for Node hosting, but they invariably require more set up and command line access, which is potentially off-putting for beginners. PHP wins this round hands down, no question.
Round 8: Performance
Round 8 focused on speed; and, although this can often come down to the experience and care taken by the development team, Craig noted the advantages of Node on a number of fronts.
Misconceptions abound. First, there is this post which renders all performance discussions moot. Any and all performance gains/losses depend exclusively on the experience of the devs and the type of app. But even if that post isn't convincing you that performance discussions are stupid out of context, here are some of my own arguments:
- PHP is getting a multi-threaded built-in server. This would make it possible to bypass an external server completely, but not recommended (yet). There are also super fast servers like Nginx which make the whole process of launching PHP and delegating requests to it unnoticeable.
- Projects like HHVM and Appserver add powerful async and multithreading aspects to PHP, and PHP7 itself is getting some powerful upgrades in that department, too.
Performance discussions are, and always will be, a draw. (Unless you're dealing with Java — then Java always loses! ;) )
Node is touted as the runtime of choice for high-performance, low latency applications, and has already found its way into the code stacks of several Fortune 500 companies. Thanks to its non-blocking I/O mechanism and Google Chrome V8 engine technology, it has become synonymous with the words "fast" and "scalable". There are numerous stories online about how Node brought serious performance gains to companies and lead to greater developer productivity. I'm happy to see this one go to Node, but understand that it's a contentious point.
Round 9: Programmer Passion
Round 9 looked at Craig's perception of how much passion developers are currently showing for PHP and Node, and in his estimation, Node wins hands down.
You are definitely looking in the wrong places, Craig. The PHP community is incredibly passionate and very active. There are over 20 big conferences per year, and some amazing topics get discussed. The treading of water has finished with the advent of HHVM and PHP7.
Additionally, I would say that it's curious that Node's developers still haven't learned how version numbers work (version v0.12.5 at the time of writing), even after 6 years in development. That kind of immaturity and desperate "playing it safe" (whoops, you used something that's unstable, your fault it broke your company lol), coupled with the critical but ignored ancient bugs that alienate userbases of entire operating systems, is something that will turn any serious developer away from a programming language's ecosystem.
I dislike Node. My dislike is based on negative experiences mainly revolving around npm. That might change in the future, but for now, I'm filled with dread and despair every time I have to use Node in any capacity. We all have our preferences, but it's important to remain objective and pick the right tool for the job. But it's also important to admit that sometimes picking the right tool entails picking the wrong one first because you just don't know yet. So don't listen to Craig. Don't listen to Jim. Don't listen to me. Try it out — see what works, find out what feels good and use that. Ultimately, the environment that makes you feel productive and awesome is the best one, not the one that gives you a millisecond shorter loading times.
Node is hot. There is a whole lot of innovation going on right now in Nodeland. Whilst passion is subjective, I'm glad Node won this round.
Round 10: The Future
Round 10 looked at the future of both languages, and Craig declared this one a draw, as both languages look to have a strong future at this stage.
Bruno had to rush off to write some more PHP and edit incredible PHP articles for SitePoint.
A draw was a fair result for this round. Node is the rising star, but it's going to take something massive to unseat PHP.
To wrap up, if your only tool is a hammer, then every problem looks like a nail. Node isn't the perfect fit for every scenario, and indeed there are many times when it makes sense not to use it. However, what Node does well, it does very well. It's up to you to make an informed choice and choose the best tool for the job.
So, now that Bruno and James have had their say, what do you have to say?