"Node.js runs everything in ‘parallel’, meaning that all of your tasks can be run at the same time. For example, let’s say you have a webpage that has 100 lines of code with 10 database calls. With a web server like Apache, these 10 database calls must be made in succession. While running node.js, you can run all 10 of these database calls at once, which makes the webpage load faster."

errr... maybe...

"Current web servers must open many connections to interact with their operating system (OS), while node.js only needs to open 1 connection. Each connection costs the system memory, so using fewer connections is more efficient and faster for the entire system."

there are many lightweight polling webservers like nginx, lighttpd etc

In programming or technical environments, there are literally thousands of factors that come into play, so to avoid the inclusion of all of them, I kept it brief.

Is there any different way you'd phrase the above?

Also I have no idea what you're talking about with 'connections to the OS'. Sounds like more FUD to me.

  The code that makes up node.js is carried out by the V8
  javascript engine.  This engine (read: the component that
  processes javascript so that it can be understood by your
  operating system) is the same one Google uses in Chrome,
  which makes the processing of node.js very, very fast.

"Node's goal is to provide an easy way to build scalable network programs. In the "hello world" web server example above, many client connections can be handled concurrently. Node tells the operating system (through epoll, kqueue, /dev/poll, or select) that it should be notified when a new connection is made, and then it goes to sleep. If someone new connects, then it executes the callback. Each connection is only a small heap allocation.

This is in contrast to today's more common concurrency model where OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use. See: this and this."

Definitely a good design decision, but as I say, not unique to node.js.

As long as there are no deliberate deceptions, and links are provided to resources that give a fuller picture, there is no problem. If all the resources surrounding a technology are written at the lowest possible level of understanding, that technology will never be able to gain traction outside the world of hackers.

to the OP: maybe add a disclaimer to the effect of "Some of these points are simplifications, please read on elsewhere if interested to find out more"

The only thing node.js does that other frameworks don't, is uses javascript as a language syntax.

In fact, Node.js isn't what I personally would call "non-blocking", as it only has the weakest form of it. Node.js has cooperative multitasking; writing an infinite loop still takes everything down. Erlang, Haskell, and a growing number of other languages have preemptive multitasking, while still having sane concurrency compared to lock-based threading; infinite loops are still bad but will only lock up that local-running-unit (thread, process, whatever). That's non-blocking; within reason (modulo bugs, deliberate hostile attempts, etc), nothing you do in one thread will block another.

If you need to shuffle various things around, Node.js is OK, but if you actually need to compute something that may take significant fractions of a second, you're going to have some sort of problem. Maybe that problem is bad latency on your other requests, maybe your problem is a sudden and bizarre need to chop up an otherwise-straightforward computation into many little pieces so other things get a chance to run which is easier said than done (chop too fine, lose performance, chop too coarse, lose latency on other responses, getting this right is very tricky), maybe you're going to have to manage worker OS processes, but it's going to poke out somewhere.

Again, I don't really have a problem with Node.js, but the hype needs to be taken out back and shot.

The companies providing value, creating profits are using old boring tried and tested unfashionable technology.

Actually, I'd disagree on both counts. V8 isn't faster than contemporary JavaScript engines anymore (although it's a tad faster than Safari's Nitro engine, perhaps). However, V8 is much faster than most of the other languages used for web development: Ruby, Python, PHP, and Perl. The only exception is Java.

Most languages can compile down to JVM byte code. I'd say the JVM is a pretty quick beast.

Unless you use Java, C, C++, etc you would do better with Node.js

Just take out the "runs everything in parallel" and replace it with "is able to handle more requests and events while it's waiting for slower operations to complete, such as a database query, whereas in the traditional model, each request is handled by a dedicated process, which must wait for each database query to complete before issuing the next one"

Question from a newbie: is there any disadvantage to polling?

Allow me to digress a little. When I look at the benchmark comparisons between Apache and the new, lightweight crowd that there is no way a modest static site could serve anything reasonable back in 1995.

I realize that in 1995 there was way less traffic, but some humble sites did get thousands of visits per hour. It looks like this can very well choke an Apache server with 2010 hardware!

I guess my question could be rephrased thus: Why didn't the Apache folks take this lightweight path fifteen years ago, when it mattered much more?

Any comments will be welcome.

http://code.google.com/p/v8/issues/detail?id=847

Also wonder what other bugs are going to emerge as a result of trying to use a client side app on the server.