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.
this post was submitted on 06 Jun 2024
23 points (100.0% liked)
Programming
19223 readers
154 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
It’s standard for operations that take a while and can be performed asynchronously.
What’s your problem with it?
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).
From browsing your other comments on this thread I understand that you are in a context where you can’t await, that you expect the invocation to take very little time, and that the library offers no complementary sync interface.
As far was I know you’re stuck in this case. I consider the stubborn refusal to add “resolve this promise synchronously right now” a major flaw in js.
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.
Thus insisting on any other way is a major flaw in the developer not the language.
I mean, I understand the idea, but this is a pretty asshole way to frame it. I don’t think I deserve that, and certainly OP doesn’t deserve that.
> 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 await in an async function.
just use
awaitin anasync function.
Sure, I'll just put await and async everywhere. 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...
A constructor can't be async so now I need to restructure my code to use async factories instead of constructors
It sounds like you’re trying to do OOD/OOP. In js that’s usually not the way to go. You might want to restructure into a more functional architecture anyway.
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.