3 ms·

Looks at correct-mkdir. Sees "cb = dezalgo(cb)". https://www.npmjs.com/package/dezalgo https://www.npmjs.com/package/dezalgo "Contain async insanity so that th

Looks at correct-mkdir. Sees "cb = dezalgo(cb)". https://www.npmjs.com/package/dezalgo https://www.npmjs.com/package/dezalgo "Contain async insanity so that the dark pony lord doesn't eat souls" Just... What. I feel like when you need to reach for tools to "contain insanity", you might want to backup and ask someone who has written to a filesystem before... The linked blog about "preventing the release of Zalgo" and the linked https://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/ https://blog.ometer.com/2011/07/24/callbacks-synchronous-and... seem completely erroneous. The entire point of callbacks is to _surrender_ control to a function - here is a piece of code to run when you are ready - now, sometime, or never, or maybe many times, as you see fit. Waiting until the next process tick seems so completely unnecessary... This strikes me heavily as "a solution in desperate search of a problem" - although I have that feeling with a _lot_ of NodeJS code I read... The author of the blog linked on the dezalgo project seems to, at the end of the post, imply the purpose is for performance? By deferring work until a later date? "The basic point here is that “async” is not some magic mustard you smear all over your API to make it fast. Asynchronous APIs do not go faster. They go slower. However, they prevent other parts of the program from having to wait for them, so overall program performance can be improved." Other parts of the program _other than the work we've asked it to do_? What if we're only "correctly making" one directory? So we intentionally make our code slower... So that "other code" can run? He continues: "This makes the API a bit trickier to use, because the caller has to know to detect the error state. If it’s very rare, then there’s a chance that they might get surprised in production the first time it fails. This is a communication problem, like most API design concerns, but if performance is critical, it may be worth the hit to avoid artificial deferrals in the common cases." So it's slower -and- more complicated, and we're gonna hide it behind a meme. Gotcha.

fenwick67 9y ago
Deferring until next tick is one way to get around call stack problems. If you create a really big series of callbacks which will call other callbacks which call other callbacks... you can run out of call stack. The other issue is let's say you have some code like... var f = 1 doSomeOperation(function done(){ console.log(f) }) f = 5 If doSomeOperation calls done() sometimes syncronously and sometimes asynchronously, it will sometimes log 1 and sometimes log 5. If doSomeOperation always works one way it's more consistent. It's not a perf thing it's just consistency.

fenwick67 9y ago

Deferring until next tick is one way to get around call stack problems. If you create a really big series of callbacks which will call other callbacks which call other callbacks... you can run out of call stack. The other issue is let's say you have some code like... var f = 1 doSomeOperation(function done(){ console.log(f) }) f = 5 If doSomeOperation calls done() sometimes syncronously and sometimes asynchronously, it will sometimes log 1 and sometimes log 5. If doSomeOperation always works one way it's more consistent. It's not a perf thing it's just consistency.