5 ms·

the problem is that async-ification infects everything up the call chain. converting a synchronous loop to async may now require that you change a lot of your s

the problem is that async-ification infects everything up the call chain. converting a synchronous loop to async may now require that you change a lot of your sync code above that loop into async code as well, which can complicate all sorts of stuff like debugging, profiling, error handling. for this reason i always optimize the shit out of all synchronous code before resorting to async. and if you do need to go async after that, you might be better off just offloading that optimized synchronous op to a worker thread (or to wasm) to not block the UI. modern JS vms are insanely fast when you pay attention to GC pressure, mem allocation, monomorphism, and dont use accidentally quadratic algos. it's rare that i encounter a codebase that can't be sped up by some large multiple without ever resorting to an async/defer crutch.

ordu 2y ago
> you might be better off just offloading a synchronous op to a worker thread to not block the UI. 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.
mikepurvis 2y ago
Is this a JS specific issue? I find python is decently friendly to having little pockets of async where it makes sense in what is otherwise a regular synchronous program.
- Too 2y ago
  I'd say it's the other way around. In JS, async is just syntax sugar on Promises, they still execute within the same event loop. So regardless of if you are in async or not, you always have to think about not blocking. This becomes a lot easier to reason about, because all code is from the beginning made to be non blocking. Whereas in python if you call a blocking sync function from async world you are up for trouble. The problem solved in the OP is the unusual case where you need to do some big sync computation.
- Yoric 2y ago
  My experience is that Python is worse at async than JavaScript. At least, the debugging experience quickly scales up to nightmarish.
MzHN 2y ago
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 2y ago
  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 2y ago
    > 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/ https://jsfiddle.net/om3tj2rd/ async function foo() { return 2; } console.log(foo()); this
    - leeoniya 2y ago
      > 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.
fenomas 2y ago
> you might be better off just offloading that optimized synchronous op to a worker thread (or to wasm) to not block the UI. 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.
- adregan 2y ago
  The library use case is trickier, but bundlers do a pretty good job of handling workers (albeit with funky magic comments in webpack’s case). What I find a pain is the uneven support for shared workers.
bboygravity 2y ago
Does anyone know when we went from calling things serial and parallel execution to sync and async? Was it before or after we started calling "man-hours" "story points"?
- rplnt 2y ago
  Async and parallel are not the same thing. You can run code async and yet not parallel (one core, no i/o).
- abtinf 2y ago
  JS, as typically run in a browser, is both async and single-threaded.
- com2kid 2y ago
  Async in JS is not in parallel, which is a very -very- important distinction for program correctness.
- Yoric 2y ago
  Async and parallel are a bit different. 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.
  - pavlov 2y ago
    Node didn’t introduce callbacks to JavaScript, they were present in the earliest browser APIs (img.onload, etc.)
    - 2y ago

ordu 2y ago

> you might be better off just offloading a synchronous op to a worker thread to not block the UI. 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.

mikepurvis 2y ago

Is this a JS specific issue? I find python is decently friendly to having little pockets of async where it makes sense in what is otherwise a regular synchronous program.

Too 2y ago
I'd say it's the other way around. In JS, async is just syntax sugar on Promises, they still execute within the same event loop. So regardless of if you are in async or not, you always have to think about not blocking. This becomes a lot easier to reason about, because all code is from the beginning made to be non blocking. Whereas in python if you call a blocking sync function from async world you are up for trouble. The problem solved in the OP is the unusual case where you need to do some big sync computation.
Yoric 2y ago
My experience is that Python is worse at async than JavaScript. At least, the debugging experience quickly scales up to nightmarish.

MzHN 2y ago

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 2y ago
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 2y ago
  > 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/ https://jsfiddle.net/om3tj2rd/ async function foo() { return 2; } console.log(foo()); this
  - leeoniya 2y ago
    > 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.

fenomas 2y ago

> you might be better off just offloading that optimized synchronous op to a worker thread (or to wasm) to not block the UI. 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.

adregan 2y ago
The library use case is trickier, but bundlers do a pretty good job of handling workers (albeit with funky magic comments in webpack’s case). What I find a pain is the uneven support for shared workers.

bboygravity 2y ago

Does anyone know when we went from calling things serial and parallel execution to sync and async? Was it before or after we started calling "man-hours" "story points"?

rplnt 2y ago
Async and parallel are not the same thing. You can run code async and yet not parallel (one core, no i/o).
abtinf 2y ago
JS, as typically run in a browser, is both async and single-threaded.
com2kid 2y ago
Async in JS is not in parallel, which is a very -very- important distinction for program correctness.
Yoric 2y ago
Async and parallel are a bit different. 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.
- pavlov 2y ago
  Node didn’t introduce callbacks to JavaScript, they were present in the earliest browser APIs (img.onload, etc.)
  - 2y ago