Posted by & filed under Node.js, PHP, Web Server.

This is an apples to oranges comparison. PHP is an older language, running behind the Apache web server in a request/response fashion. Node.js is a non-blocking event-loop framework running JavaScript within the V8 engine, with an optional web server built in. Then again, is it really an apples to oranges comparison? Both technologies are commonly used to serve webpages to browsers.

If you’ve been following my blog through the years, you’d know that I’m a big PHP fan. I earned my PHP5 ZCE (Zend Certified Engineer) certificate a few years back. I’ve built a couple hundred content-based websites using various Content Management Systems, as well as a dozen or so apps using different PHP Frameworks. I had a blast at the 2011 ZendCon, and I’ve even taught a PHP meetup for about nine months.

If you’ve been reading my blog as of late, you’ll also notice that I won’t shut up about this new thing called Node.js (Browser-Less JavaScript). Surely, I haven’t thrown away my years of PHP experience for this new kid on the block, right?

Honestly, I’ve been using both languages recently. At work our websites are built using PHP (although I’m finding more reasons for Node.js each day). For my side projects, I’m writing multiplayer web games and hardware interfacing software using Node.js.

Both environments have their pros and their cons, and neither language is the perfect solution for every project. In this post I’m going to compare and contrast the two environments, covering their strengths and weaknesses, and outline which is better for various situations.

Why am I only covering PHP+Apache and Node.js? Honestly, they’re the language I know best and have production code running for each. Ruby and Python are some great languages in this same space with comparable strengths and weaknesses, but I never had the opportunity to learn them. JavaScript (Node.js) and PHP both have syntax influenced by C.

Strengths of PHP

PHP is by far the most widely used server-side web programming language. It is old, and there is never short supply of cheap, shared hosting providers. Some of the largest and commonly used platforms/apps use PHP. WordPress, the most popular of self-hosted blogging platforms is PHP. MediaWiki, Joomla, are some more common self hosted apps which use PHP.

Some of the biggest websites use PHP, such as Facebook, Wikipedia. PHP uses traditional (read, familiar) Object Oriented methodologies. There are loads of PHP web frameworks and language documentation.

PHP is great for serving up content websites. PHP sits behind a web server, which can check to see if the file being requested exists in the filesystem. If so, the file can be served to the client without needing to run any PHP code. This isn’t necessarily a pro of the language itself, but it is a beneficial side-effect for most situations.

PHP also has corporate backing by the Zend company (Their tagline is “The PHP Company”). This backing is required by big corporations, which all share the same philosophy, “If something doesn’t cost money we don’t want it”.

Weaknesses of PHP

PHP is not meant to be run for extended amounts of time. Many will argue with me here, but the language by default is set to terminate itself once it has been running for 30 seconds, or if it reaches a certain amount of memory usage. This can be disabled, and apps can be built to run for a long time successfully, but this is not where PHP shines.

The language isn’t able to run code in parallel. You can, using tools like Gearman, pass off some work to be handled by other processes, and kinda keep an eye on the progress, but the process is rather klunky, and is not what PHP is intended for. Gearman itself offers some other great features and can be used by many different environments, including Node.js.

Back in the day, when URLs and filesystems had a 1:1 mapping, it made perfect sense to have a web server separate from the language it is running. But, nowadays, any PHP app with attractive URLs running behind the Apache web server is going to need a .htaccess file, which tells the server a regular expression to check before serving up a file. Sound complex and awkward with unnecessary overhead? That’s because it is.

Overall, the stack required to support PHP is overly complex when compared to something simpler like Node. One needs Apache, which has some global settings as well as site specific settings. One also needs PHP, which has global php.ini settings, some of which can be overridden at run time (but not all). There is also a bunch of old stuff left around which should be removed, e.g., y2k support (finally removed in 5.4).

The official website is quite ugly and outdated. The docs are okay, the user contributed notes are very useful, however the method to update docs involves SVN and hacking away at XML files, and is not exactly encouraging for most people to write docs.

