Stop comparing stuff you don't understand

Mon, Jun 25, 2012 11:09 PM
I normally don't do this. When I see someone write a blog post I don't agree with, I often just dismiss it and go on. But, this particular one caught my attention. It was titled PHP vs Node.js: Yet Another Versus. The summary was:

Node.js = PHP + Apache + Memcached + Gearman - overhead

What the f**k? Are you kidding me? Clearly this person has NEVER used memcached or Gearman in a production environment that had any actual load.

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.

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.
He believes that PHP inside Apache requires a .htaccess file. Welcome to 1999. I have not used a .htaccess file since then. Anyone that cares at all about scaling Apache would disable .htaccess files. And as for running regexs, how does he propose you decide your code path in the controller of his Node.js code? Something somewhere has to decide what code is going to answer a given request. mod_rewrite is wire speed fast and compiled in C. Javascript nor PHP code could ever beat that.

The official website is quite ugly and outdated.
Really? You choose your tools based on that? I don't know what to say.

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.
He clearly has no understanding of how memcached is supposed to be used. You don't put things in Memcached so you can use it on the next request on this server. You put things in memcached so you can use it in any request on any server in your server pool. If you just have one web server, you can write Perl CGI scripts. Performance and up time is not important to you. If you want to share things across requests in PHP, APC and XCache fill the need very well.

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.
This sums up the mythical magic of Node.js. People think just because your code is not "running" that somehow the server is not doing anything. The process does not get to go do other shit. No, that would be multi-threaded. And Node.js is not multi-threaded. It is single threaded. That means the process can only be doing one thing at a time. If you are waiting on a DB call, you are waiting. I don't care what world you think you live in. You are waiting on that DB call. How your code is structured is irrelevant to how computers actually work. The event driven nature that is Node.js is much like OOP. You are abstracting yourself from how computers really work. The further you get from that, the less you will be able to control the computer.
Node.js is a very new, 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.
So, if I plan on making a living, don't use Node.js. Got it. We finally agree on something.
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?).
No, why would you? It is not the web server. Apache or nginx would be your web server.
  • 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.
Yes, of course you would not build a daemon in PHP. Do you plan to share that same data across servers? He already told us Node is not multi-threaded, so how can it run code in parallel? Websockets have a ton of their own pain to deal with that is not even related to Node vs. PHP. Things like proxies. If I was building a command line tool and wanted to use Javascript, I would just use V8.

Listen, I write code in PHP and JavaScript all day. I also use some Ruby, Lua and even dabble in C. I am not a language snob. Use what works for you. I do however take exception when people write about things they clearly have no idea about. He claims to have written a lot of PHP. He clearly has never deployed a lot of PHP in environments that matter. If you are building small sites that don't have a lot of traffic, you can use anything. If you are building massive sites that have to scale, any technology is going to require a full understanding of what it takes to scale it out. I leave you with this wisdom that I am reminded of by his blog post.
Gravatar for dogmatic69

dogmatic69 Says:

| Yes, of course you would not build a daemon in PHP

Gravatar for Brian Moon

Brian Moon Says:

@dogmatic69, Yes, I have done it too.

Gravatar for John Douglass

John Douglass Says:

I've written plenty of daemons in PHP. I use the same models and functions that I might use on the website/API within my daemon logic. Works great for me.

Gravatar for Shay Ben Moshe

Shay Ben Moshe Says:

Hey Brian, thanks for the article.
I can't completely agree with either one of you, however, I would like to refer to what you said about Node.js being one threaded.

First, there is an option to open another thread (or process I don't remember at the moment) in Node.js.

Second, if I am making a request to the database I am passing a callback. This callback is emitted when the response from the database comes. In the time between the request to the database and the time when the callback is emitted, other parts of the code run.
For example, lets say my page has to parts, each part's content has to be requested from a database and the processed (sorted, summed, capitalized, whatever).
In PHP what I will normally do will be:
1. Request the first part from the database.
2. Wait for the response.
3. Process that response.
4. Request the second part from the database.
5. Wait for the response.
6. Process that response.
7. Deliver the data.
(You can move 3 after 6 but this is not the issue).
In Node.js I will do:
1. Request the first part from the database, when the response is done call 3.
2. Request the second part from the database, when the response is done call 4.
3. Process the first part's response, call 5.
4. Process the second part's response, call 5.
5. If this was called twice, deliver the data.
In the Node.js case I can process the response that came earlier while the other response isn't here yet.
Another example is that I can get and handle more request from clients while I wait for the database/sending email/getting data from the web/etc'.

Hope I was clear enough.

Gravatar for Brian Moon

Brian Moon Says:

@Johen, I have written daemons using PHP. They however, did not do high speed, low latency socket work to a client. They were more for churning data. I would not write a network daemon using PHP. I would use C. I may actually consider Node.js for such a thing.

Gravatar for Baptiste

Baptiste Says:

"If you are waiting on a DB call, you are waiting. I don't care what world you think you live in. You are waiting on that DB call"

Brian, clearly you've got no idea of how an event-driven environment might work. Waiting on an I/O operation (e.g. waiting for a response back from the DB) is a perfect opportunity for a single-threaded event-driven application to do something else.

Gravatar for Asad

Asad Says:

I think node applications can do multithreaded, they can do secondary processes thats forsure, to make use of all of your cpu cores are banged for the buck...

but again its a flame war, its about whats the better tool for the job...I use both, PHP for the main app and business logic, and Nodejs for commet or websocket or even ajax callbacks...

nodejs is nto good with big string themeing in it is not as performant.

Gravatar for Brian Moon

Brian Moon Says:

Event driven !== parallel. Doing things in random order does not mean you were doing them at the same time. While that code was parsing response 1, it could not read in response 2. It is single threaded. It can not by definition do two things at the same time. You can easily achieve the same with Gearman AND have all that work done on other servers in true parallel.

Gravatar for Says:

You may have more reasons to become happy as possible choose from a number of beautiful works of art. Let like to speak within his individual abode When you wish your beloved to consider you each and every moment, whether resting about the leisurely hours inside your living space, let which lovely piece of art covering that congratulations up walls to speak a lot of words quietly.

Add A Comment

Your Name:

Your Email:

Your URL:

Your Comment: