- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 17 Jul 2013 19:51:59 -0500
- To: Ruben Rodriguez II <whatwg@therealcha0s.net>
- Cc: WHATWG <whatwg@lists.whatwg.org>
On Jul 17, 2013 8:40 PM, "Ruben Rodriguez II" <whatwg@therealcha0s.net> wrote: > > This is exactly what I was thinking when I was reading this. I have been building a game engine with async JS and I have run into situations where promises were absolutely sapping performance. > > I would encourage people to look over even the faster promise libraries and understand just how much complexity they introduce, and how many 'next tick'-type operations that a cascading promise chain can stimulate. > > It's wonderful because of how entirely promises cover your execution path, making control flow silky smooth and safe. However it does come at a price, and any API at a 'system' level should strive to implement features in the most performant way by default: a callback. It'll take 1 day to wrap your API with a promise-based API for people who would make that tradeoff. If you sacrifice speed first, there's no way to go back the other way. Forcing people to wrap with their own code is just a way of saying "lol, we're not actually doing that". Callbacks are no faster than promises, because to maintain consistent semantics, they have to delay across ticks anyway. Homebrew callback systems can ignore that, but only because they're not as worried about overall API correctness, and are okay with making their users deal with sometimes-synchronous code. ~TJ
Received on Thursday, 18 July 2013 00:52:24 UTC