Hi, As the starter of this thread that sums it all up for me. Just look at how > long this thread is with people waring back and forth it's really silly. I > have basically given up and found this list to be of no help with my > question. With so many different approaches, I have no idea what one to > use and am left with the same question I started with. >
That's really disappointing. I'm fairly new to this but here's my input. I've not used fibers or streamline or promises or any of those frameworks but I'm happily writing code based on callbacks. I've also recently been migrating quite a bit of code originally written for a threaded, blocking, style, to node. First, above everything else, don't write code that you don't understand. Unless you really know what these frameworks are doing on your behalf, don't just use them blindly. By all means research them and understand what they're doing, but until you've spent a bit of time writing simple callback-based code, you're unlikely to get most of the subtleties and complexities of what they're doing. Second, really appreciate the differences between node's single-threaded, async but non-preemptive execution model, and other conventional synchronous and threaded environments. Understand where the non-preemptive nature really helps you and where the async nature can trip you up. Comparing threaded code in java (say) and async code in node you will really appreciate where the absence of pre-emption helps you. No more locking, deciding what you need to lock, and in what order. Now try to write what you want to write, but use the async style. If you really find yourself in callback hell, my suggestion would be that you've not got enough state in your code. Add more state; make sure every async event has a clear consequence in terms of that state. For every nested sequence of callbacks, there's probably some state you can introduce that helps you reduce or eliminate the complexity. When we write conventional sequences of statements in a synchronous and blocking environment, there's really a lot of state that's just implicit in where you are in your program and your call stack. You have to distill this implicit state into explicit state. When you do this, you find you're considering how unexpected events impact your state, as well as the expected ones. When you write a simple sequence of blocking statements, you know the sequence of events; but in the async case things can happen that aren't in the anticipated sequence. The risk with the "sequentialise everything" frameworks is that they give you the illusion that things happen in the anticipated order, when in fact each time the event loop is idle then any pending event can occur. (I say this from a position of ignorance, not having used them .. but that would be my worry.) Then you know everything to decide for yourself whether or not to use another framework. By all means use it if it helps you do stuff that you would written "longhand" before. Writing less is good, understanding or anticipating less is bad. Many of the other comments here are also valid; you have more latitude if you're writing application code than library code; name functions where it helps instead of just using anonymous functions. There are times, such as when your application is starting up, where using sync blocking functions is OK, because blocking the event loop won't hurt you, and you probably are in complete control of the sequence of what's going on. Your freedom might also be affected by who has to maintain what you write. Please don't be put off. You're going through the same learning curve that everyone else here is. You'll get a lot of constructive help if you come back with more concrete questions, but you were unlucky to pick a question that has a long tradition of kicking off a religious war :) Good luck. Paddy -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
