Awesome response by Paddy. +Infinity, and also beer next time we're in a pub
On 17 April 2012 00:54, Paddy Byers <[email protected]> wrote: > 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 > -- Richard Marr -- 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
