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
-
-
A substantial readability improvement according to who though? That's assuming that everyone prefers reading/writing procedural code over declarative code... which obviously isn't true if you look at all the people who use libraries like RxJS, etc.
-
One issue I found with both Promise, Task and such, is when you need to keep multiple intermediate values in scope, and not just the last result. In Haskell, you'd use do-notation to avoid nesting the lambdas, and that is pretty much what you get when you use async/await.
- 1 more reply
New conversation -
-
-
On the ergonomic of it I think the opinions are various then
I find piping better for brain to process and having to use try/catch really reduces readability -
+1 I hate try-catch.
End of conversation
New conversation -
-
-
But the thread was a discussion on why async/await might not required when working with other idiomatic alternatives in TypeScript, such as Task/TaskEither. It was not about vanilla promises in JS.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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