[MzHN]

If this was any other language than JS I would agree but my personal experience with JS is the opposite.

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.

[StackTopherFlow]

I agree with you. I rarely find myself in a situation where a piece of async code forces me to refactor a synchronous code to be async.

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.

[leeoniya]

> 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());

this

[leeoniya]

> of course it does.

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.