Re:Show HN: I built a zero-latency developer tool suite in p...
by moritzwarhier on Thursday July 23, 2026 @03:22PM
(#49026773)
I'd phrase that as "local" and "synchronous".
"Achieving" latency using local JS is not hard, just do some heavy compute and/or do the same via the browser's layout engine.
Try and do some real work in JS, for example, generate Sudokus, render raster images from DOM fragments, whatever: you'll see latency.
If you want non-blocking latency (like from a network request), use asnyc APIs and a Worker or other natively non-blocking API. Or simply a Promise wrapping a setTimeout.
But latency in synchronous and local JS is an everyday problem. So I think your phrasing is wrong.
"Achieving" latency using local JS is not hard, just do some heavy compute and/or do the same via the browser's layout engine.
Try and do some real work in JS, for example, generate Sudokus, render raster images from DOM fragments, whatever: you'll see latency.
If you want non-blocking latency (like from a network request), use asnyc APIs and a Worker or other natively non-blocking API. Or simply a Promise wrapping a setTimeout.
But latency in synchronous and local JS is an everyday problem. So I think your phrasing is wrong.