Pull to refresh

Comments 21

Это «быстрорастворимый» доклад, содержательная часть которого изрядно разбавлена потоком слов. Но заходит хорошо, нескучно. :)

По-моему айтишные презентации на 40 минут с вопросами из зала, уже успели обзавестись своими канонами и правилами. Так что их давно пора относить к особому сценическому разговорному жанру (ну типа камеди клаб). А если прямо так нужно получить информацию кратко и по делу, то лучше профильные статьи почитать или переговорить с докладчиком tête à tête.
Хорошо рассказал. Давно так весело и внятно не было.
UFO just landed and posted this here
Разработчик Артём Белов из самарского офиса норвежской компании Cxense

вы бы хоть первый абзац до конца дочитали...

UFO just landed and posted this here
Расскажите подробнее про последний раздел — кэш. Я не понял, почему для кэша надо использовать Service Workers, когда во всех браузерах уже давно есть встроенный механизм кэширования?

Если это рассказывается в видео, извините. Я только статью прочитал.
Цитата из текста:
Знаете, ребят, а Service Worker вообще-то хранит в преподготовленном состоянии кэш уже в распарсенном виде, вам не нужно компайлить второй раз

Стандартный кеш браузера хранит только файлы, потом их надо заново парсить и компилировать каждый раз при открытии страницы.
Строго говоря, Service Worker кэш не хранят. За хранение кеша отвечает Cache API, которому сервисворкеры делигируют хранение кеша. Cache API хоть и появился в спецификациях вместе с сервис воркерами, но фактически доступен отовсюду: из ServiceWorker, из любых других worker и, конечно, из window. Cache API вполне может использоваться самостоятельно.

В Chrome 42 добавили возможность кеширования байткода для JS скриптов. Фича применяется как для скриптов загружаемых обычным способом, так и извлекаемых из Cache API. https://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html. Поэтому все предыдущие способы кеширования тоже в деле. Но есть отличие в политиках, когда code cache начинает применяться. Для скриптов, загружаемых обычным способом, байт код начинает кешироваться только при повторной загрузке. Для извлекаемых из Cache API — сразу.

Нюанс в том, что компиляция JS это достаточно тяжелая операция, а сайты куда пользователи заходят не слишком часто, или библиотеки из которых приложение использует лишь 5% функций это все реальность. V8 много делает для того, чтобы уменьшить время холодного старта. Поэтому старается запускать детальный парсинг и компиляцию лениво, когда код действительно выполняется. Хаки типа optimize-js и Cache API могут форсировать компиляцию и кеширование байт кода. Но надо понимать, что это будет негативно сказывается на времени первой загрузки (что Артем и получал, судя по графикам на слайдах при попытке положить в кеш все подряд).

Много интересного по теме в статье JavaScript Start-up Performance.
Но разве это не заслуга Cache API, который доступен и без сервис воркеров.
А есть лекции про «быстрорастворимый» бекенд? Было бы интересно послушать.

Это только для тех, кто с Торвальдсом учился.

Не понял прикола с ктрл+ф5, есть же отлаженный механизм чтобы принудительно обновлять кэш у юзеров, и если по тестам он быстрее, о чем вообще доклад?
А потому что, не поняв, что это и как это работает, ты сразу в бой

Мой мозг плакал кровавыми слезами при прочтении этой статьи.
Совершенно, рандомные знаки — препинания: ничуть, не помогают. Прочтению.
Лучше бы их не было вообще.

Логика вместе со знаками препинания скачет, как мысли у Газманова во всем известной песне. Абзацы нарезаны в рандомных местах. Предложения обрываются другими предложениями, чтобы рассказать шутку. Прикольно? Да прикольно. И потерять мысль, а потом продолжаются как ни в чем не бывало, а ты попробуй пойми.

Помимо этот автор как будто не имеет русский язык как родного и поэтому пишет через силовой приём.

видимую прокраску и полную прокраску приложения.

Прокраску? Ты имел в виду, прорисовку? Хотя в тексте и так куча англицизмов, и какого хрена вместо привычного «рендер» тут нужно впихивать ненужный форсед-русизм?
Значение фразы «видимая прокраска», видимо, навсегда останется для меня тайной покрытой мраком.

Из-за всего вышеперечисленного информацию из статьи приходится выуживать через силу.
Тематика интересная, но автору надо учиться говорить внятно, а не бормотать что-то под нос — чтобы его понимал не только он сам. Например:
Но на самом деле за этим будущее. Оно наступит, видимо, не сегодня. Если в случае с optimize-js понятно, там убывающая, то в случае с prepack — возрастающая. И мне кажется, ребята придут к успеху. А уже повезло ребятам, которые делают приложения про PWA, Progressive Web Apps, которые продают Windows Store, для которых APK автоматом генерируется на Android.

Может быть, специалисты поймут такие пассажи; но тогда зачем это печатать здесь, если поймут лишь те, кто уже знал?
Sign up to leave a comment.