Используется, из того, что сразу вспоминается -
веб версии телеграмма. У них достаточно интересная реализация уровня работы с данными. Весь сетевой слой: MTProto-соединения (это их бинарный протокол вместо классического json), шифрование, сериализация, обработка апдейтов, нормализация и кэширование) живёт в воркере, а главный поток через
Proxy-обёртку просто запрашивает доменные данные и получает их готовыми к рендеру. Только они используют SharedWorker, чтобы один сокет шарился между всеми вкладками.
Сейчас всё чаще слышно про local-first подход, который подразумевает минимальный и что самое главное - не заметный для пользователя обмен данными с сервером. То есть на клиенте хранятся кэш с ранее загруженными данными для ui, если что-то изменяется - сервер или клиент обмениваются только обновлениями, для этого придумали разные
sync-engine и другие сложные штуки. Концепция спорная, да и всё хранить локально на клиенте очевидно не получится.
Вообще, разные бывают ситуации и нужно комплексно смотреть на архитектуру фронта и бэка. Точно можно сказать, что это сильно усложнит код и придётся задуматься о вещах, о которых раньше не приходилось думать: как типизировать контракт между потоками, как не упереться в стоимость postMessage со структурным клонированием больших объектов, как отлаживать гонки в realtime-апдейтах. Фактически придётся построить и поддерживать свой маленький RPC-фреймворк
