Comments 6
> Конечно, полезность Service Worker-ов на этом не ограничивается, с их помощью реализуются, например, offline-режим и backsync, – прим. переводчика)
офлайн отлично меня устраивал в эппкеше, not a douche bag. Background sync неплохо конечно, но каковы юз кейсы?
> (FCM = Firebase Cloud Messaging, но его использование не является обязательным в данном случае, – прим. переводчика)
я могу ошибаться, но для push notification FCM обязательный, или другой провайдер. Куда то же надо слать на общий сервер.
Я согласен что у эпкеша есть минусы. Но он работает и он прост. СВ — не поддерживается Эплом вообще (читай — нет смысла реализовывать), сделан очень замудрено (функцию push notification можно вообще было в отдельное API вынести, без того чтобы плодить SW для одной единственной цели). Плюс личные причины — я давно хочу офлайн приложения чтобы были подписаны публичным ключом/ами создателей, СВ это игнорирует.
Крайне недоволен, по итогу.
Про FCM. Мозилла и гугл, реализуют по-отдельности протокол webpush. В хроме он работает на основе fcm, но разработчик ничего не должен подключать — всё предоставляет браузер, а разработчик получает только урл-эндпоинт для отправки сообщений конкретному подписчику.
Про SW.
Когда сам разбирался с sw — проклял всё. Документации мало, половина имеющейся — устарела. Но я считаю, что это просто шаг вперёд, дальше будет лучше. По моему ощущению в мире фронтенда уже некоторое время все делают по принципу: сейчас релизим как есть, а завтра латаем дыры и смотрим, что получилось. Тут так и вышло.
И Chrome, и Firefox теперь поддерживают W3C Push API.
Использовать Firebase Cloud Messaging не обязательно, есть Web Push Libraries.
Вам придется со временем полностью от него отказаться, потому что он уже в статусе deprecated ( MDN ). И его поддержка будет удалена со временем
> Background sync неплохо конечно, но каковы юз кейсы?
Пользователь в оффлайн отправляет сообщение, которое отправится когда появится сеть. любая активность в оффлайн может быть таким образом не утеряна. Кейсов много если задуматься
> я могу ошибаться, но для push notification FCM обязательный, или другой провайдер
Имелось в виду что вы не привязаны к конкретному провайдеру — выбор серверной реализации на ваших плечах.
> Эплом вообще (читай — нет смысла реализовывать)
Эпплом, к сожалению, много что не поддерживается. Например тот же WebRTC. Это не делает технологию неюзабельной. И кстати на Chrome Summit что-то говорили про то что в Apple все-таки планируют ( не знаю насколько это окажется правдой )
Я убежден, что нужно добавить флажок для отключения Service Worker.
Я тоже за то, чтобы предоставлять пользователю возможность как можно большего контроля над происходящим. Но вопрос в том, насколько эта возможность будет востребована у обычных пользователей. Многие ли блокируют выполнение JavaScript в браузере?
Лично мне эта технология пользы не приносит.
Например, Push и Cache/Precache, — одни из основных концепций прогрессивных web-приложений (Progressive Web Apps, PWA), основаны на Service Workers, а у PWA светлое будущее.
Вы читали документацию Cache? Это же как китайская грамота.
Есть отличный учебник по Service Workers — https://serviceworke.rs, есть https://github.com/GoogleChrome/sw-precache и https://github.com/GoogleChrome/sw-toolbox, которые довольно просты в использовании и хорошо документированы.
Проблема не в Service Workers, проблема в сознании. Нужно перестать относиться к сайтам как к наборам отформатированных страниц, а начать воспринимать их как полноценные приложения, а web как платформу, причём самую большую. Современные браузеры предоставляют возможности, ранее доступные только нативным приложениям: доступ к местоположению, камере, микрофону, USB, NFC, возможность получать push-уведомления, работать без доступа к интернету и т.д. И к вопросу безопасности и доверия к web-приложениям нужно относиться так же как и к нативным приложениям.
Использование Service Worker для создания ботнета