A design for DOM Futures (nee "Promises"): https://github.com/slightlyoff/DOMFuture … with help from @domenic @annevk @wycats and @ErikArvidsson
-
-
@wycats@slightlylate@domenic@annevk@ErikArvidsson IDBReq is a shitty API. The other is an opinionated flow control things force on me. -
@Raynos2 promises are as opinionated as addEventListener. Consistency, not "forcing"@slightlylate@domenic@annevk@ErikArvidsson -
@wycats@slightlylate@domenic@annevk@ErikArvidsson chaining then is opinionated. Propagating errors is opinionated error handling. -
@Raynos2 don't use those features@slightlylate@domenic@annevk@ErikArvidsson -
@wycats@slightlylate@domenic@annevk@ErikArvidsson Meh. I like neutral APIs. -
@Raynos2 it's really useful to have "async value" encapsulation when using values elsewhere@slightlylate@domenic@annevk@erikarvidsson -
@wycats@slightlylate@domenic@annevk@ErikArvidsson Agreed. Promises/Futures just aren't the concept I would use for that. -
@Raynos2 instead you would use...@slightlylate@domenic@annevk@ErikArvidsson - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.