Sure, and if you're only invoking a single promise, execution time is negligible. I presumed we were discussing real-world impacts, not angels-dancing-on-a-pinhead tweaks.
-
-
Having done both, I'm also leaning towards WASM at this point. For the algorithms I'm implementing I think they will be faster than the WebCrypto-based equivalents, with a friendlier API.
-
Right. That's the cost of getting WebCrypto wrong. People will, understandably, do that. Now we have larger download, a slower (ignoring WebCrypto overhead and algorithm selection) and less side-channel-protected impl, AND, in so far as this was misuse, we didn't even avoid it!
- 1 more reply
New conversation -
-
-
JS regexps after Perl are NFAs (backtracking), can go exponential. This would never have justified making their APIs async, even if I had had promises in 1997 when I prototyped what became ES3 regexps. It seems fruitless to try to prevent main thread jank by crippling such APIs.
-
This Tweet is unavailable.
- 2 more replies
New conversation -
-
-
The vast majority of the code I write nowadays ends up in an `async` function with `await` all over the place. It's extremely natural to read and easy to reason about. I agree that callback soup is a special kind of hell.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
More importantly a lot of code where crypto is needed inherently can’t be changed to async without changing api contracts.
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.