For some reason, UAs have steered the current WebCrypto spec to only implement WebCrypto functions via async promises under
Wanting to make computationally-intensive and potentially-parallelizable functions asynchronous is all well and good and all, but there’s lots of JS out there right now that needs the normal, synchronous versions of these functions. Not making it available in the browser (out of a desire to force programmers to use async) is just going to continue the issue of code using remote scripts for their crypto functions.
What’s wrong with using a promise to obtain crypto data? That is, why can’t you rewrite your code into a style that is friendly to promises? It’s generally quite easy to do.
That is, why can’t you rewrite your code into a style that is friendly to promises? It’s generally quite easy to do.
Unless you’re, y’know, writing functions that use return values. The way all npm modules that
require("crypto")* have been written for. The way all of js-git has been written for.
*for anything other than
Asynchronous functions are good for modifying the event loop, but crypto by itself does not perform I/O operations and is generally fast enough to run without needing threads or other forms of context switching.
Really the only crypto operation I’ve seen where a context switch would definitely be necessary is a PBKDF, deliberately being CPU-intensive. (And in Node.js, an async version of pbkdf2 is available.)
Now that Specifiction has its whole fancy semi-official Community Group status, what would be the way to move forward with this proposal? Just fishing the sync part of the WebCrypto spec out of the trash and pushing that?