Hacker News Reader

Comment by swannodette | Hacker News Reader

I'm excited about it. But I think the verdict's out on whether a medium to large Node.js program will not be a steaming spaghetti shaped pile of callbacks. Nothing I've seen coming from the Node.js community seems to address the fact that debugging/refactoring callback heavy code is hellish. Pretty please point me to literature/code that shows otherwise.

For small nuggets of async goodness Node.js looks great.

View on HN

Lessons learned from somebody who wrote a pretty large node app and is almost done with a rewrite:

* Yes, async coding is hard.

* Debugging can be tough, but good coding helps.

* 95% of most node apps will be pure JS that does not perform any I/O.

* Test driven development really shines in combination with node

Make sure you keep that last point in mind when you build something with node. Reasoning about async code can be tricky, but TDD will force designs upon you that make it simple.

--fg

I suspect we'll see people building better abstractions on top of the raw callback APIs Node provides. "Promises" (similar to deferreds/futures), um, promise to help with this.

I think Promises were removed recently.

Correct, but they can still be implemented on top of the callback based APIs.

They already are: http://github.com/kriszyp/node-promise

promises need to be build into the language and all libraries have to be build with promises in mind for this to work. Look at io-lang's @ syntax or for a slightly different ( much better ) take, look at go's channels.

Actually, a bunch of us are working on taking the pain out of async programming. Here's my approach, using (fab)'s chained continuations:

http://www.flickr.com/photos/tr4nslator/4532445014/in/set-72...

While this is cool, when you get to this point with JavaScript syntax why not just write your program in a Lisp like Clojure? People keep saying that JavaScript is good for asynchronous code, but that might not true at all. It's just that we JS hackers become very accustomed to a style of code that works great for simple user-driven events. In my experience this does not scale for much else.

Maybe we can make it work, but I don't like what I've seen thus far. I want people to adopt a syntax that doesn't affect standard JS style: http://mootools.net/shell/q9ASd/28/

Because I'd rather write my programs in a Lisp like Javascript?

Reply on news.ycombinator.com