MZ
Если ты делаешь оффлайн-ферст приложение ты должен совершенно точно и желательно вручную менеджерить ресурсы приложения
Ну вот и получается, что с оффлайн фёрст ты в любом случае выстрелишь себе в ногу, если не будешь следить за размером статики.
Size: a a a
2020 October 17
MZ
Как бы и саппер уже не при чём
L
Ну вот и получается, что с оффлайн фёрст ты в любом случае выстрелишь себе в ногу, если не будешь следить за размером статики.
видимо в этом и заключается сырость технологии
L
)
AP
офлайн ферст это вообще довольно редкий кейс если честно
PM
Ну вот и получается, что с оффлайн фёрст ты в любом случае выстрелишь себе в ногу, если не будешь следить за размером статики.
Вопрос в том это ли проблема самого SW и что греха таить, технологии не сразу взрослеют, либо проблема конкретной реализации в саппер
A
А как не следить за размером статики?
PM
офлайн ферст это вообще довольно редкий кейс если честно
Причём тут редкий или нет. У всех по разному. Технология есть, мы лишь обсуждаем зачем она и насколько ещё сырая
L
А как не следить за размером статики?
ну вон как я описал выше
AP
мы обсуждаем что св в большинстве случаев вообще не нужен и редкость кейсов здесь имеет прямое значение
L
мы обсуждаем что св в большинстве случаев вообще не нужен и редкость кейсов здесь имеет прямое значение
как это он не нужен, когда кейсы существуют
L
хоть и нечастые
AP
ну я же написал, для простого кеширования он не нужен. И написал что для офлайна нужен)
L
ну я же написал, для простого кеширования он не нужен. И написал что для офлайна нужен)
в общем я думаю в сапере он для задела на оффлайн ориентированность. Как я уже писал, у них используется два сценария. В качестве префетчка они в него пихают все что динамически должно загрузится потом (в т. ч. чанки), как хранилище для офлайн сценария со стратегией network first.
MZ
не все же с vue пошли на svelte. или как? надо сначала все круги ада отмотать на реакте, vue, потом опытному на sapper переходить?
Я не писал на вью и не строил архитектуру приложения на реакт.
Просто у меня такие мысли: когда у тебя медиа-сервис с кучей динамических ресурсов, то это повод задуматься об отдельном сервисе, который будет разруливать эту кашу.
Даже когда ты собираешься закинуть на сайт видос в 50+ мб, ты должен отдавать себе отчёт, что собираешься загрузить юзеру 50мб видео, и нужно бы это как-то оптимизировать.
Когда у тебя куча видосов по 10 мб — это тоже повод задуматься об оптимизации. Тут начинается всякие ререндеры под разные разрешения, пропускную способность и т.п. С картинками та же история.
Это же довольно простая мысль: «50 мб+ на клиенте, — это не гуд». У браузеров ограничения тоже не просто так ввели.
Просто у меня такие мысли: когда у тебя медиа-сервис с кучей динамических ресурсов, то это повод задуматься об отдельном сервисе, который будет разруливать эту кашу.
Даже когда ты собираешься закинуть на сайт видос в 50+ мб, ты должен отдавать себе отчёт, что собираешься загрузить юзеру 50мб видео, и нужно бы это как-то оптимизировать.
Когда у тебя куча видосов по 10 мб — это тоже повод задуматься об оптимизации. Тут начинается всякие ререндеры под разные разрешения, пропускную способность и т.п. С картинками та же история.
Это же довольно простая мысль: «50 мб+ на клиенте, — это не гуд». У браузеров ограничения тоже не просто так ввели.
L
Я не писал на вью и не строил архитектуру приложения на реакт.
Просто у меня такие мысли: когда у тебя медиа-сервис с кучей динамических ресурсов, то это повод задуматься об отдельном сервисе, который будет разруливать эту кашу.
Даже когда ты собираешься закинуть на сайт видос в 50+ мб, ты должен отдавать себе отчёт, что собираешься загрузить юзеру 50мб видео, и нужно бы это как-то оптимизировать.
Когда у тебя куча видосов по 10 мб — это тоже повод задуматься об оптимизации. Тут начинается всякие ререндеры под разные разрешения, пропускную способность и т.п. С картинками та же история.
Это же довольно простая мысль: «50 мб+ на клиенте, — это не гуд». У браузеров ограничения тоже не просто так ввели.
Просто у меня такие мысли: когда у тебя медиа-сервис с кучей динамических ресурсов, то это повод задуматься об отдельном сервисе, который будет разруливать эту кашу.
Даже когда ты собираешься закинуть на сайт видос в 50+ мб, ты должен отдавать себе отчёт, что собираешься загрузить юзеру 50мб видео, и нужно бы это как-то оптимизировать.
Когда у тебя куча видосов по 10 мб — это тоже повод задуматься об оптимизации. Тут начинается всякие ререндеры под разные разрешения, пропускную способность и т.п. С картинками та же история.
Это же довольно простая мысль: «50 мб+ на клиенте, — это не гуд». У браузеров ограничения тоже не просто так ввели.
а если человек вообще не собирается закидывать?
PM
ну я же написал, для простого кеширования он не нужен. И написал что для офлайна нужен)
Мы наверное разное под кэшированием понимаем. Мое понимание, SW это про кэширование ресурсов под управлением клиента. Стандартное кэширование этого контроля не даёт, вот и все.
PM
Если копать глубже, то SW это замена раннему AppCache
L
скажем разрабатывает локально библиотеку компонентов, ему нужны моки для статики. не разобравшись накидал парку картинок с медиавики и всё
MZ
а если человек вообще не собирается закидывать?
Ну так и проблемы нет, да?