Web workers aren't threads. Threading is where you have two parallel streams of execution that share mutable memory. If there's no shared memory then what you've got is more like the older term "multi-processing".
> if other execution can run while you wait for the value, it's blocking.
How does that not capture any operation with a callback, and why does this definition depend on being "in your thread"? I don't think this is a definition that's widely used or understood.
> async vs not async is about interruptibility
By this definition Java fully supports async functions, because you can call Thread.interrupt() on any thread at any time. But I think most people would say Java doesn't do what is commonly understood by "async" including the Java developers themselves.
Your definition isn't as universal as you'd like to believe:
> Web Workers makes it possible to run a script operation in a background thread separate from the main execution thread of a web application. The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down.
> How does that not capture any operation with a callback
You're right that my "blocking" definition is weak. I don't use the phrase in practice (It was introduced by the parent), preferring to think in terms of interruptibility [1]. The distinction I draw is between code that can assume no other code will interrupt it and much up it's view of global state, and that which cannot. The "in your thread" distinction is there because random kernel code or code from other applications (or code from other web workers) running doesn't muck up the thread-in-question's state. Those changes can only be observed across the boundaries of an `await` ("blocking") or in callbacks from separate events.
> I think most people would say Java doesn't do what is commonly understood by "async" including the Java developers themselves.
There's room in this world for multiple definitions. See above :)
[1] The question of "blocking" is a bit interesting, the execution thread wants to make a "blocking" call, but the runtime doesn't actually execute the syscall from that thread. It spins up a new thread to make the call, that thread gets blocked by the OS, and all the while the main execution thread continues running. Thus the call was "blocking" in some sense, but not to the thread in question, which was only "interrupted". The thread in question however is executing all sorts of other code while the assistant thread is blocked, so when the assistant thread returns and execution of that task resumes from being interrupted, it must ensure all the state it had observed beforehand is still valid.
This makes things confusing: the code which executes a trillion digits of Pi is blocking, but it is not interruptible. The code which reads a file or makes a network request via a syscall might be considered blocking, but it is interruptible.
> if other execution can run while you wait for the value, it's blocking.
How does that not capture any operation with a callback, and why does this definition depend on being "in your thread"? I don't think this is a definition that's widely used or understood.
> async vs not async is about interruptibility
By this definition Java fully supports async functions, because you can call Thread.interrupt() on any thread at any time. But I think most people would say Java doesn't do what is commonly understood by "async" including the Java developers themselves.