Why is crypto.subtle.digest designed to return a promise?
Every other system I’ve ever worked with has the signature hash(bytes) => bytes, yet whatever committee designed the Subtle Crypto API decided that the browser version should return a promise. Why? I’ve looked around but I’ve never found any discussion on the motivation behind that.
You must log in or register to comment.
It executes on a native thread in the background. That way it doesn’t stall the Javascript execution loop, even if you give it a gigabyte of data to hash.
deleted by creator
async/await infecting all of my code, being unable to create a
get myField()method that involves a hash calculation. It may be standard to do heavy lifting concurrently, but async hash functions are certainly not standard in any of the languages I’ve used (which is quite a few).deleted by creator
Given the nature of JS running only on a single thread. Promises/asynchronity is the only way to keep the browser from locking up.
Thus insisting on any other way is a major flaw in the developer not the language.
deleted by creator
deleted by creator
> Given the nature of JS running only on a single thread.
No no, I think you found the language flaw.
its a good idea to be as non blocking as possible especially on time and resource consuming tasks like IO, cryptography, …
just use
awaitin anasync function.just use
awaitin anasync function.Sure, I’ll just put
awaitandasynceverywhere. Oh wait, I can’t. A constructor can’t be async so now I need to restructure my code to use async factories instead of constructors. Wonderful…deleted by creator
Sounds like an architectural issue to begin with. A constructor shouldn’t do the heavy lifting to begin with.
You consider calculating the hash of a few bytes to be heavy lifting?
The API doesn’t restrict the amount of bytes to be hashed. So yeah it’s still heavy lifting.
Trigger a loading event after the constructor is finished that the view model takes to calculate your hash.
