For one thing, client and server share only a small part of the overall functionality. Usually the database interfacing on the server and the user interfacing on the client will require substantially different code.
For another point, Python, Ruby and even PHP come with a lot of available packages and libraries. Node.js has lots of them too, but generally I prefer Django's API design to be more pleasant to work with than node.js
So, from my perspective, I like server-side js more than PHP and I think it will continue to grow and improve.
One language, one toolset
The use of a single platform on the client and server means that developer skills will transfer more easily from client to server work. This can lead to more consistent project quality and easier developer scheduling.
DOM and library portability
Node.js and asynchronicity
For more background on event-based server programming, read up on Twisted and libevent, and read the classic papers "Threads: Threat or Menace?", "Why Threads Are a Bad Idea (For Most Purposes)", and "Threads Considered Harmful".
Source : http://www.quora.com/Why-would-someone-want-to-build-an-enti...
In my perspective lack of threads is a blessing because it takes this complexity out of the equation.
On the other hand, working with async callbacks also takes training and more careful thought of the bindings and closures.
I'm not sure I'd say that, I talked with a few companies that were doing it in the early 2000s, but it wasn't exactly widespread. I vaguely remember at the time the only interpreter was available for Windows, and maybe not a *NIX-like platform so it wasn't really moving.
note: version 1.0 is from 1994
Where in node.js, a vaguely procedural programming pattern is usually adhered to, Twisted uses a lot of objects with state to manage protocols and business logic. Many of these objects will adhere to various pre-defined interfaces within Twisted, especially when they are directly dealing with network protocols.
This means that when you're implementing that new protobuf-based protocol, you will always subclass Protocol or one of the simple Protocol subclasses in twisted.protocols.basic, implementing dataReceived() (or the relevant message-oriented function for your subclass), then create a subclass of Factory to create these protocols, then, when you want to connect, you hook up the Factory to an Endpoint.
"Callback hell" is thus mitigated by the fact that you will typically name every callback as a method on the object, and each callback can be as short as a few lines. You also don't tend to bury yourself 6 layers down waiting for a read; instead, you store a bit of state on the object, and wait for dataReceived() (or your buffer-emptying callback) to be called again.
In cases where it's still hell, for whatever reason, the @defer.inlineCallbacks decorator will help by allowing you to write code like this:
result = yield somethingThatReturnsDeferred()
result2 = yield somethingElse(result)