In my experience almost everything in the JS world is already async. User interactions are async, requests are async, almost all NodeJS APIs are async. To me having to add more async in JS is a tiny barrier compared to what I'm facing in other languages that feel more synchronous to me.

Since there is already so much async I also feel like debugging, profiling and error handling are all pleasantly solved problems in JS.

Offloading to workers is also async so while there are many valid benefits to be gained, avoiding async does not seem like one of them to me.

A lot of junior devs I've worked with don't understand that putting `async` in front of a function doesn't actually make it asynchronous.

of course it does. annotating any function with async makes it implicitly return a Promise, which fundamentally changes how all callers have to use it (and their caller's callers, etc.). you can't "just" make a function async and change nothing about how it was used previously.

https://jsfiddle.net/om3tj2rd/

  async function foo() {
    return 2;
  }
  
  console.log(foo());

i should clarify a bit, that this can still freeze your UI if foo() is expensive, since the microtask still runs on the same event loop. my point is that you cannot always throw async in front of a function and not change any other code.

It works in principle, but note that this really complicates your build process. In particular, if you're writing a library that other people will use as a dependency, there's really no good way to use workers at all without affecting how people bundle their code using your library.

What I find a pain is the uneven support for shared workers.

I believe it should be the answer. If your computations are tolerably fast, then you could do it without async, but if they are not, then it is better to use preemptive multitasking for them. The overhead on the kernel scheduler will be small, because you don't start 10k of threads concurrently eating CPU time. Probably the overhead of starting a thread doesn't matter either with long tasks. As a bonus you could also do blocking i/o operations without thinking about blocking.

Parallel means that things execute at the same time (or at least appear to do so). Async means that you yield control to some kind of scheduler and get it back at a later point.

Barring workers, JavaScript actually guarantees that two pieces of code never execute at the same time. That's the run-to-completion semantics.

When async was introduced to JavaScript from two different angles (callbacks in Node, Promise then await in browsers), there was limited parallelism involved (typically running I/O in the background), but the async was meant to ensure that:

1. while a task was (almost explicitly) waiting, another one could run;

2. in the case of the browser, we could yield control from JavaScript often enough that the UI could run smoothly.

  img.onload = function() {…}
  img.src = “some url”

  img.load(“some url”, function() {…})

Async code is scheduling different parts after each other. It's still running in a single thread (maybe on same core)

aaync essentially is non-blocking IO in many cases. It can also ahieldnsome logic running in a diffefent thread, hidden from that segment of code.