Live data from Hacker News

Is NodeJS Wrong?

ncannasse.fr

1–10 of 47 posts

Re: Is NodeJS Wrong?

#2
This is a bit annoying since if you want to make three async requests you have to write the following

Well, beyond a style issue. You can unfold the events and make it a lot less "annoying".

Consider,

var cb1 = function() {

}

var cb2 = function() {

  req(cb1);
}

var cb3 = function() {

  req(cb2);
}

req(cb3);

It's a lot cleaner and it looks like a state machine (and kind of looks like erlang/message passing).

Re: Is NodeJS Wrong?

#3

This is a bit annoying since if you want to make three async requests you have to write the following Well, beyond a style issue. You can unfold the events and make it a lot less "annoying". Consider, var cb1 = function() { } var cb2 = function() { req(cb1); } var cb3 = function() { req(cb2); } req(cb3); It's a lot cleaner and it looks like a state machine (and kind of looks like erlang/message passing).

Another way is to have an array of functions and just loop||recurse through them. This gives the illusion of serial execution.

There are actually a number of other ways to get around the function nesting issue as well.

Re: Is NodeJS Wrong?

#5
Several commenters point out that long-running computations can be performed outside the main request thread without the server having to do anything special.

It's also possible to divide up long-running computations oneself. This can lead to very interesting designs.

Re: Is NodeJS Wrong?

#7
Can anyone suggest a better architecture than that of node.js for a server side Javascript application engine?

Perhaps still using Google V8 but maybe being more intelligent about threading/multicore, maybe using something like gearman (gearman.org) to distribute tasks, and addressing some of the criticisms of node.js but still maintaining good performance.

Re: Is NodeJS Wrong?

#8
Given any long-running task, there are two natural things to do:

  1. Do something while the long-running task is running
  2. Do something after the long-running task has completed
Node.js' callback function convention simply makes it stupendously easy for you to write code for both cases, and leans towards making case (1) as natural as possible. Case (2) is naturally easy in Javascript (and even easier in Coffeescript) because of the way Javascript supports closures.

  application = function() {
    // do stuff
    database_call( options, function(err, callback) { // javascript closure
      // case (2) logic
    } );
    // case (1) logic
  }
How does Tora fare on this regard? Node.js is about parallelism through forking closures, not any solution to long running CPU intensive tasks.

The weakpoints of Node.js, in my opinion (and please correct me if I'm wrong, that would make me happy), is having to write a lot of boilerplate code for error and exception handling. Exception handling is particularly onerous because depending on the function call you'll never know which stack the exception will travel up. In the example above, you (probably) can't catch an exception from case (2) by wrapping the database_call in a try-catch block. Does anyone have a good solution to this?

All-in-all, I like that Node.js tries to stay pure by enforcing the above convention. Noders who stay in "userland" can't shoot themselves in the foot by making an asynchronous procedure synchronous, which may lead to faster code overall.

Re: Is NodeJS Wrong?

#9
post #8

Given any long-running task, there are two natural things to do: 1. Do something while the long-running task is running 2. Do something after the long-running task has completed Node.js' callback function convention simply makes it stupendously easy for you to write code for both cases, and leans towards making case (1) as natural as possible. Case (2) is naturally easy in Javascript (and even easier in Coffeescript)…

To me, it seems the real weakness of node.js is having to manage asynchronous control flow yourself, at all. It grows exponentially more ugly as the system increases in size. I really like continuation-passing-style as a technique (especially as a compiler IR), but doing that stuff by hand is so 70s.

I got pretty far along writing a similar system in Lua (because, hey, event-driven systems are pretty nice), and unlike Javascript, Lua has well-implemented coroutines - they singlehandedly eliminate a LOT of the ugly control flow management. Still, most libraries are blocking* . I eventually decided that, for small systems, an event-loop framework wasn't necessary in Lua (it's easy enough to just do it from scratch!), and for larger systems, I was better off using Erlang, which has the ideal foundation for that sort of system. In particular, I'm really not clear how much error-handling node.js does; that was what convinced me that Erlang's approach is refreshingly sane. When I started writing process-supervision and hot update code in Lua, I realized I was just re-implementing what Erlang does best.

* Which is a funny objection, like being mad that most libraries default to using decimal numbers rather than octal. It must be a conspiracy!

See also: http://news.ycombinator.com/item?id=2150800 and http://news.ycombinator.com/item?id=1304599

Post reply on HN