Asynchronous programming isn't a hell :/

Apache2 servers are capable of running multiple PHP programs at the same time. The difference between JavaScript servers and Apache2 servers is that JavaScript servers can run only one program process, but execute code from different parts of the program at the same time. Where Apache2 typically chooses to run several synchronous programs at the same time, instead. The result usually leads to Apache2 taking longer to accomplish the same task as a JavaScript server. Comparing JavaScript servers to multiple PHP programs running under Apache2 is like comparing an apple to a bag of pears. I mean, of course the bag of pears will be heavier than the apple. The impressive point is that the single apple is just as nutritious as that particular bag of pears- and easier to hold, too! Now, some people argue whether or not Asynchronous programming is harder than synchronous programming. That is opinion. Are you doing asynchronous programming in Apache2? Yes, you are- regardless of whether or not you notice you are- If two people request the same URL which tells Apache2 to run two instances of the same PHP program at the same time- then Apache2 will happily run them both at the same time. In my opinion it doesn't matter that much which is faster to execute- My main goal is to meet development time requirements.

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:
Which Lord of the Rings character is JavaScript? I think JavaScript is the Wizard. With the ability to fly under the radar for so long disguised as a Document Object Model for HTML, and suddenly come into the web development world as (not a major part) an essential part of the big picture without changing much at all from it's original release, you'd have to be a wizard to do that. Something with more power than PHP or C or Poptart or w/e it's called.

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

phpclasses.org/blog/post/61-File-up ...

As for JavaScript, as I said in the article, I would compare it to a Hobbit too. It is just not better for us to switch from PHP to JavaScript on the server side because of the asynchronous programming hell, in my opinion of course.