I modded this submission up not because I agree with it but because I want a discussion. The G-WAN author has been known being... confident. He claims to be faster and more scalable than Nginx by a significant factor. He attributes the speed partially to the fact that his code contains few branches, where he defines even function calls as branches. Both statements are bold claims, and I can only imagine how it would take a genius to maintain "branchless" code like that.<p>Leaving that aside, I feel that the article focuses too much on the hype words. Yes some of the hype is over the top and focuses too much on the coolness factor, yes some of the reasons given for using Node is total nonsense (e.g. what he quoted from the Wikipedia article). But none of that invalidates the valid reasons for choosing Node:<p>- Javascript is so much easier to program for than C/C++. This is a fact; he mentioned it several times in his article but then brushes off these claims. Writing Phusion Passenger 4's new evented architecture in C++ has been an extremely intensive effort. There's just so much you need to be aware of and take care of, Javascript would have speeded up development significantly. If course we couldn't and didn't: being system software, Phusion Passenger's core cannot rely on Javascript and must be optimized for speed.<p>- Javascript is <i>fast enough</i> for quite a lot of server software. Of course C wipes the floor with everything. If you don't mind spending 4 times longer to ship your product to market. Oh yeah, good luck recruiting that brilliant C programmer, I hope you live in a place where they are easy to come by. His bold claim that G-WAN's Javascript engine uses 2444x less resources is a bold one, but if in the end you have 2 million users and you can still handle them with 1 or 2 servers, then switching to G-WAN does not give you a lot of added advantage.<p>- G-WAN runs everything in-process!! Of course everything is faster then!!! It's because there's no need to perform inter-process communication and CPU synchronization, which often require (relatively slow) kernel intervention. But if one component dies, your entire web server goes down. Better hope the application programmer never makes a mistake. With Phusion Passenger we've explicitly chosen not to utilize an in-process architecture because it causes to much pain, even if it's faster.<p>There's also at least one logical fallacy in the article:<p>_"Node.js' CPU & RAM usage is so high that the scale had to be resized. The chaotic curves do not give the feeling of anything seriously engineered."_<p>He puts two separate scales in the same graph and then claims this? That doesn't make any sense.<p>Where is the source code for the benchmark? How did the benchmark look like and what's the methodology? No mention of it.<p>I wish the G-WAN author would focus more on the technicalities instead of trying to fight the hype. That would make the entire article much more interesting. Why is G-WAN faster? What's the difference between Node and G-WAN's Javascript engine? Etcetera. G-WAN is a very interesting product but it would have so much more potential if the author communicates in a less inflammatory and emotional way, and behaves more professionally.