5 ms·
I write and prefer libraries written in error-first callback, continuation-passing style. I also prefer `require()` to new `import`. Those choices have rather l
by kemitchell 10y ago
I write and prefer libraries written in error-first callback, continuation-passing style. I also prefer `require()` to new `import`. Those choices have rather little to do with backwards compatibility, from my point of view. I think they are better choices, which just so happened to be the norm before ECMAScript began to change again. Opinions differ, and will differ, forever and ever, amen.
Maybe we can all agree that experience in other languages leaves ECMAScript with much to be desired. Whether the changes ES6 hath wrought and ES7 and friends portend bode ill or well is likewise up for debate. So are the one-trueness of futures, specialized async syntax, and static typing. Those aren't either-or kinds of debates as far as ECMAScript is concerned. ECMAScript could be more Scheme-like, more Java-like, more ML-like. I've forgotten to mention some other disappointed camp. Forgive me!
If specific judgments on those kinds of controversies unify a culture, there is no unified culture of Node.js, any more than there is a unified culture of C or Java or English punctuation. The only unity is that standards-compliant ECMAScript runtimes are everywhere and we all want to use them. As long as different tastes are at least sufficiently well specified, we've a fighting chance of automating adapters. So I'd argue promisifiers and depromisifiers might be the most important libraries of the moment, culturally speaking. But it's too much to ask of any broad and adaptable common platform or library to hide the fact that tastes and approaches differ.
- kpil 10y ago[There are] standards-compliant ECMAScript runtimes everywhere and we all dream that it had been scheme instead. Fixed that for you.
- deleted 10y ago[deleted]
- kemitchell 10y agoI'd be happier with a Scheme-ier JavaScript, and I'm not alone, but that's not everybody.
- stiGGG 10y agoThe other ones do not know what that means?
- kpil 10y agoA [crappy] religion teacher once tried to convince me; Everyone longs for salvation - only some does it unconsciously, without knowing it. Maybe he was right all along, but was actually talking about scheme. (I can't just let go that it was soooo close that we would not had to suffer in the javascript wastelands.)
- a-saleh 10y agoAny specific reason why do you prefer the "error-first callback, continuation-passing style" libraries to ones using promises?
- kemitchell 10y agoA few specific reasons, but none unique to me personally.
- spion 10y agoWould you kindly share them? I have a few reasons why node-style callbacks are absolutely the worst possible choice, so I'd like to compare. Here are some: 1. Not values. Values can participate in expressions, can be passed as arguments to functions, can be returned as values from functions, can be stored in variables, arrays, etc. There are no values with node-style callbacks. You are throwing away half of the language capabilities regarding values and expressions. 2. No guarantees. Callback may be called multiple times. It may be called synchronously or asynchronously. There is no way to know what will happen. 3. Bad semantics for thrown errors. Its assumed that thrown errors will simply crash the process. This is a dealbreaker in node because every uncaught thrown error provides a vector for denial of service attacks, and the thrown error semantics of most libraries and the standard node library are pretty bad.
- a-saleh 10y agoThat is why I would like to hear them :-) I know most people use Promises to escape the call-back hell, but you can do that with async library as well, so maybe you just like writing "return cb(err);" more than "return Promise.reject(err);" Maybe you like, that you need to deal with the err in the call-back, while \w promises it is easy to write code that just silently fails?
- Yaggo 10y agoI also prefer callbacks. Here are my reasons: - They are simple (fully transparent) - They are the simplest good enough solution for many problems - Cleaner code than new Promise().then().then().then().catch() clutter - Yes, I like nested indentations (good functions are short anyway) - They perform well As a side note, I also prefer coffeescript, snake_case, CONSTANTS, and avoid using classes, prototypes, and this. I'm not very happy with the recent development of EcmaScript, too much complexity and unnecessary new concepts.