> if you understand plain old callbacks, you won't have any trouble reading > code written with the async module.
Ha-ha, yea, "you don't like callbacks because you don't understand how to work with it!". You may want callbacks in network layer, but definitely not in the business logic. The funny thing is - in most web project 90% of code base is business logic when you don't need callbacks at all :) What even more funny - it seems that node.js doesn't give you significant speedup compared to Ruby on Rails in classical Web App (classical request/response apps, without realtime or 10k connections). So, you get extra complexities with callbacks in return for nothing (a very little performance boost). P.S. I'm not against the node, I'm against accepting bad thing as if it's a good thing. Callback is a bad thing (for most of the projects, you don't write network optimised stuff everyday, usually you work more or less with plain old classical webapps), sadly, there's no better ways currently, and we have to use it, but we shouldn't fool ourselves into believing that it's a good thing. On Friday, 19 September 2014 00:22:46 UTC+4, Tom Boutell 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] > <javascript:>> 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] <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/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 > -- 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/16d1698f-8b38-4953-aaa9-5973fc856c78%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
