4 ms·

In practice a lot of libraries don't support promises, so in my experience you'll just end up with a codebase with callbacks and promises mixed. Not very pretty

In practice a lot of libraries don't support promises, so in my experience you'll just end up with a codebase with callbacks and promises mixed. Not very pretty.

SonicSoul 10y ago
pretty sure they're part of ES6 spec[0]. If you're using a 3rd part library that supports callbacks only that sounds more like a choice rather than a limitation with Node. [0] http://www.ecma-international.org/ecma-262/6.0/#sec-promise-constructor http://www.ecma-international.org/ecma-262/6.0/#sec-promise-...
bilalq 10y ago
Any library that accepts a standard node callback can be easily promisified. See: http://bluebirdjs.com/docs/api/promise.promisify.html http://bluebirdjs.com/docs/api/promise.promisify.html http://bluebirdjs.com/docs/api/promise.promisifyall.html http://bluebirdjs.com/docs/api/promise.promisifyall.html
- spriggan3 10y ago
  Now compare that kind of patching with writing Go code where non blocking I/O doesn't require any special syntax. I'm not fan of Go by a long shot, but it is undeniable the blue/red function problem is a pain [1] when dealing with JS. [1] : http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
  - jerf 10y ago
    I love that blog post, because then this makes sense: Promises are basically an inner-platform [1] that replicate all the control flow constructs of the given language, except as a different "color". Go simply is that inner platform. Go does not use promises because all of its code is already running in the promise color. You don't need anything special to "deal with" a for loop that may end up waiting for something to be read from a socket, because the for loop is already a "promise", and so forth. You can rearrange your code as much as you like, and you are not constantly juggling with stuff the compiler ought to deal with. Manual promise transpilation is better than manual callback transpilation, but it's still manual transpilation. Why are you working so hard? Sometimes I get mistaken as an advocate for Go. I'm not really. What I am an advocate for is using languages where you don't need an inner-platform of promises because the language is already that color. Go just happens to be the most familiar Algol-esque of the bunch right now. Don't want to learn Go? Go learn Erlang or Elixir. Or maybe if you're feeling saucy, Haskell. Or some of the other choices popping up lately. If you're writing network servers you will not be able to understood how you ever functioned without this. [1]: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect
masklinn 10y ago
Promises and callbacks are equivalent, it should be pretty trivial to convert all libraries of one style to the other just by wrapping calls to it in a utility function of some sort (and there are probably existing libraries to do exactly that). The only excuse for mixed-style codebases is a codebase in the process of being converted from one style to the other.

In practice a lot of libraries don't support promises, so in my experience you'll just end up with a codebase with callbacks and promises mixed. Not very pretty.

SonicSoul 10y ago

pretty sure they're part of ES6 spec[0]. If you're using a 3rd part library that supports callbacks only that sounds more like a choice rather than a limitation with Node. [0] http://www.ecma-international.org/ecma-262/6.0/#sec-promise-constructor http://www.ecma-international.org/ecma-262/6.0/#sec-promise-...

bilalq 10y ago

Any library that accepts a standard node callback can be easily promisified. See: http://bluebirdjs.com/docs/api/promise.promisify.html http://bluebirdjs.com/docs/api/promise.promisify.html http://bluebirdjs.com/docs/api/promise.promisifyall.html http://bluebirdjs.com/docs/api/promise.promisifyall.html

spriggan3 10y ago
Now compare that kind of patching with writing Go code where non blocking I/O doesn't require any special syntax. I'm not fan of Go by a long shot, but it is undeniable the blue/red function problem is a pain [1] when dealing with JS. [1] : http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
- jerf 10y ago
  I love that blog post, because then this makes sense: Promises are basically an inner-platform [1] that replicate all the control flow constructs of the given language, except as a different "color". Go simply is that inner platform. Go does not use promises because all of its code is already running in the promise color. You don't need anything special to "deal with" a for loop that may end up waiting for something to be read from a socket, because the for loop is already a "promise", and so forth. You can rearrange your code as much as you like, and you are not constantly juggling with stuff the compiler ought to deal with. Manual promise transpilation is better than manual callback transpilation, but it's still manual transpilation. Why are you working so hard? Sometimes I get mistaken as an advocate for Go. I'm not really. What I am an advocate for is using languages where you don't need an inner-platform of promises because the language is already that color. Go just happens to be the most familiar Algol-esque of the bunch right now. Don't want to learn Go? Go learn Erlang or Elixir. Or maybe if you're feeling saucy, Haskell. Or some of the other choices popping up lately. If you're writing network servers you will not be able to understood how you ever functioned without this. [1]: https://en.wikipedia.org/wiki/Inner-platform_effect https://en.wikipedia.org/wiki/Inner-platform_effect

masklinn 10y ago

Promises and callbacks are equivalent, it should be pretty trivial to convert all libraries of one style to the other just by wrapping calls to it in a utility function of some sort (and there are probably existing libraries to do exactly that). The only excuse for mixed-style codebases is a codebase in the process of being converted from one style to the other.