It’s standard for operations that take a while and can be performed asynchronously.
What’s your problem with it?
this post was submitted on 06 Jun 2024
2 points (100.0% liked)
Programming
16780 readers
119 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 !webdev@programming.dev
founded 1 year ago
MODERATORS
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.
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.
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...
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.