[thalesmello]

I particularly don't find the problem it solves appealing. The power of Node comes specifically from its everything async programming model, Javascript is just a detail.

So what's the point in taking away the good part, and keep the cumbersome one? If you just want to program a Synchronous server in the JVM,just stick to Java.

[_pmf_]

> If you just want to program a Synchronous server in the JVM,just stick to Java.

And if you want to program an asynchronous server on the JVM in Java, all of the major and minor servers also support an asynchronous model (you merely lose the ability to program against the Servlet API, which pre-3 was bound to threads).

There's no reason at all to bring JS in for asynchronous behavior.

[sourcesmith]

There is also Vert.x which runs on the JVM but is event driven and asynchronous (as well as providing a reactive API) and supports JavaScript (http://vertx.io/docs/vertx-core/js/) as one of its languages.

[cel1ne]

I hope you don't mean the JVM by "the cumbersome part". It think is unparalleled in performance, garbage-collection, general dev-ops and monitoring capabilities.

You can run many different languages on it, all nicely contained within the virtual machine.

As far as I know Twitter replaced their Ruby/Rails with Code on top of the JVM for these reasons.

Also I don't think it's good to religiously stick to async/"just one thread" and sync/"one thread for everything". The most performant answer depends on the real world scenario and almost always lies somewhere in between.

[boggydepot]

I think he meant the js not java. Question about node js, So async model is the good part, js is the bad part, why use js then?

[my123]

The JVM is nowhere near as flexible as the CLR.

[amelius]

> The power of Node comes specifically from its everything async programming model, Javascript is just a detail.

I don't agree. The power of Node comes from being able to run the same code on the browser and the server (without transpiling performance penalties).