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] > <javascript:>> 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 > > > > -- > > > 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/dd788333-b998-4e32-b047-b67ea4add34b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
