PHP + Apache Stack vs Node.js

 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 PHPClasses.org, 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 tr

补充：Web开发 , php ,