Package management is virtually non-existant. Sure, there is PEAR, but that tool is ridiculously painful to use. Some other package managers have appeared, e.g. Pyrus (PEAR2) and Packagist, but usage is so scattered that there is no de facto standard. There probably never will be to be honest. There is also, but this site is painful to use and requires a signed-in user to browse.

Since a PHP process starts, does some boilerplate work, performs the taks the user actually wants, and then dies, data is not persistent in memory. You can keep this data persistent using third party tools like Memcache or traditional database, but then there is the overhead of communicating with those external processes.

Strengths of Node.js

Node.js’s biggest strength, IMO, is that it is event driven. Node apps run great over long periods of time. The event emitter code, while pretty simple at its core, provides a powerful and consistent interface for triggering code execution when needed.

Node has a web server built in. Some people call this a bad thing, I call those people crazy. Having the server built in means that you don’t have the awkward .htaccess config thing going on. Every request is understood to go through the same process, without having to hunt through the filesystem and figure out which script to run.

The number one bottleneck with web apps is not the time it takes to calculate CPU hungry operations, but rather network I/O. If you need to respond to a client request after making a database call and sending an email, you can perform the two actions and respond
when both are complete.

Of course, with Node.js being written in JavaScript, if you already know JS for frontend development, you are doing pretty good in the Node.js realm. You already know the syntax, and the gotcha’s of the language, all that is left is an API for interacting with the system.

The package management system, npm, is great (although the website leaves much to be desired). Instead of having to follow strict guidelines and formatting requirements (e.g. PHP’s PEAR), anyone can put anything into npm (even me!). It is similar to the Android market. Sure, you can get some crappy things out of it, but if one uses common sense they won’t be downloading a virus.

Being so new, it doesn’t have a lot of baggage leftover from days of old. Having a server built in, the stack is a lot simpler, there are less points of failure, and there is more control over what you can do with HTTP responses (ever try overwriting the name of the web server using PHP?).

Data can be persisted in memory very easily, so if you are sharing data between different clients (e.g. with a multiplayer game), this sharing of data is built in.

Weaknesses of Node.js

Node.js is a very new, API unstable, untested platform. If you are going to be building a large corporate scale app with a long lifetime, Node.js is not a good solution. The Node API’s are changing almost daily, and large/longterm apps will need to be rewritten often.

If you are serving up a lot of static files, such as images, you don’t want to use Node.js, otherwise you get back to the situation where you are checking the filesystem if things exists. This can be fixed by moving all static content to a subdomain or Content Delivery Network.

JavaScript is a far from perfect language, having been created over a 10 day period. If you are a traditional Class based developer, getting used to a Functional programming language can be painful. Getting used to asynchronous programming can also be difficult.

The persistent memory thing can be a little tricky. If you don’t know what you’re doing, you might accidentally share data between clients (which could be a disaster). Also, you are in bigger danger of memory leaks. If you keep appending data to an array in PHP, the script only really has a lifetime of 0.1 seconds, but your Node.js script needs to run forever, and you can easily blow it up over a period of time.

Node is single threaded, even though it kind of appears to be multithreaded with the asynchronous execution it does. This doesn’t really matter too much, when is the last time your app’s biggest bottleneck was CPU instead of waiting on network I/O? So, while it would be cool to be multi-threaded, it doesn’t usually harm an app.

Which should I learn?

This is a great question. If you don’t have any experience developing server side software, you should probably start off with PHP. It is a great, easy language for performing the request -> response pattern which makes the stateless internet great. You will surely find more forum posts from people having the same problem as you (even though the posts might be 10 years old).

If you are looking to build other kinds of software, Node.js may be a safer bet. For example, I’m writing some software which requires code to be triggered by changes made to hardware, such as a wireless network coming into range. Writing this kind of software using PHP would be hacky and painful, but with Node.js it is a breeze.

As far as being future proof is concerned, I am not convinced that either language will stand the tests of time. The future of web apps are probably Single Page Applications, where smaller amounts of data are sent over the wire and the frontend is in charge of generating HTML, through the use of websockets. PHP can’t nicely do websockets like Node.js can. However, it is too soon to tell if Node.js will win the asynchronous, event driven language war. Due to the major flaws of JavaScript, a better language could easily kick its ass.

Example Situations

Here’s some quick examples of different programming situations and which language you should probably go with.

  • Are you building some sort of daemon? Use Node.
  • Are you making a content website? Use PHP.
  • Do you want to share data between visitors? Use Node.
  • Are you a beginner looking to make a quick website? Use PHP.
  • Are you going to run a bunch of code in parallel? Use Node.
  • Are you writing software for clients to run on shared hosts? Use PHP.
  • Do you want push events from the server to the client using websockets? Use Node.
  • Does your team already know PHP? Use PHP.
  • Does your team already know frontend JavaScript? Node would be easier to learn.
  • Are you building a command line script? Both work.

Simple Equation

Here’s a funny way of looking at things… To emulate the functionality of Node.js using PHP + Apache, you would need a couple other services running. To have Node act the same as PHP, you would simply run a bunch of synchronous code.

Node.js ≈ PHP + Apache + Memcached + Gearman - complexity

Thomas Hunter II

