Spencer Andrew Lockhart
Something like a progress bar for streaming large media files, or an impressive set of ajax rules, or web sockets is very hard to do with Apache2. Doing it with Node is rather trivial. Creating a static HTML web-site with Apache2 is easy enough for children to pick up the basics enough to build a site. Doing the same with Node.JS requires a high level of knowledge. That being said, I don't think Apache2 and PHP+MySQL is going anywhere anytime soon. I do think that Node.JS will become more popular, but not to the extent of PHP, because it doesn't apply to beginners. Now, a good beginner-friendly server coded in Node.JS (equipped with a shared-hosting tool, of course) may take the place of Apache2 someday in the future, but it would have to be at a minimum, more beginner-friendly than PHP and Apache2- enough that cheap hosting companies will buy into it like they did cPanel. Apache2 can't hang around forever.. Perhaps we'll see a web-server war by the time Apache3 comes out and there comes a time for the massive pool of shared-hosting providers to choose new software.
So, with all that said:
|2013-02-18 23:20:40 - In reply to message 1 from Spencer Andrew Lockhart|
|I know Web servers handle asynchronous event, but the problem is not Web servers do, but rather when you have to deal with asynchronous events in your code.|
When I am talking about asynchronous programming being a hell is that every time you need to access a file, a database, a network server, etc. I need to write the code to deal with the responses or errors in the damn callback functions.
The problem is that it complicates matters when you need to execute an action depending on a condition that is evaluated inside the callback. It is a different scope, so you need to figure how to access variables from one scope with the other. You usually end up nesting callback functions.
And loops may get worse because if the loop condition is evaluated inside the callback function, you may need to use recursion to iterate. That is dangerous because deep recursion may cause stack overflows or otherwise consume a lot of memory to save the context.
Anyway, I do not agree that asynchronous servers like Node.js may always run your page scripts faster. Often is quite the opposite. For instance, if a script has execute a CPU intensive task, like for instance rescaling an image that was uploaded, while it is doing that, all Web server requests are halted and no response is sent back to the browsers until the CPU intensive task ends. In that case page scripts are slower because they are stoping each other.
What Node.js allows is to deal with many parallel requests eventually with less memory. That is fine as long as those parallel requests only perform I/O operations like file access, database access, network access.
If your page scripts do other CPU intensive tasks, a multi-threading server is more adequate. That is what Facebook HipHop uses.
Apache can work in multithreaded way using the worker mode, but that is not what most PHP site use. They usually use the pre-fork mode.
Pre-fork is more reliable, as unstable processes do not kill each other, but it may take more memory, as each process has its own memory pool. This limits the ability to serve more simultaneous requests per server machine. That is why Facebook uses a multi-threaded server, instead of the regular PHP and Apache in pre-fork mode.
As for file upload progress bars, it can be done perfectly without asynchronous servers. It is in use in this site and does not require multiple requests doing frequent polling to the server to see how far the upload went