After tasting the magic of ES6 generators (combined with promises or thunks), I never want to look again at the async module (or any other callback-based constructs).
On Saturday, September 20, 2014 7:04:32 AM UTC+3, Tom Boutell wrote: > > I think the async module results in readable code. It's just too verbose > to type. (: > On Sep 19, 2014 9:00 PM, "Alexey Petrushin" <[email protected] > <javascript:>> wrote: > >> The problem with sublime snippets is that most of the time you reading >> code or thinking and sadly there's no sublime snippets that helps you >> effectively read callback-heavy code :) >> >> On Friday, 19 September 2014 00:22:46 UTC+4, Tom Boutell wrote: >>> >>> (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 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/nodejs/dd788333-b998-4e32-b047-b67ea4add34b%40googlegroups.com >> >> <https://groups.google.com/d/msgid/nodejs/dd788333-b998-4e32-b047-b67ea4add34b%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/50de4bdb-7214-412e-a9e2-e844011bccd4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
