Promises instead of callbacks
kaleb opened this issue · comments
I would prefer this library uses promises instead of callbacks. This would make using async/await functions seamless in environments that support them.
I've had this same wish cross my mind a couple times. Using promises would present an even more future-oriented story for Nodal by including the ES6 syntax that enables the new ES7 async/await syntax. That said, callbacks haven't been a dealbreaker. They're familiar, not a problem if used thoughtfully.
The problem with Promises is two-fold:
- Promises give you control-flow and introduce state. Callbacks are used for control-flow only, meaning they're easier to reason about and less prone to errors (or giving developers just enough rope to hand themselves).
- Async / Await is a superior design pattern for handling asynchronous control flow. (It's easiest to reason about, and is the most elegant solution, IMO.)
I have no intention of introducing a Babel compilation step into Nodal, but it is very likely async / await will be natively supported in the future. For now, keeping development easy to reason about (not introducing state management into control flow mechanisms with Promises) is my top priority, knowing that I'll have to adapt the framework to a new form of control flow with async / await in the future.
A number of people have asked for this, but I think the value of Nodal (and frameworks in general) is in curating the design patterns and application stack to reduce the cognitive overhead of developers involved with the project (junior or senior).
I would hope lacking Promises is not a dealbreaker, and that you'd be willing to play with the design patterns I've chosen, but understand your concerns completely. :)
I think this logic is reasonable to me and I think this issue could be closed.
Nick
On Apr 17, 2016, at 1:27 PM, Keith Horwood notifications@github.com wrote:
The problem with Promises is two-fold:
Promises give you control-flow and introduce state. Callbacks are used for control-flow only, meaning they're easier to reason about and less prone to errors (or giving developers just enough rope to hand themselves).
Async / Await is a superior design pattern for handling asynchronous control flow. (It's easiest to reason about, and is the most elegant solution, IMO.)
I have no intention of introducing a Babel compilation step into Nodal, but it is very likely async / await will be natively supported in the future. For now, keeping development easy to reason about (not introducing state management into control flow mechanisms with Promises) is my top priority, knowing that I'll have to adapt the framework to a new form of control flow with async / await in the future.
A number of people have asked for this, but I think the value of Nodal (and frameworks in general) is in curating the design patterns and application stack to reduce the cognitive overhead of developers involved with the project (junior or senior).
I would hope lacking Promises is not a dealbreaker, and that you'd be willing to play with the design patterns I've chosen, but understand your concerns completely. :)
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
Async/await uses promises under the covers.
On Sun, Apr 17, 2016, 17:48 nick notifications@github.com wrote:
I think this logic is reasonable to me and I think this issue could be
closed.Nick
On Apr 17, 2016, at 1:27 PM, Keith Horwood notifications@github.com
wrote:The problem with Promises is two-fold:
Promises give you control-flow and introduce state. Callbacks are used
for control-flow only, meaning they're easier to reason about and less
prone to errors (or giving developers just enough rope to hand themselves).Async / Await is a superior design pattern for handling asynchronous
control flow. (It's easiest to reason about, and is the most elegant
solution, IMO.)I have no intention of introducing a Babel compilation step into Nodal,
but it is very likely async / await will be natively supported in the
future. For now, keeping development easy to reason about (not introducing
state management into control flow mechanisms with Promises) is my top
priority, knowing that I'll have to adapt the framework to a new form of
control flow with async / await in the future.A number of people have asked for this, but I think the value of Nodal
(and frameworks in general) is in curating the design patterns and
application stack to reduce the cognitive overhead of developers involved
with the project (junior or senior).I would hope lacking Promises is not a dealbreaker, and that you'd be
willing to play with the design patterns I've chosen, but understand your
concerns completely. :)—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#214 (comment)
Maybe so, but it also abstracts away state management by hiding the Promise implementation.
Not asking to reopen this, just wanted to put the case that in general to rely on a promise's state (fulfilled/errored), rather than its eventual value, is to use them wrong: https://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-promises-are-functional-nodes-biggest-missed-opportunity/