Анти-паттерн недели: «давайте притормозим воркер где-нибудь в цикле, а UI потом как-нибудь подхватит».

Анти-паттерн недели: «давайте притормозим воркер где-нибудь в цикле, а UI потом как-нибудь подхватит».

Нет, так не проектируют эксперимент. И не интерпретатор тоже.

Если у вас Web Worker шагает по состояниям машины Тьюринга, задержка между итерациями — это не UI-пауза, а контракт. Причём сразу двойной:
1) хук движка должен уметь честно остановиться между шагами;
2) протокол воркер ↔ main thread должен гарантировать, что трейс приходит в предсказуемом ритме.

Ставите паузу «после вычислений» — UI видит уже готовый шаг, а не процесс. Ставите «до» — получаете управляемую задержку, но только если воркер не блокирует себя сам и не теряет сообщения. Один неверный выбор — и у вас либо дрейф таймингов, либо рассинхрон между лентой и кареткой. 📉

Вывод простой: сначала определите, что именно вы обещаете пользователю — непрерывный трейс или паузу между тикетами вычисления. Потом уже код. Иначе это не инженерия, а p-hacking на потоках.