Thomas is the author of Advanced Microservices and a prolific public speaker with a passion for reducing complex problems into simple language and diagrams. His career includes working at Fortune 50's in the Midwest, co-founding a successful startup, and everything in between.


  • alex


  • ted

    spel chek?

    • I wrote this in VIM while riding in a car. Whoops!

      • devil

        u showing that how great u r.. take ur time n write meaningful blogs..

  • Gildus

    Excelent article.

  • Great article. It seems to many people are on the PHP is 100% crap or node.js is 100% crap and no one really writes about how php is AMAZING for some things and node.js can blow everything out of the water in a different scenario.

  • There are some good points in here. However, there is a lot of bad information about how to deploy a PHP application with Apache. There is also a lack of understanding of what memcached does and why you should use it. There are memcached and Gearman libs for Node.js. Why is this? According to you, no one would ever need them. Bummer, you had some good points, but lost them in FUD about PHP.

    • Good point, apparently I did a bad job of explaining myself, and I will have to go back and rewrite some parts.

      The comment I had at the end was a mostly joking statement about technologies PHP would need to use to keep data persisted in memory and run tasks in parallel, I didn’t mean to say Node.js had all of the capabilities of Memcached or Gearman within itself.

      Memcached and Gearman both can be used by Node.js. Memcached, as it is distributed, allows it to be much more useful than simple in-memory Node.js variables and Gearman offers a great method for keeping track of externally running jobs.

  • Bicou

    Does your team already know PHP? Use PHP.

    duh !

    • This statement does seem obvious to you and I, however, there is a surprising amount of people who believe Node.js is the best thing since sliced bread and that new projects should switch over to using the latest technology.

      Even if Node.js is a better tool for the job, the knowledge of the existing team takes priority.

  • Bicou

    ever try overwriting the name of the web server using PHP?

    header('Server: wtf')

    • In theory that command should work, however Apache still overrides the server header set by PHP with that of its own.

      header('Server: blah');

      Results in:

      HTTP/1.1 200 OK
      Date: Tue, 26 Jun 2012 13:26:23 GMT
      Server: Apache
      X-Powered-By: PHP/5.3.5
      Vary: Accept-Encoding
      Content-Encoding: gzip
      Content-Length: 25
      Connection: close
      Content-Type: text/html; charset=UTF-8
      • Bicou

        Works with nginx. Blame Apache, not PHP.

      • Bicou

        Why do that btw ?

        • It was an example of the issues that will arise when using so many different layers of tools for a development stack.

          A PHP website uses PHP and a web server (Apache, lighttpd, nginx, etc) whereas node.js, having the server built in, has less layers and less issues with these inter-layer communications.

          • Bicou

            Your example is not an issue, as configuring HTTP server name should be done in HTTP configuration. And why do that ???
            Find a real example.

            So many stacks ? each stack is doing its job, it’s the principle of SoC. With “real” websites, you have to divide: decoupling is the key to scalability.

            Try to rebuild your website with nodejs instead of apache+php+wordpress, I think you will find some nodejs issues.

  • Nice post, I enjoy NODE for the few experiments I have used it for. But will always have a soft spot for PHP as its what pays the bills :)

    • Same here!

      • Actually, I lied. After moving to Node.js a few years ago I’ve never once looked back at PHP.

    • People are using the V8 engine, which was developed by Google to sit in the browser, to serve content on a server (and run forever).
      I am bedazzled. I am skeptical and curious at the same time.
      I’m sure PHP is more performant/efficient and robust (as most older technologies are), but then if that’s all what mattered we’d all be writing assembly now.

  • Christian

    thanks for this post, i understand your point of view

  • claudiu

    You can not compare two different architectures this way, there just build for different purposes.

    I’ve been using PHP for many years and I’m a big fan of JavaScript, but comparing them is just ridiculous…

    If you look at your title, your comparing a programming language with a server.

    • Cladiu, you are right but I think this question “PHP or Node.js” is not about architecture. It’s about what to choose in order to create your project and which platform can help you solve your project features.

      I’m starting a new project and I asked myself what to choose, should I stay with PHP or should I test Node.js. I plan heavy usage of Backbone.js and that’s why I had Node.js in mind but in the end I realized that PHP and Backbone.js will do it’s work.

  • Very nice and informative post. Although I’m not totally agree with the “Simple Equation” part.
    Node wouldn’t completely replace the need for Memcache and Gearman, although it does some of the basic functionalities of both.

    • Yeah, I need to rewrite that part. I was trying to say that PHP would be able to emulate the persistence/asynchronous features of Node by using those technologies, but I did a bad job explaining it.

  • Nice write-up, makes me want to try node now. I take issue with you saying the Apache/PHP stack is overly complex. It works out of the box after a simple “apt-get install apache2 php5” everything else is spot on though.

  • i used NODE some times this year, i worked on front-end for a few years but this year i made a change on my career path and now i’m working full time as php developer.
    personally i prefer to keep working with PHP <3

  • Adrian

    Regarding package management in PHP please check out Composer and it’s package archive packagist.

    • I mention packagist in the second to last paragraph in the weaknesses of php section.

      • How is Packagist a weakness? It’s seeing an increase in uptake, just like Node.

        You can’t suggest that new tools are not good because they’re still not used by the vast majority. How else can progress be made?

        • I didn’t say Packagist is a weakness, I was saying that there is no de facto package management tool for PHP. Personally I think packagist/composer is a great idea and I hope it does become the standard tool, as it is simpler and more modern than its prickly predecessors.

  • > There is also a bunch of old stuff left around which should be removed, e.g., y2k support (finally removed in 5.4).

    So it’s not “still around”, it has was removed in March. Why say use 4 month old configuration options as an argument against PHP today? We’re on 5.4.5 now dude.

    > This [30 second limit] can be disabled, and apps can be built to run for a long time successfully, but this is not where PHP shines.

    Does it need to be? While you certainly can build applications that run on the command line just fine if you manage your memory correctly, I wouldn’t recommend doing it on an application where I cared about extreme performance. I build dsitributed applications in PHP and for that you need to meet minimum requirements of languages and features so that is when you would, but if I am writing server code I would use a language designed for the sever. A little bit of Ruby here would be fine.

    > But, nowadays, any PHP app with attractive URLs running behind the Apache web server is going to need a .htaccess file, which tells the server a regular expression to check before serving up a file.

    Hey now, what are you talking about? PHP is a scripting language and you need some server glue to make HTTP requests get directed correctly. Ruby has rake which does the same stuff, using tools like WEBrick, Shotgun, etc. Is that more or less complicated that having Apache? You only need to use mod_rewrite if you’re trying to use the Front Controller pattern where everything is routed through index.php, which not everyone does. Again, this is nothing to do with PHP.

    As for .htaccess, that is pretty slow if you’re worried about performance. Putting your configuration into the main configuration files is quicker, and less “confusing”. But that is just sysadmin logic, and nothing to do with PHP.

    Finally, why not use nginx? If you’re concerned about old stuff, why not use new stuff? Nginx is crazy fast and when coupled with PHP-FPM is a MASSIVE upgrade on the now 13-yr old Apache server. Again this is nothing to do with PHP. Seeing a pattern here?

    > The official website is quite ugly and outdated.

    How is that relevant? The information in there is as useful as ever. We’re developers, who cares.

    > There is also, but this site is painful to use and requires a signed-in user to browse.

    Nobody has ever recommended that site to anyone for anything. It needs to be shut down, but that is nothing to do with PHP.

    > The package management system, npm, is great

    And Composer is basically Idential. It’s usage is less thinly spread than you think, as it has become a de-facto standard for anyone building PSR-0 and up components. It’s rare you’ll see anybody suggesting PEAR, but you see a LOT of developers picking up Composer. It’s getting huge, especially with pretty much every modern framework supporting it.

    > Instead of having to follow strict guidelines and formatting requirements

    That sounds fun…

    > Being so new, it doesn’t have a lot of baggage leftover from days of old.

    It’s also not been through years and years of rigourous hardening, and is yet to reach a 1.0 version.

    > Are you building some sort of daemon? Use Node.

    I would recommend Ruby or Python. Why would you use something that has a web-server built in, for a task that does not require a webserver? That’s just ridiculous.

    > Are you making a content website? Use PHP.

    Node would do this fine. Do you mean a “distributable application?.”

    > Are you building a command line script? Both work.

    I thought you suggested against this?

    Dude I am just confused. Your article is basically saying that Node is pretty cool, and it’s good.

    We all KNOW that Node is pretty cool. I’ve used it for a few projects, especially stuff that involves real-time connections, peer-to-peer sockets, etc, but this article is mainly FUD.

    You’re pointing out problems with PHP that are nothing to do with PHP. Complaining about things that have been fixed, suggesting it shouldn’t be used for stuff it does fine and recommending it for things it does not do well.


    • @Phil: I respect where you are coming from with your reply, but to be honest, some of your arguments are a bit one-sided (toward PHP). I won’t negate your arguments here, but I will point you to the following:

    • @Phil: BTW, if you want to know which points I take issue with, hit me up directly and we can chat.

    • Agree with you Phil. Also, I think, and I hope, the whole PHP community will listen and look into all those cool kids around of corner and keep improving itself. Back in days of PHP 4, the OOP features are not complete, and later on we have public, private and protected methods (hey Java!), then we have closure (hey Javascript!) and now we have traits and short array syntax. (Hey Ruby!) And, we have extensions like php-uv and even v8js. (Hey node.js!)

      • jim huang

        Also, I remember when in the old days when Ruby on Rails just hit the street, everyone is saying “MVC is cool and we should all code web apps on Rails”. Later on PHP community has an array of MVC frameworks come up, CakePHP, Codeigniter, Kohana, YII… I wish this time it is the same thing, PHP community will come up with an array of node.js like packages.

        • Which means PHP is a follower, not a leader, and after a while that gets a bit tiring…

  • trash

    A great Comparision based on facts wouldn’t help anyone, but waht do you think about the enviroment,
    Coding Style, Packages (npm vs. pear, composer?). Shared hosting is good for PHP, ok…I agree, but what about PHP Applications in the “real” world.
    Would you mind if your Car requests a PHP Webservice and get a JSON Response?
    Would you use Node over PHP in critical Applications, ie. accounting?

  • Varun Sheth

    Can you come up with a tutorial for node.js with real life examples for newbies like us to node.js

    • I might be open sourcing my HTML5 game (which runs on node.js). Is that the sort of thing you’re looking for?

  • Pingback: Community News: Big Data Trends, Continuous Delivery and More | New Relic blog()

  • Mathieu Rochette

    Do you realize that actually you are comparing different things?

    you should compare PHP with Javascript, and Node.js with Apache/mod_php

    remarks about PHP weaknesses,

    “PHP is not meant to be run for extended amounts of time.”
    what make you say that? what problem did you have with long running process with PHP?

    “The language isn’t able to run code in parallel.”

    “Back in the day, when URLs and filesystems had a 1:1 mapping…”
    Agreed. but it’s how apache handle PHP not PHP by itself.

    “Overall, the stack required to support PHP”
    “One needs Apache” and Javascript needs Node.js . Agree about old stuff left, I guess Node.js API is not (yet) that way.

    “The official website is quite ugly and outdated”
    strong point… Never tried to contribute to documentation, intersting point. Looks like it’s git+html for node.js but I couldn’t find a howto as in the php website.

    “Package management is virtually non-existant.”
    maybe you should look at composer (

    “Since a PHP process starts”
    That the apache mod_php too (maybe a PHP specific server is needed as node.js for javascript but it would probably still have to the same problem (IYHO) that node.js have with static files)

  • Just a bit fresh air here, I think the whole idea of node.js is great but with a bit effort PHP can do the same thing too, especially now with php-uv extension, we can approach the core of node.js, libuv from PHP.
    Check out
    The benchmark shows almost identical (maybe better) performance than node.js

  • Francisc

    Good article overall, but I disagree with this:
    “Due to the major flaws of JavaScript, a better language could easily kick its ass.”

    I think you’re saying that because you don’t know JavaScript well enough.

    Another thing to note is that the language is continually improved, ES6 is around the corner, and Node will benefit from it right away as browser inconsistencies are irrelevant so server-side JS.

  • Johnny5

    Different tools really (basically in agreement with the post aside from specifics). I see a lot of PHP guys getting defensive around the ‘net when they have no reason to worry: node isn’t after your CRUD space. I wouldn’t be surprised if it eventually does though.

  • Sergey

    I like this article. I cannot agree only one one point of the weakness of node.

    JavaScript is a far from perfect language, having been created over a 10 day period. If you are a traditional Class based developer, getting used to a Functional programming language can be painful. Getting used to asynchronous programming can also be difficult.

    I more agree with people in comments here

    Javascript revolution!

    It is also important that Microsoft made Javascript/HTML5 one of 2 native languages (another C#/XAML) to develop apps on WinRT (Windows 8 Metro)

    Not J# not Java but JavaScript. To me JS is an excellent choice for for what node stends for.

    • yenic

      Obviously Java isn’t going to be a native dev platform for Win8, come on. I wouldn’t get too excited about the ‘rise’ of JS, it’s just to bring in frontend developers to the Windows fold. C++ is more significatn and also native on Win8. Source-

      “A single, modern, unified Windows API at last

      The point of all this? It gives parity to native C++ and managed .NET code. Instead of being separate, each with its own different capabilities and strengths, they will be peers. “

  • yenic

    I’m teaching myself Python as my 1st real programming language, having dabbled in various languages in the 80s and 90s.

    You seem to have some good experience under your belt with production systems and I’m curious on your view of Python. You should try Learn Python the Hard Way (it’s how I’m learning Python). I’ve regularly wondered if JS/Node would ultimately make Python pointless, but it seems the async nature requiring callbacks and general ugliness of the language is holding it back from taking over general acceptance in to the realms that Python holds onto well (*nix admin scripting, crossplatform GUI applications, game scripting / game creation, data modeling, 3D applications). Of course Python can’t do frontend work, but it certainly holds its own on backend.

    I did a lot of research before picking my first serious programming language and I came down to Python, Javascript and C as being my main interests (in that order). But I’m always interested in the point of view of those of you with production work out there.

    • Everything I know about python leads me to believe I would love it; I just haven’t had the time yet to take it seriously and research it.

  • hamish

    Great article, and as someone who has written similar articles, just ignore the haters who feel threatened and try to put you down, and are negative for its own sake.

    Being an active developer in PHP, JavaScript and Python I’ll tell you not to get your hopes up that it’s an awesome language. It has pros and cons like all the others.

  • Dave

    How would you evaluate erlang in this context?
    I like node.js but hate JavaScript.

  • I just want build a dating site use node.js. is that OK?

    • It is of course OK, but if you’re serving up simple CRUD pages (like most dating sites do), it isn’t where Node.js would be most beneficial. If you do a bit of real time communication, Node might be a better solution.

  • very well written, but PHP still got long way to go :)

  • Great article, unbiased and informative. I’m sort of in the same situation (using node at home and PHP at work), though I feel that as node matures it’ll become common on shared hosting and one day may surpass the traditional *AMP stack in usage, which would be awesome because I love JavaScript as a language (I prefer prototypes over traditional class objects) and it’d be great to use a single language for both server and client side on my daily work!

  • Kristy.L

    thanks for your advice :)

  • Don


    can you provide website developed in node.js or games developed in node.js,

    Its better if you attach any node.js project to learn.


  • Great article, really put node into perspective. Thanks

  • David

    I appreciate the article, but you’ve greatly gimped what PHP actually is in your article by far. Yes PEAR/PECL may be difficult for you to use, but it’s arbitrary and after you compile in a small list of extras (memcached, geoip) then they’re easily available. Many you could simply copy in the PHP class files and are good to go.

    Even though the default timeout is 30 seconds, you addressed it could be extended, but there are lots of appropriate applications where you could build a response, serverside application running in parallel. PHP allows you to fork processes and create socket listeners etc. Along with that, long sockets / comet applications allow you to do real-time, event driven applications in PHP.

    Node.js has some perks, but aside from simplifying a few tasks, it doesn’t seem a seasoned PHP developer would benefit from switching over.

    Also, Apache sucks, your example used .htaccess (which is ONLY Apache), nginx performance (especially with PHP, using cgi of fpm etc) has surpassed Node.js for sending HTML in several tests I’ve seen.

  • Jonathan

    Hi Thomas,

    Thanks for the brilliant insight and comparison between both systems. We are planning on running a large scale E-commerce marketplace (eventually an array of websites, one for each country) and we are trying to decide on whether to use PHP + Apache Stack or go with Node.js. We plan on getting 5000 peak simultaneous connections for our “product search” function. What would you suggest ? Thanks !

    • I’d lean towards PHP as you’re probably not going to benefit from any real-time communication, shared data between different users, etc.

      Also, if Node crashes, it could cause a lot of trouble, especially since most of what you are doing is transactional, but if one PHP execution fails, it’s much less dangerous.

      There’s also a lot of PHP eCommerce applications and libraries out there already that you could make use of.

  • Pingback: Pitfalls in Large-Scale Application Development on Node.js()

  • pcunite

    The library Node.js uses, libuv & http-parser, is going to really make high performance sites easy … if you want to code in C/C++ that is.

  • Hi Thomas,

    Thanks for the great article. It may have flaws but without it we wouldn’t get these useful discussions.

    I’ve been using PHP and Javascript developer for 9 years now and although I too do my severside webdev in PHP, I have really noticed how Javascript development is quickly gaining a lot of uses like:
    – Web client (always has been, but gotten huge since jQuery and everything that followed)
    – Web server (node.js)
    – System standalone (node.js)
    – Browser extensions
    – Windows 8 Metro
    – Mobile semi native (Titanium) and using webkit? (Apache Cordova)
    – Extending different software (like Adobe CS)
    – And probably another few I didn’t know (please tell me)

    So, I think node will become much more of a competitor to PHP, not because it’s better for server site webdevelopment but because Javascript will become the easy-to-learn-use-everywhere language. And it will be used for things it shouldn’t be used, just because the programmer already knew how to program Javascript.

  • Air Man

    See another example on a websocket/node/PHP integration here:

  • This is a well written article. Thanks for nice comparison between PHP and Nodejs