(I don't disagree that "use callbacks to do five simple things consecutively" is a lot to ask and can be offputting and bug-prone. It absolutely is. I use sublimetext snippets to stay out of trouble, which means I'm effectively coding in a higher-level language with a really, really crude compiler (: )
On Thu, Sep 18, 2014 at 3:35 PM, Tom Boutell <[email protected]> wrote: > The async module is used pretty heavily; I would suggest that if you > understand plain old callbacks, you won't have any trouble reading > code written with the async module. It's just a way to do the common > async patterns more consistently and not get lost. > > Promises is a much bigger cognitive shift than the async module. > > More importantly though, if your module successfully implements its > advertised API, it doesn't matter what you use internally to implement > it. > > The API you advertise to the rest of the world is a more important > question. Generally you should be exporting methods like: > > doSomething(arg1, arg2, ..., callback) > > Where the callback expects to receive: > > err, ... > > And if err is falsey, nothing is wrong and the other arguments (if > any) can be safely examined. > > That much at least is extremely consistent in node. The only common > exception is streams, which are a viable option if you'll be inputting > or outputting a lot of data gradually over time. > > > On Thu, Sep 18, 2014 at 8:19 AM, Axel Kittenberger <[email protected]> wrote: >> As you can see this has always been and is still a controversial issue. >> >> The gospel is, callbacks are fine and you are wrong. Somethings are still >> going to be fixed with domains etc. >> >> I think the misunderstandings is due to the fact on the level of >> complication of stuff being handled. Some people just push some streams >> through and need high effectiveness others do stuff that is already >> complicated enough by itself. >> >> My first larger project I did with node was scientific analysis of data >> collected in a mongodb database -- controlled by a user via a web interface. >> Thus I personally never bought into that gospel. Things were complicated >> enough without having to wrap my head around callback issues, and being able >> to request several items at the same time from database could speed up >> stuff, it didn't really matter that much. I changed the project on the fly >> to Bruno's streamline which rescued it (otherwise I'd had to redo it with >> something completely different, it wasn't manageable anymore) >> >> I also know of friends whom I tried to convince how awesome node is of which >> I know that turned it down due to callbacks. >> >> Node has recently lost one of its main contributors due to callback issues. >> And no, promises and flow control libraries didn't cut it. His main point I >> understood was, bugs caused by misbehaving libraries that fail to call a >> callback or even worse, call it twice, are extremely hard to debug. >> >> Right now I'm using suspend, >> https://github.com/jmar777/suspend >> which takes advantage of harmony generators. >> >> I like it, since it is the most reliable on getting backtraces in case of an >> error. Bruno's stuff should generate backtraces too, but I had issues in >> case of rethrowing catched errors. On the other hand, suspend and generators >> are little more try on when to put a * and when not, and result into hangups >> if you do it wrongly, while Brunos preprocessor proofed to be very reliable >> in pointing out a variety of coding errors. >> >> My advice is, if you do a library that is to be used by others, you ought to >> use simple callbacks, as this is still the lingua franca in node world. >> >> What you do inside is up to you and if you do an application or anything >> that is not a library to be used by others, there is no definitive answer, >> do not listen to the gospel, try things out, look what works best for you. >> >> -- >> Job board: http://jobs.nodejs.org/ >> New group rules: >> https://gist.github.com/othiym23/9886289#file-moderation-policy-md >> Old group rules: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "nodejs" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/nodejs/wBAJhYOzjqQ/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/nodejs/CABg07fvC_5vKW3vNdJ86FW%2BBu4AXX%3DxzJ%2B%2BmaQOVO%2BRa2NAW5w%40mail.gmail.com. >> >> For more options, visit https://groups.google.com/d/optout. > > > > -- > > > THOMAS BOUTELL, DEV & OPS > P'UNK AVENUE | (215) 755-1330 | punkave.com -- THOMAS BOUTELL, DEV & OPS P'UNK AVENUE | (215) 755-1330 | punkave.com -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAORXhGJ%3DfH0GnNRz4Ff-ee-zQ501bLKpT%3D%3DevNGN5S6AoweuMQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
