A hill I will die on: There is no good reason to use `async/await` in JS/TS/Flow. - Specialized to thenables, not overloadable due to wrapping vals in promises - Tries to mask declarative async code as procedural sync code - No perf benefits vs 3rd party Promise implementations
-
-
The real-world benchmarks from the post show a ~50ms gain when switching from Promises to async/await. So, if you're looking to shed that last few ms off your request, then sure. But in most cases I've found in the real world, there are many other areas you'd optimize first.
-
That’s the thing — I wouldn’t consider async/await an optimization, but rather a substantial readability improvement. It’s a nice extra that the perf is now on par or better than vanilla promises. In general, we should all focus on writing readable, idiomatic, modern JS.
- 3 more replies
New conversation -
-
-
This doesn't address my larger point about it probably not mattering if you are already using a library that's significantly faster than native promises though.
-
If you're already using something like Bluebird or Creed or a non-promise based async library that's significantly faster than native promises, are you really going to be concerned with this async/await optimization over plain promise code? Probably not...
End of conversation
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.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.
JavaScript performance advice:
1. prefer `async`/`await` over hand-written promise code
2. prefer native promises over userland implementations