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.

Any specific reason why do you prefer the "error-first callback, continuation-passing style" libraries to ones using promises?

A few specific reasons, but none unique to me personally.

Would 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.

That 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?

I 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.

Give me any moderately complex callback-based code, and I'll make it look cleaner with promises and ES6.

And I'd like to know what you mean by "fully transparent"

Besides the last point I think I disagree on everything you have said :P

[There are] standards-compliant ECMAScript runtimes everywhere and we all dream that it had been scheme instead.

Fixed that for you.

I'd be happier with a Scheme-ier JavaScript, and I'm not alone, but that's not everybody.

The other ones do not know what that means?

A [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.)

While - in general - you are quite right, most of the bigger libraries that I use in production offer interfaces for both styles. Mongoose for instance. You can easily use it with Promises or with the old-school callback style. Same for unit test libraries. And this trend will only continue. There is a lot of cool research being done in combining JS with hardcore FP (fantasy-land, ramda) and this will of course influence future developments. Not to forget the FRP community around React/Bacon etc... I predict that in a year or two, the majority of devs will use Promises as if they always have been there.... And hey. Promises are Monads [1], so maybe we will also soon see a lot of Eithers and Maybes in Production code. I taught today a lecture about this at my company, and people with no prior exposure to FP immediately loved it.

Thats also one cool thing of the js/node community. We just adopt stuff and try it out. With microservices, this also poses no problem. If it doesn't work, do it differently in the next service.

[1] I know, I know. A+ Promises are violating some laws BUT the general idea holds. And there are full monadic promise libraries like Data.Task or Fluture available.

Callbacks and events are significantly faster than promises, and promises I think most see as a wrapper around callbacks, with convenience functions for running and waiting on multiple concurrent async functions.

If you want promises, just embrace promisify. I get a lot of this fear about error-first callbacks being only a "convention", but everything follows this convention in practice. Anything that can't be promisified because of that will likely have a pull request or a more popular fork that can.

I don't think node core libraries should be promise-based, and you can't expect the whole ecosystem to switch to promises if node core won't. At some point you have to jump to callback-style to live on node.

I also don't really understand what this post has to do with the release.

There is a way to support both styles at the same time, and most libraries (that I'm aware of) use it. If a callback is given, call it with the result. If not, return a promise for the result. This doesn't require a rewrite of existing libraries, but merely a new minor version.

I don't see how compile-time type checking would help here. When checking out a new library, I read the documentation, or maybe it's test suite, and then use it accordingly. My tests ensure that I use it correctly, i.e. give it types it understands, give it the right data (the id of the correct user account for example), and handle the outcome correctly (i.e. display it in the right format).

JavaScript has run-time type checking, which could be used for automatic promisification, but I agree that's a slippery road, for many reasons.

You don't know what you are talking about. Not _everyone_ is sticking to callbacks. Many (if not most) are now on promises or async/await.

Also you slipped in weasel language to disrespect JS developers. I have been coding for 30 years in wverything from assembly to C++ to C# to OCaml to now for the last several years mainly Node.js. Your comment was (reading between the lines) as close as you could get on Hacker News to spitting in my face.

Promisifying works fine. So do rewrites, as the language has evolved rapidly.

We do not actually have a big backwards compatibility problem.

Dynamic languages are dynamic.

I have to disagree with you regarding promisify. I think its part of the solution, not the problem - it forces libraries to actually adhere to conventions, otherwise they are not promisifyable.

We need something like promises to replace node streams too. We need streams with well defined semantics. Quick, what are the unpipe semantics for stream erors? Does a stream unpipe from its source? Will it unpipe synchronously or asynchronously? Can a stream emit an error synchronously when its created? At the next tick of the event loop? What about at the end of the same tick? Are these semantics defined anywhere? Which versions of node streams adhere to them? All is fuzzy.

We need to replace node streams and of all eventemitter-based streamlike stuff, badly.

Regarding types, you always have the option to add TypeScript into the mix.

I actually think using your promise library's promisify methods are best practice. Reason: there are multiple promise implementations with different methods available (e.g. the Bluebird library extends the promise/A standard significantly), and thus if libraries included promises, a conversion from whichever promise library the library was using to the promise library which you are using would be necessary, and this would be considerably less efficient.

I have to agree. It's the wild west. You just have to be prepared for things to break, and if you're lucky, they break early and reliably enough that you don't have Heisenbugs. I'd say it's a bit of dynamic language culture, overall. Although, perhaps Javascript sees a particular flavor of it, with its first-class, always-variadic functions.

It's all good for prototyping, but man, once you're up in production, dynamism is a recipe for pain. Granted, statically typed languages crash too, but the big difference is that you can often eliminate the same problem throughout your program by getting the type right, as opposed to trying to TDD bugs one at a time as they emerge.

I think you nailed it when you said, "there's no compiler to enforce it". Actually, maybe a compiler isn't the key word, but automated checks is the idea. A type-checking compiler is just one solution, albeit a pretty powerful one. Type inference makes it much less onerous these days. But even staunch dynamic language devs have come around to embrace the use of linters. So while it's often seemed that static and dynamic language users would always be at odds, perhaps a convergence is slowly happening.

> It's something that works most of the time, but sometimes breaks when the callback code isn't what the promisify function expected.

The sounds like a limitation of promisify, not inherently of callbacks. There are many situations and styles where callbacks are perfectly adequate, and promises offer no benefit, so referring to it as the "old callback style" may be a bit premature.

> There are many situations and styles where callbacks are perfectly adequate, and promises offer no benefit

Promises are superior in general, I guess that has been discussed already[1], many times. Promises may indeed offer just an insignificant benefit sometimes (you can even call it just a different style), for example when you are first writing a monolithic prototype. In this worst case, you would simply make a giant chain of ".then" methods, any your gain is you can get creative with the error handling if you want. However, the greatest benefit revels itself later: The composability that comes with them will help you immensely when refactoring.

[1]: One example: http://softwareengineering.stackexchange.com/a/302456/9451 Another: http://blog.parse.com/learn/engineering/whats-so-great-about...

Promises are not superior in general. There is a significant performance hit that, in some problem areas, absolutely should not be ignored. Neither of those links claims that promises are superior in general. They provide additional, valuable features, but with tradeoffs.

Well, I stand corrected. Yes, there definitely is a performance penalty for promises.

Performance may be a tradeoff for the current engines, but I'm optimistic that it will be optimized away as it doesn't add too much semantics over the callbacks. Maybe error handling is tricky.

I would say they are superior to callbacks as object-oriented code is to procedural code - that also has some performance cost in many engines.

But, you are saying tradeoffs - plural. I, as an experienced web developer, am sincerely curious what any other can be?

> as object-oriented code is to procedural code

That is not a universally-accepted statement either.

I'm not interested in taking sides here, only pointing out that there are a wider variety of extant opinions than you seem to realize.

That was exactly my point. Object-oriented code is conceptualized as a next step but there are indeed cases where you would be better off procedural and there are many people who like procedural just better. Maybe it's my poor English, would this be more clear: Promises are as superior as to callbacks as object-oriented code is to procedural code. (Ok now it's not very readable :) )

