Надо ли мне кеш через ServiceWorker?

ServiceWorker нужны не для префетчинга ассетов.

Префетчить ассеты фоном ты можешь через <link rel=preload>

А ServiceWorker это прежде всего возможность отображать приложение, хоть в каком-то виде, без интернета (даже временного его отсутствия - человек зашел в метро, пропала сеть, но он не лишается возможности читать открытый контент и его не выбрасывает на загулшу браузера о том, что нет сети).

Или хотя бы для того, чтобы говорить, что интернета нет в интерфейсе твоего же приложения, а не показывая стандартную заглушку браузера.

Ну и возможность доступа пользователя к какому-то контенту, для которого интернет не нужен (или он закеширован) - как пример товары в интернет магазине могут кэшироваться в локальные хранилища и быть доступны для просмотра и без сети, или на тех же формуах, могут кэшроваться просмотренные треды.

Ну и еще SW используются как главный менеджер всех активных сессий в браузере (табов, в том числе не связанных дочерностью) и локальных хранилищ.

Это все уровня повышения UX, как например - сохранять введеный, но не отправленный, в поля ввода текст в кэш, чтобы если пользователь случайно ушел со страницы, ему не пришлось вводить всю свою пасту сначала. Как пример - на ЛОРе ты можешь написать несколько абзацев, нажать отправить - узнать что у тебя пропала сеть, и дождавшись когда она вернется вводить все сначала. Без SW можно было просто закешровать ввод, и предоставить его потом. С SW можно поставить сообщение в очередь на отправку и уведомить об этом пользователя.

Если тебе не нужны такие возможности, то и сервисвокреры тебе не нужны.

SW для префетча - это ошибка уровня «Electron для лэндинга». Для префетчинга ресурсов есть специальные теги (link) и даже, поддерживаемые некоторыми браузерами, HTTP-заголовки (Link).

Ну и еще SW используются как главный менеджер всех активных сессий в браузере (табов, в том числе не связанных дочерностью) и локальных хранилищ.

Кхе… ну так можно конечно, но ты уверен что это все не проще сделать на SharedWorker, не уродуясь особо с инсталляцией? Вроде как профит ServiceWorker где-то рядом с процессингом реквестов. А устраивать через него брокер вкладок выглядит трохи перебором.

Это все уровня повышения UX, как например - сохранять введеный, но не отправленный, в поля ввода текст в кэш, чтобы если пользователь случайно ушел со страницы, ему не пришлось вводить всю свою пасту сначала. Как пример - на ЛОРе ты можешь написать несколько абзацев, нажать отправить - узнать что у тебя пропала сеть, и дождавшись когда она вернется вводить все сначала. Без SW можно было просто закешровать ввод, и предоставить его потом. С SW можно поставить сообщение в очередь на отправку и уведомить об этом пользователя.

IMHO сохранение стейта - это localStorage/IndexedDB. Корректная синхронизация стейта - это довольно кучерявая математическая задача (с крайней формой - «параллельное редактирование документа по сети»). Дизайн синхронизации, при которой данные провисают в реквестах [в «междустейтах»] - это уже тяжелая форма безумия, КМК. Не, это на первый взгляд действительно выглядит изящно и привлекательно, но если сформулировать математически - ну ведь кащенко же.

Если тебе не нужны такие возможности, то и сервисвокреры тебе не нужны.

Ну да, я похоже пешком постою. Спасибо что помог сориентироваться в направлениях. Просто народ чаще всего упоминает кеширование на сервисворкерах, вот я и нахлобучился, как такое вообще может быть лучше браузерного кеша. Еще позырил в фаерфоксе about:serviceworkers, кто во что горазд. Почему-то отложилось только 2 юзкейза - долбить юзера пушами, и кешировать ответы сервера.

но ты уверен что это все не проще сделать на SharedWorker

Уверен, конечно. Сравни поддержку ServiceWorker и SharedWorker.

не уродуясь особо с инсталляцией

Так у SW нет интерактивной инсталяции. Они устанавливаются сами по себе, без действий со стороны пользователя. Это если он хочет себе иконку PWA на рабочий стол\лаунчер поместить нужна специальная установка, это совершенно другое. У SW есть только событие, когда они устанавливаются впервые, это просто часть жизненного цикла.

IMHO сохранение стейта - это localStorage/IndexedDB

Так я про это и писал. Кэшрование стейта - это локальные ранилища. Кэширование контента или очередь запросов это SW.

Без SW можно было просто закешровать ввод, и предоставить его потом. С SW можно поставить сообщение в очередь на отправку и уведомить об этом пользователя.

Просто народ чаще всего упоминает кеширование на сервисворкерах

SW не для кэширвоания ресурсов. Они для кэширования контента. В идеальном сценарии все твое приложении вообще не зависит и ничего не знает об SW. Оно ходит на бэк за контентом как обычно, но на самом деле SW мониторит все запросы, и при наличии интернета запрашивает его с бэка, без наличия - из кэша. Контент - это не картиночки с css фйлами - они закэшируются и так стандартными заголовками о кэшировании. Контент - это непосрредственно наполнение сайта.

Ну и плюс при наличии SW приложение пишется с тем расчетом, что оно способно открываться и работать без этого интернета. Буквально - у тебя нет сети, но ты вводишь адрес сайта и он открывается (то есть в логике должны быть корректные отработки тех веток, где данные запросить не удалось потому что их нельзя кэшировать, например).

SW это просто следующий шаг Progressive Enhancement, на равне со всеми остальными.

Еще позырил в фаерфоксе about:serviceworkers, кто во что горазд

Как я уже написал - SW для префетча или кэширования статики - это как электрон для лэндингов. Некорректное применение технологии. Любителей заворачивать условные лендосы, в электрон так же полно, лишь для того, чтобы приложение имело иконку на рабочем столе и работало без сети (для чего как раз хватило бы обычных SW и PWA).

SW не для кэширвоания ресурсов. Они для кэширования контента.

Похоже на то. Просто большое количество долбодятлов со своими статьями в бложиках сильно сбивает с толку :).

Мне же проблем меньше - не надо код писать.

но ты уверен что это все не проще сделать на SharedWorker

Уверен, конечно. Сравни поддержку ServiceWorker и SharedWorker.

Ну так-то да, но выглядит запуск сервисворкера реально странно. Плюс он только один.

Я прикидывал, стоит ли на нем мутить шареный коннектор к центрифуге. А потом подумал, и решил что проще через Visibility API в каждой вкладке свой коннект поднимать/опускать :). Заодно отпала необходимость во всякой альтернативной эзотерике, вроде master election для вкладок.

Контент - это не картиночки с css

А что тогда?