8 ms·

Breaking Up with Long Tasks or: how I learned to group loops and wield the yield

203 points by jcbhmr 2y ago

leeoniya 2y ago
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
underyx 2y ago
[flagged]
- bsimpson 2y ago
  Dev rel content has always had analogies in it. It's a big assumption that AI made that choice.
  - pwdisswordfishz 2y ago
    It's called a "benefit of the doubt"...
- Brian_K_White 2y ago
  Made sense to me. A problem with multiple solutions, but none of them actually good, or as good as not having the problem. If you didn't understand that, that would be embarassing. If you did understand it, then it wasn't nonsense. Humans have been using weak analogies for several millenia longer than any AI has existed.
neuroelectron 2y ago
[flagged]
- aktuel 2y ago
  These issues pop up everywhere, not just with JS. You can (and people do) write horrendously complex and laggy software (e.g. using "frameworks") in any language. Lots of excellent pieces of software are written in pure JS.
- deleted 2y ago
  [deleted]
bsimpson 2y ago
It's insane that "don't block the UI thread" is so complicated. I never would have expected half the article to be about an edge case if the user is in a background tab. What's worse is I don't even know how you're supposed to know what the edge cases are without stumbling into them. You shouldn't have to know about APIs like document.hidden unless you specifically want to handle background tabs differently. They shouldn't leak into the regular event loop.
- PittleyDunkin 2y ago
  I just wanna note it's crazy that things confusing people a decade ago are still confusing people now. How fucking hard can the concept of a ui thread be?
  - hahn-kev 2y ago
    I think part of the problem is that there is no other thread (outside of service workers), so that's why it's hard. In C# I would just fire up another thread to do the work and I don't have to worry about blocking the UI until I want to notify the UI from that thread. But I can't fire up a separate thread in JS so everything is done on the UI thread
    - PittleyDunkin 2y ago
      > But I can't fire up a separate thread in JS so everything is done on the UI thread Yea targeting the web is nuts if you have other options!
    - chii 2y ago
      The browser as a runtime is the epitome of worse-is-better.
      - PittleyDunkin 2y ago
        [flagged]
    - 2y ago
gttalbot 2y ago
What's old is new again. Some of the same techniques used to keep pre-MacOS-X applications responsive, back when MacOS was cooperatively scheduled, show up here. This begs the question of what is a reasonable programming model? In the MacOS case, the forcing function was buying NeXT, using their Unix kernel for MacOS, and literally firing the OS engineers who disagreed with preemptive multitasking. For these browsers, is there a programming model that could be instituted where processing in these handlers didn't hold up the main UI thread?
- wongarsu 2y ago
  The previous decade certainly feels like a big resurgence of cooperative multitasking, in the rise of JavaScript and the rise of async in all languages. Making JavaScript (conceptually) runs in the UI thread was imho one of the mistakes owed to the extremely simple early versions of JavaScript. We would be better off if JavaScript was preemptively scheduled (whether by the browser or by the OS) with language primitives to lock the UI in specific execution sections.
  - ciconia 2y ago
    Locking the UI while doing a lengthy operation is hardly an acceptable solution. A better solution would be to indicate to the user an async operation is in progress, and optionally provide a button for canceling the operation.
    - wongarsu 2y ago
      What I was thinking about is that you do need a way to lock the UI when running multiple statements that update the UI. Something like a lockUI{} block (conceptually a critical section holding a lock on UI updates). This would for example allow you to prevent a situation where you have to change two data attributes on a button and the user clicks the bottom between those two updates. It would be on the programmer to keep those lockUI{} sections as short as possible. If JavaScript 1.0 had included such a primitive you could run all other JavaScript in the background. Alas, the JavaScript we have is essentially putting all code into such an lockUI block, and this assumption is baked in to a lot of code