> [promisification is] something that works most of the time, but sometimes breaks when the callback code isn't what the promisify function expected

You're just saying that if you make a mistake and use it wrong it doesn't work. That applies to all code, not just promisify.

> Also, the library writers are not writing the code with any guarantees that promisify will always work. So even if it works now, it could break in the future.

That also applies to all code, not just promisify. If the author changes their API without a major version bump, that can break any code that relied on the old API.

Promisify is deterministic and works as specified, 100% of the time. If it doesn't work, that means you passed a function with the wrong signature.

Promises often end up "infecting" every async function. Promises are easy to add, but hard to remove.

To my understanding, the following code examples do the same thing:

  readFilePromise("file").then(... txt ...);
  
  txt = readFileSync("file");

  txt = await readFilePromise("file");

Why not use the one in the middle ?

Because it blocks anything else from happening. If on a server, it will prevent that process from handling any requests until the file has been read, and in a browser-like environment it will prevent the UI from updating and will prevent all UI interaction until the file has been read.

In a simple script you run from your shell, the middle one is fine.

Thank you. I can see the advantage of Promises and async/await. But most of the time, I want to read the file right now, or define what should happen after it has been read. I can not imagine any circumstance when I maybe want to read a file later witch I think is the only advantage of Promises over callbacks, EventEmitter and Sync.

I think it's perfectly fine to wrap standard nodeJS modules into your own module, Promisify or what not. Almost all NodeJS modules does actually use standard modules in some way, it would be very naive to suggest that the standard library should start returning Promises, as it would break almost every NodeJS module ever created.

I also think that Promises only makes sense when you only expect one return, it would note make sense to use Promises in NodeJS streams.

Because it makes points of potential interleaving obvious. Without await, you have no idea whether the call will block or not, and whether whatever shared state you accessed before the call will remain the same after.

With await, you know. If there is no await, the call will not block, and more importantly, shared state cannot be modified from outside of that block of code. If there is await, there are no guarantees and you need to take the necessary precautions.

> sometimes breaks when the callback code isn't what the promisify function expected

Use $q.when() in your code if you aren't sure you're getting a promise.

the problem with promises is that they spread like a virus. And there is no cure. So i want to have a choise not to be infected.