4 ms·
Author of Kneden here. If generators are avaiable, you should probably indeed be using this. If they are not though, Kneden will generate code that's probably
by marten-de-vries 11y ago
Author of Kneden here. If generators are avaiable, you should probably indeed be using this.
If they are not though, Kneden will generate code that's probably more readable and smaller (no polyfill except for a Promise implementation).
- david-given 11y agoIs Babel's generator transpiling support good enough to allow this to be transpiled down to ES5?
- s986s 11y agoIf your looking for es5 promises are much easier to polyfill and much more competitive than generators
- wging 11y agoCan you clarify what you mean by 'competitive'? Are you talking about performance, or some other measure of quality?
- marten-de-vries 11y agoIt is, the resulting code is just a bit harder to read, and the babel-polyfill is required. It's quite good considering they're transpiling generators actually, but it's hard to beat something working on a higher level (async/await straight to promises, like Kneden does.)
- skrebbel 11y agoIt's actually how babel's "standard" async/await support works. First to generators, then generators to ES5-compatible code using Facebook's Regenerator (which includes a polyfill). Pragmatic and it works, but the code isn't pretty. Which is why Kneden was made.
- Eridrus 11y agoHave you run any sorts of performance benchmarks on this? I like async/await a lot, but I'm concerned at how much all of this JS machinery costs in terms of perf, especially compared to writing callback chains.
- marten-de-vries 11y agoI haven't. It probably mostly depends on the JS engine and Promise implementation. That said, it might be a good idea to hand-optimize that single hot loop, typing the Promise chain out yourself, or even using callbacks directly. It's impossible to beat that using an automated solution like this.