jebarker 2y ago
As others have commented, this seems way too hard to achieve. But it warms my heart to see web developers caring about performance.
dleeftink 2y ago
For really heavy work I think hamsters.js is pretty cool[0]. GPU.js can also make a huge difference, but might be overkill for some applications. [0]: https://github.com/austinksmith/Hamsters.js https://github.com/austinksmith/Hamsters.js
bennythomsson 2y ago
Isn't the whole approach wrong? All that stuff should be in another thread. That's it. Re-inventing a bad version of cooperative multitasking, in 2025, really? It's surely a nice exercise, but I really hope this is not production code anywhere. If it is then I'm not surprised about the current state of web software (myself working in a very different area, so I don't really have a clue).
thdhhghgbhy 2y ago
I'm surprised the solution ended up having a magic number in it. I realise the initial guess is refined, but in a commercial scenario I see this code aging poorly and misbehaving at some point, after the whizkid who wrote it has left.
geon 2y ago
Is anyone using generators and the yield keyword to do concurrency in js?
astoilkov 2y ago
For the past 4 years, I've been working on a library that does exactly this — https://github.com/astoilkov/main-thread-scheduling https://github.com/astoilkov/main-thread-scheduling. It works in all browsers and it breaks long tasks. Sometimes it's even more powerful than scheduler.yield(). HN post: https://news.ycombinator.com/item?id=38864791 https://news.ycombinator.com/item?id=38864791.
niutech 2y ago
Why not use async iterators and generators in JS? https://javascript.info/async-iterators-generators https://javascript.info/async-iterators-generators

203 points by jcbhmr 2y ago

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

underyx 2y ago

[flagged]

bsimpson 2y ago
Dev rel content has always had analogies in it. It's a big assumption that AI made that choice.
- pwdisswordfishz 2y ago
  It's called a "benefit of the doubt"...
Brian_K_White 2y ago
Made sense to me. A problem with multiple solutions, but none of them actually good, or as good as not having the problem. If you didn't understand that, that would be embarassing. If you did understand it, then it wasn't nonsense. Humans have been using weak analogies for several millenia longer than any AI has existed.

neuroelectron 2y ago

[flagged]

aktuel 2y ago
These issues pop up everywhere, not just with JS. You can (and people do) write horrendously complex and laggy software (e.g. using "frameworks") in any language. Lots of excellent pieces of software are written in pure JS.
deleted 2y ago
[deleted]

bsimpson 2y ago

It's insane that "don't block the UI thread" is so complicated. I never would have expected half the article to be about an edge case if the user is in a background tab. What's worse is I don't even know how you're supposed to know what the edge cases are without stumbling into them. You shouldn't have to know about APIs like document.hidden unless you specifically want to handle background tabs differently. They shouldn't leak into the regular event loop.

PittleyDunkin 2y ago
I just wanna note it's crazy that things confusing people a decade ago are still confusing people now. How fucking hard can the concept of a ui thread be?
- hahn-kev 2y ago
  I think part of the problem is that there is no other thread (outside of service workers), so that's why it's hard. In C# I would just fire up another thread to do the work and I don't have to worry about blocking the UI until I want to notify the UI from that thread. But I can't fire up a separate thread in JS so everything is done on the UI thread
  - PittleyDunkin 2y ago
    > But I can't fire up a separate thread in JS so everything is done on the UI thread Yea targeting the web is nuts if you have other options!
  - chii 2y ago
    The browser as a runtime is the epitome of worse-is-better.
    - PittleyDunkin 2y ago
      [flagged]
  - 2y ago

gttalbot 2y ago

What's old is new again. Some of the same techniques used to keep pre-MacOS-X applications responsive, back when MacOS was cooperatively scheduled, show up here. This begs the question of what is a reasonable programming model? In the MacOS case, the forcing function was buying NeXT, using their Unix kernel for MacOS, and literally firing the OS engineers who disagreed with preemptive multitasking. For these browsers, is there a programming model that could be instituted where processing in these handlers didn't hold up the main UI thread?

wongarsu 2y ago
The previous decade certainly feels like a big resurgence of cooperative multitasking, in the rise of JavaScript and the rise of async in all languages. Making JavaScript (conceptually) runs in the UI thread was imho one of the mistakes owed to the extremely simple early versions of JavaScript. We would be better off if JavaScript was preemptively scheduled (whether by the browser or by the OS) with language primitives to lock the UI in specific execution sections.
- ciconia 2y ago
  Locking the UI while doing a lengthy operation is hardly an acceptable solution. A better solution would be to indicate to the user an async operation is in progress, and optionally provide a button for canceling the operation.
  - wongarsu 2y ago
    What I was thinking about is that you do need a way to lock the UI when running multiple statements that update the UI. Something like a lockUI{} block (conceptually a critical section holding a lock on UI updates). This would for example allow you to prevent a situation where you have to change two data attributes on a button and the user clicks the bottom between those two updates. It would be on the programmer to keep those lockUI{} sections as short as possible. If JavaScript 1.0 had included such a primitive you could run all other JavaScript in the background. Alas, the JavaScript we have is essentially putting all code into such an lockUI block, and this assumption is baked in to a lot of code

jebarker 2y ago

As others have commented, this seems way too hard to achieve. But it warms my heart to see web developers caring about performance.

dleeftink 2y ago

For really heavy work I think hamsters.js is pretty cool[0]. GPU.js can also make a huge difference, but might be overkill for some applications. [0]: https://github.com/austinksmith/Hamsters.js https://github.com/austinksmith/Hamsters.js

bennythomsson 2y ago

Isn't the whole approach wrong? All that stuff should be in another thread. That's it. Re-inventing a bad version of cooperative multitasking, in 2025, really? It's surely a nice exercise, but I really hope this is not production code anywhere. If it is then I'm not surprised about the current state of web software (myself working in a very different area, so I don't really have a clue).

thdhhghgbhy 2y ago

I'm surprised the solution ended up having a magic number in it. I realise the initial guess is refined, but in a commercial scenario I see this code aging poorly and misbehaving at some point, after the whizkid who wrote it has left.

geon 2y ago

Is anyone using generators and the yield keyword to do concurrency in js?

astoilkov 2y ago

For the past 4 years, I've been working on a library that does exactly this — https://github.com/astoilkov/main-thread-scheduling https://github.com/astoilkov/main-thread-scheduling. It works in all browsers and it breaks long tasks. Sometimes it's even more powerful than scheduler.yield(). HN post: https://news.ycombinator.com/item?id=38864791 https://news.ycombinator.com/item?id=38864791.

niutech 2y ago

Why not use async iterators and generators in JS? https://javascript.info/async-iterators-generators https://javascript.info/async-iterators-generators