The only time I've really had this problem was in initialization code before the http server started accepting requests, as that's pretty much the only place you can get away with synchronous I/O in a web server app. I wanted to compile LESS CSS as part of the process, and its compilation method is asynchronous (due to how it handles includes). It was quite a pain, and made more difficult by the fact that it can be hard to figure out what code is affected by a change like that in javascript.
The code that handles requests is so tainted with I/O calls that most of it's in async form already, so I think this is less of a concern for apps that are already I/O intensive. But after getting burned a couple times you'll probably start off writing sync code in async style. And maybe you'll even use fibers to not have to pay the callback penalty, or maybe you're in a situation where you don't need to worry about lots of callbacks. Chris On Mar 19, 9:01 pm, Andy <delvarwo...@gmail.com> wrote: > But isn't it a big hassle when you have a function that calls a function, > and maybe those functions call 5 more functions, and only the deepest one > needs a callback, so now the 5 functions above it, even though not doing > any asynchronous work, need callbacks as well? -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
