As someone who has spent the last six months coding in Node.js, I completely disagree with this notion.<p>One of my favorite advantages of Node is in fact that it is based on javascript. When building my application I can share code between client/sever side (string formatting methods for example) and don't need to do any mental context switching when it comes to languages. I've developed in javascript for years and all that I have learned doesn't go out the window here, all I need to do is learn how to use a few libraries.<p>The "faults" of javascript are primarily inexperience with event looped architectures that use callbacks (people complaining about having to use callbacks and the spaghetti code messes they make), people remembering the past horrible browser implementations of it (where something would work/be fast in one browser and not another ... Internet Explorer I'm looking at you) and confusion over how prototypical languages work vs. standard OOP.<p>Callbacks aren't that bad and a few extra nesting levels shouldn't create chaos in your code. Since its based entirely off of one javascript implementation (V8) the cross browser stuff is gone. How it handles OOP is different, just watch these videos first and you'll be fine: <a href="http://www.yuiblog.com/blog/2007/01/24/video-crockford-tjpl/" rel="nofollow">http://www.yuiblog.com/blog/2007/01/24/video-crockford-tjpl/</a><p>As far as speed goes it gets huge benefits by being javascript. Every time the Google coding machine feels like making V8 a little faster, Node gets faster too.<p>Yes its different, no its not worse ... its better but takes some getting used to.
<i>Why would you write this: [long_io_operation with callback]
When you can instead write this: [long_io_operation without callback]</i><p>Off the top of my head, I'd say because "var result = long_io_operation(req);" is not only not self-documenting but actively <i>deceptive</i> if long_io_operation is an asynchronous call.<p>I'm not sure I see what's to be gained by pretending closures don't exist.
Since fogus is responding here: Other than hitching your wagon onto the fantastic hype storm that Node.js has generated, which I must say is a good move overall, reading your target description, why not start with Haskell or Erlang? You could start from there and mutate out but actually have a library base to start from. Or one of the languages sitting on top of Erlang like Reia. (Or discover that you don't need to mutate away after all.)<p>Starting from scratch is going to be difficult at this point; by the time you even have a half-decent stack you're going to be way behind.<p>(At the very least... you <i>do</i> realize this has been done and you don't have to start from scratch, right? Rather a lot of Node.js users have exactly the cognitive holes I'd expect from not knowing that Node.js is at best "keeping up", rather than being anything like cutting edge. And I'd say this style of programming was actually on its way to the dust heap of history before being brushed off and gotten a shiny new coat of paint sprayed on... it really doesn't work very well....)
I prefer coffee-script. It also works in the browser.<p><a href="http://jashkenas.github.com/coffee-script/" rel="nofollow">http://jashkenas.github.com/coffee-script/</a>
"My problem with Javascript has always been that expertise is defined more in terms of understanding its faults rather than its features."<p>That's mostly just true for browsers. Javascript itself has very few faults.<p>My biggest annoyances with the language are: Lack of lexical scope, no trailing commas and semicolon usage that differs from C.<p>I could complain all day about my annoyances with browsers (or just IE).
My greatest hope is that the makers of node.js will continue to abstain from language changes. Some inconvenient syntax is a small price to pay for the confidence that node.js isn't going to get turned into another regurgitation of Java meets Perl by hordes of perfectly well meaning but unsatisfiable programmers who want everything to work like the things they know. I don't mean to insult the makers or users of other languages, just to highlight the distinction of Javascript.
Fix the language, then fix event processing approach, then spend 10 yeard maturing in the highly concurrent environments and end up being Erlang. w00t.
Take a look at this, I am sure it has been posted on HN before:
<a href="http://beamjs.org/" rel="nofollow">http://beamjs.org/</a><p>This allows you to trade off all the cool speed of V8, but running node.js singlethreaded, for running on an alpha port of V8 for the Beam VM. If you want to sidestep the problems with Node.js, but keep the good parts, this might be a way forward.
Additionally, JS on the Beam VM can seamlessly interact with any other Erlang code, so you get all kinds of other benefits that are erlangy.
Don't get me wrong, this could end up being the best thing since sliced bread, but the advantage of closures is that a higher-order approach can work wonders. Just take a look at async.js.<p>For me, more interesting than a pure assault on callbacks would be to see if you could handle more asynchronous scenarios, using async.js as a baseline.<p>e.g. callback waterfall, callback when all children are finished, callback when any children are finished
Not sure why he uses this as a code sample, as it's also not how someone would write code (though I suppose he is entitled to his style).<p><i>The original from the article</i><p><pre><code> function do_request(req) {
return long_io_operation(
req,
callback=function(results) {
return create_something_from(results);
});
}
</code></pre>
<i>How it might be written if you saw it in a codebase</i><p><pre><code> function do_request(req, callback) {
long_io_operation(req, function(err, results) {
callback(err, create_something_from(results));
});
}
</code></pre>
It seems like the article is not finished, so I can understand that there might be questionable sections. Also you'll note that he forgot the `error, results` argument pattern for callbacks, making me think that he is not terribly familiar with node.
all I'm asking for with Javascript is a shorter function keyword. Let me have<p>dosomethingasync(f() { });<p>With a language so dependent on callbacks, anonymous function are so verbose.
I'm all for a new version of Javascript that eliminates the junk and keeps just the "Good Parts", but I'm averse to anything that serves to abstract away the bad parts by building a subset of functionality on top of the existing version javascript for a niche application (server framework in this case, other cases include cappuccino for UI, coffeescript for...everything? etc.)<p><i>The Javascript that can be used only via add-ons is not the eternal Javascript...</i>
How about Node.as? Flash doesn't get much love these days but I've always thought ActionScript 3 would make a great server side language. It's more like other OOP languages, has an event model like JavaScript (sync or async), and doesn't have many of JS's idiosyncrasies.<p>Edit: <a href="http://haxe.org/" rel="nofollow">http://haxe.org/</a> is based on AS3