В моем варианте даже останавливаться не нужно... Просто забирай или отрабатывай готовые данные из "общедоступного места".

Процесс пишет. А мониторит кто? Второй процесс? А как в js без worker сделать второй процесс?

Да.
Еще один setTimeout()...

voraa, рендеринг "по готовым данным" можно запускать и из процесса "обработчика".
Т.е. собственно мониторинг может только показывать "состояние дел". А сами изменения на клиенте может запускать процесс-обработчик некими "порциями".
Подготовил N-ное количество - запускай setTimeout(), который все N штук и отрисует...

Тут главное чтобы сам "источник данных" был доступен всем процессам-участникам.

setTimeout не запускает новый процесс. Он просто ставит обработчик в очередь внутри одного процесса
И зачем setTimeout, если есть requestIdleCallback?
Используя setTimeout, мы тупо пихаем очередное задание в очередь, не зная сильно ли она заполнена. Есть ли у браузера время обработать это задание не тормозя прорисовку. А requestIdleCallback выполняет задание именно тогда, когда браузер не занят обработкой событий, пересчетом стилей и прорисовкой. К тому же внутри задания можно узнать, осталось ли еще время, что бы посчитать очередную порцию.

Это я условно так написал... :-?
Потому и указывал много чего в кавычках...

requestIdleCallback не всегда был в JS... :D
А коней на переправе не меняют.

Т.е. работает такой подход уже давно... А нужен он далеко не всегда.

Я не критикую такой подход. :)
Я лишь описал как выходил их таких положений ранее сам.

Вот решил почитать про него...
https://developer.mozilla.org/ru/doc...stIdleCallback
И сразу там увидел большое сообщение

В JS не всегда были requestAnimationFrame, forEach, Map, Promise, async/await .... Всякие ?. ??
Это не повод ездить на старых клячах.

Я же сразу написал, "если не думать про Safari" (ИЕ нашего времени)
Для Safari есть типа полифил (реализованный как раз через setTimeout).
Ну хоть в нормальных браузерах будет нормально работать.