Ребята из Slack продолжают радовать статьями про своё новое приложение. В этот раз они написали про использование сервис воркеров в web-версии — "Service Workers at Slack: Our Quest for Faster Boot Times and Offline Support".

При первой загрузке приложения в кеш сервис воркера помещаются html, звуковые файлы, шрифты, js и css-файлы. Для того чтобы хранящиеся файлы не устаревали, кастомный плагин webpack формирует манифест, который встраивается в установочный код сервис воркера. Изменение кода сервис воркера инициирует его установку, в результате которой происходит загрузка всех файлов из манифеста и их сохранение в кеш. При таком подходе всегда будет загружаться не самая последняя версия клиента. Но на этот шаг пошли осознанно, чтобы сократить время загрузки клиента. Теперь приложение с прогретым кешом стартует в два раза быстрее. Чтобы приложение не устаревало, в фоне регулярно происходит проверка наличия обновлений.

Добавление сервис воркеров позволило реализовать базовые оффлайн функции (чтение ранее загруженных сообщений, отметки о прочитанности сообщений). В будущем, планируют добавить более продвинутые оффлайн-сценарии, но не написали, какие именно.

Статья хорошая, но, скорее всего, будет интересна не всем.

#serviceworker #experience

https://slack.engineering/service-workers-at-slack-our-quest-for-faster-boot-times-and-offline-support-3492cf79c88

Брайан Карделл — один из участников w3c — приоткрыл завесу над тем, как в последние годы в web-платформе появляется поддержка новых стандартов — "Beyond Browser Vendors".

За каждым браузером есть компания, которая выделяет бюджет на его разработку. Этот бюджет определяет размер команды разработчиков и тот объём задач, который они могут зарелизить. Чаще всего в приоритет ставятся задачи, которые отвечают специфичным запросам компании, что вполне логично. Брайан пишет, что ему как контраргумент на это утверждение приводят гриды. На первый взгляд кажется, что разработчики браузеров смогли договориться между собой и приоритизировать имплементацию гридов так, чтобы их поддержка появилась примерно в один промежуток времени (март 2017 года). Но это не так.

Первое предложение "Frame-Based Layout" появилось в 1996 году, как попытка реализовать грид-подобную систему, управляемую с помощью CSS. Этот пропозал не был имплементирован. В 2005 году Берт Росс опубликовал предложение "CSS Advanced Layout", которое в 2009 году переродилось в "CSS Template Layout", но опять этот пропозал не был имплементирован. В 2011 году Microsoft переосмыслила предыдущие подходы и представила сообществу "Grid Layout", его реализация появилась вместе с IE10. Но на этом всё и остановилось, так как Microsoft решала свои внутренние задачи с внедрением этого стандарта.

Примерно в это же время web становился всё более и более открытым — стал прозрачнее процесс стандартизации, основную часть рынка поглотили браузеры с открытым исходным кодом. Этот факт позволил другим компаниям участвовать в разработке стандартов. В итоге, внедрением гридов в Chrome и Safari занималась Igalia — консультационное агентство, где работает Брайан. Работу полностью профинансировал Bloomberg. Подобным образом в Chromium была добавлена поддержка ResizeObserver, BigInt, private fields, MathML и других фич. Брайан не говорит о том, что вендоры плохие и ничего не делают, наоборот, он говорит о том, что они тоже участвуют в разработке, как минимум в ревью и в дальнейшей поддержке кода.

Ставлю этому посту свой любимый тег — history. Очень рекомендую почитать статью всем, кто интересуется историей web'а.

#musings #history #web

https://bkardell.com/blog/Beyond.html

Пару дней назад в код v8 была добавлена реализация предложения "Top-level await" (Stage 3). Про этот пропозал в канале ещё ничего не было, поэтому хочу написать небольшое объяснение того, какую проблему он решает.

Top-level await добавляет поддержку await на верхнем уровне модуля, то есть вне асинхронных функций, которые декларируются с помощью async. Это позволяет превратить модуль в некое подобие большой асинхронной функции. При импорте такого модуля асинхронный код, помеченный с помощью ключевого слова await, будет останавливать выполнение импортирующего модуля до того момента, пока все зависимости не будут зарезолвлены. Вот пример преобразования "асинхронного модуля" с помощью top-level await:

// было
import { process } from "./some-module.mjs";
export default (async () => {
  const dynamic = await import(computedModuleSpecifier);
  const data = await fetch(url);
  const output = process(dynamic.default, data);
  return { output };
})();

// стало
import { process } from "./some-module.mjs";
const dynamic = import(computedModuleSpecifier);
const data = fetch(url);
export const output = process((await dynamic).default, await data);

Добавление в стандарт top-level await упростит работу с динамическими импортами и модулями, предоставляющими асинхронные ресурсы, например, соединение с базой данных.

#future #async #tc39

https://github.com/tc39/proposal-top-level-await

Нашёл в твиттере ссылку на интересную статью Николаса Закаса 2015-го года — "The bunny theory of code".

В статье Николас рассуждает о том, как код похож на кроликов. Стоит немного подождать, и кусочек кода, который находился в одном файле, через некоторое время начинает жить уже в трёх местах. Размножение не зависит от того, хороший это код или плохой, поэтому стоит заботиться о том, какой код попадает в общий репозиторий.

Почему так происходит? Мы редко начинаем писать что-то с нуля в существующем проекте. В первую очередь мы ищем то, как данную проблему решали наши коллеги. Если решение было найдено, то с большой вероятностью оно будет скопировано в новый файл, так как закомиченный код неявно выступает неким гарантом качества. Поэтому стоит делать всё возможное, чтобы поддерживать это качество. Например, с помощью хорошего код ревью, воркшопов, обсуждения спонтанно возникших паттернов (“accidental standards") и т.п.

Читал статью с улыбкой. Николас хорошо описал, как работают разработчики с кодом. По крайней мере, лично я стараюсь не изобретать велосипед в рабочем проекте, но сначала ищу, не был ли этот велосипед изобретён другими.

#musings #programming

https://humanwhocodes.com/blog/2015/05/14/the-bunny-theory-of-code/

Олег @oleg_log Ковалёв скинул в личку ссылку на интересную статью — "Wikipedia's JavaScript initialisation on a budget". В ней рассказывется про то, как ребята из Wikipedia оптимизировали загрузку JavaScript-кода на клиент.

У википедии есть особый механизм — ResourceLoader, который формирует манифест для инициализации динамичной части страницы. С помощью этого манифеста происходит загрузка необходимых ресурсов — js, css, строк i18n. Это самая критичная часть системы, поэтому очень много сил было вложено в то, чтобы уменьшить её размер.

Уменьшение размера было достигнуто благодаря реструктуризации загружаемых скриптов. Например, в одной фиче использовалось 248 разных модуля. Идентификаторы этих модулей попадали в манифест, тем самым увеличивая его размер. Спустя полгода после обнаружения проблемы число модулей удалось снизить до 42. Самое крутое то, что в итоге они смогли достигнуть своей цели в 28kb на размер манифеста (было 36kb, стало 27kb). Такой размер гарантирует, что ресурс будет доставлен на клиент не более чем за две сессии отправки http-пакетов (bursts of packets).

На первый взгляд кажется, что 9kb, которые были сэкономлены, не очень много, но для Wikipedia это складывается в 4 терабайта сэкономленного траффика каждый день.

#performance #http

https://phabricator.wikimedia.org/phame/post/view/175/wikipedia_s_javanoscript_initialisation_on_a_budget/

Реми Шарп написал небольшой пост про то, почему в теге <head> не появляется поддержка новых элементов — "Head is locked".

В <head> могут находится элементы noscript, meta, style, noscript, base и link. Если поместить любой другой элемент в <head>, он будет перемещён внутрь <body>, так работают браузеры. Если бы в стандарте появились новые элементы внутри <head>, то в браузерах без поддержки этих элементов, будет отображаться лишняя информация, нарушая принцип обратной совместимости HTML. Именно по этой причине тег <link> эксплуатируется для разных целей (link rel="preconnect" и т.п.)

#history #html

https://remysharp.com/2019/09/13/head-is-locked

Случайно нашёл небольшую статью про CSS-свойство scroll-behavior, которое является частью чернового стандарта CSS View Module.

При переходе по ссылкам на внутренние части страницы с помощью якорей (ссылки начинающие на символ # ) страница прокручивается резко. Плавную прокрутку можно сделать с помощью JavaScript, но тоже самое можно реализовать с помощью scroll-behavior. Это CSS-свойство поддерживает два значения: auto — для обычного резкого перехода, smooth — для плавной прокрутки к якорю.

Со scroll-behavior: smooth есть две основные проблемы: он не поддерживается в Safari, и он может вызывать укачивание у пользователей. Поддержку в Safari стоит только ждать, а с укачиванием можно побороться с помощью отключения плавного скролла с использованием media query prefers-reduced-motion.

#css #experimental

https://css-tricks.com/almanac/properties/s/scroll-behavior/

В блоге WebKit около двух недель назад появилась статья про статус поддержки WebGPU API в Safari — "WebGPU and WSL in Safari".

Железо и архитектура видеокарт постоянно улучшается. Одновременно с их развитием появляются новые программные API, которые умеют c ними эффективного работать. На сегодняшний день есть Direct3D 12 от Microsoft, Metal от Apple и Vulkan от Khronos Group. Эти API работают на более низком уровне абстракции по сравнению с OpenGL, поэтому они более производительны. Проблема в том, что они не доступны на всех платформах, то есть не могут быть использованы для web'а. Для того чтобы решить эту проблему, разрабатывается новый стандарт для работы с видеокартами — WebGPU.

WebGPU предоставляет набор JavaScript API, с помощью которого рендеринг объектов отделяется от процесса их валидации, тем самым предоставляя разработчикам возможность эффективного управления процессом рендеринга. В статье есть график результатов синтетического бенчмарка. Там видно, что прирост производительность по сравнению с WebGL может увеличиться до семи раз. Есть планы по поддержке WebGPU API из WebAssembly в будущем. В статье ещё немного рассказывается про Web Shading Language (WSL) — новый язык шейдеров, поддержка которого появилась в Safari TP 91. Его основная особенность в том, что он создавался с нуля для поддержки всех платформ и графических API, которые поддерживает WebGPU.

Мне лично непонятно, какая судьба будет у WebGL 2.0. С учётом того, что в разработку WebGPU активно инвестирует Apple, есть риск, что поддержка WebGL 2.0 в Safari так и останется на экспериментальном уровне.

Статью стоит почитать, если вам интересно, как развиваются API для работы с видеокартами.

#webgpu #experimental #safari

https://webkit.org/blog/9528/webgpu-and-wsl-in-safari/

Рекомендую хороший канал @drbrain4web, посвящённый web-разработке (JavaScript и PHP). Ведёт канал fullstack-разработчик Георгий Астахов.

Каждый день в канале публикуются:
- актуальные авторские статьи и переводы,
- тренды,
- примеры кода,
- интересные задачи.

Front & Back. @drbrain4web ждёт вас.

https://news.1rj.ru/str/drbrain4web

Нолан Лоусон недавно написал пост про особенности разработки сайтов под KaiOS — "The joy and challenge of developing for KaiOS".

KaiOS — это набирающая популярность операционная система для бюджетных телефонов. Она очень популярна в Индии. По количеству устройств KaiOS занимает второе место после Android.

В статье рассказывается, как начать разрабатывать под эту операционную систему. KaiOS построена на базе Firefox OS, в основе которой лежит Firefox 48. То есть все приложения в системе — это запакованные web-приложения (html, js, css). Устройства на базе KaiOS, очень ограничены в характеристиках, например, в статье для разработки автор использует Nokia 8110 4G. У этого телефона обычный экран (не сенсорный) с разрешением 240x320. Навигация в системе происходит с помощью клавиатуры. Нолан пишет, что адаптация его проекта под KaiOS помогла с a11y, так как интерфейс стал полностью доступен с клавиатуры.

Очень рекомендую почитать статью, если вы занимаетесь разработкой проектов, использующихся на развивающихся рынках.

#mobile #web

https://nolanlawson.com/2019/09/22/the-joy-and-challenge-of-developing-for-kaios/

В сервисе Google Fonts появилась поддержка вариативных шрифтов. На данный момент она доступна как бета-версия (возможно изменение api в будущем) по адресу https://fonts.googleapis.com/css2.

Если на сайте используется семейство шрифтов с разной насыщенностью и разной шириной глифа (например, condensed), то каждая вариация будет представлена отдельным файлом шрифта. Из-за этого общий объём загружаемых шрифтов на сайтах с богатой типографикой может легко превысить несколько сотен килобайт. Вариативные шрифты решают эту проблему, представляя каждый глиф как контур и предоставляя возможность управления этим контуром. Каждая вариация отрисовывается браузером динамически. Благодаря этому один файл шрифта может использоваться для разных видов типографики.

На данный момент поддержка вариативных шрифтов есть во всех актуальных браузерах. Если интересно узнать больше про особенности их работы, то рекомендую почитать статью "Introduction to variable fonts on the web".

#typography #web

https://codepen.io/nlwilliams/full/JjPJewp

Вчера вышла новая версия Node.JS 12.11.0.

V8 был обновлён до версии 7.7. С новой версией движка в Node.JS улучшилось управление памятью, была ускорена сериализация стектрейсов, в Intl.NumberFormat появилась поддержка единиц измерения, научной и инженерной нотации.

В модуле crypto была добавлена поддержка опции oaepLabel для шифрования RSA-OAEP. Эта опция может использоваться для идентификации сторон, участвующих в обмене информацией.

В модуле events была добавлена поддержка EventTarget в once для лучшей совместимостью с web-платформой.

В модуле fs при работе с файлами можно использовать флаг UV_FS_O_FILEMAP (работает только для Windows). С помощью него файл может быть смаплен в виртуальную память системы. В этом случае изменение и чтение файла будет проксироваться через память (полезно при работе с очень большими файлами).

Модуль worker_threads стал стабилен. Каких-либо изменений в API больше не ожидается. Также был обновлён API inspector для улучшения отладки воркеров.

C этой версии начался процесс добавления в Node.JS поддержки source maps. На данном этапе был добавлен сбор и кеширование source maps в директорию с покрытием при установке переменной окружения env.NODE_V8_COVERAGE.

#release #node

https://github.com/nodejs/node/releases/tag/v12.11.0

Сегодня будет ещё один релизный пост. Пару часов назад в блоге V8 появился анонс фич, которые попадут в версию 7.8.

Script streaming — загрузка скриптов из сети в парсер без ожидания главного потока Chrome — теперь будет работать для preload-скриптов (в Chrome 76 и выше). Эта фича позволит сократить время инициализации страницы.

При компиляции JavaScript в байткод движок собирает специальные таблицы, которые матчат байткод на конкретные позиции в исходном коде. Эти таблицы потребляют память. С версии 7.8 они будут генерироваться, только во время создания стектрейсов. Разработчики пошли на компромисс, так как эта операция требует повторного парсинга и перекомпиляции. В результате потребление памяти было уменьшено на 1-2.5%.

Ускорили деструктуризацию объектов и работу регулярных выражений в случае, когда искомый паттерн не может быть найден в строке.

Поддержка Wasm С/C++ API перешла из экспериментального статуса в официальный. Это API позволяет использовать V8 как движок для исполнения WebAssembly в C/C++-приложениях. Был ускорен старт wasm-модулей.

#release #v8

https://v8.dev/blog/v8-release-78

Элад Шехтер в статье "Complete Guide to Responsive Images!" рассказал про все подходы, которые можно использовать при создании адаптивных изображений.

В статье разбирается использование тега <picture> и тега <img> c атрибутами srcset и sizes для разных изображений в зависимости от плотности пикселей и ширины вьюпорта. Разбирается использование CSS-свойства image-set и CSS-функции image(). С помощью функции image() (её поддержки пока нет в браузерах) можно будет обрезать изображение и использовать в background-image изображение того типа, которое может быть отображено браузером.

Мне статья показалась чересчур справочной — не хватило живых практических примеров. Тем не менее она может послужить отличной стартовой точкой для изучения темы адаптивных изображений.

На Девшахте есть хороший перевод статьи.

#web #image #responsive

https://medium.com/@elad/a-complete-guide-for-responsive-images-b13db359c6c7

Прошло уже больше полугода с момента создания Defront. Меня иногда спрашивают о том, как появился канал и как создаются посты. Хочу про это написать небольшой пост.

Если кто-нибудь мне сказал раньше, что я буду вести канал, я бы не поверил. Но сейчас в канале уже около 250 постов, и, определённо, будет ещё больше. Как так получилось? В 2017-2018 году я выпал из информационного поля и читал только то, что было нужно по работе. В начале этого года после прочтения небольшой статьи в голове что-то "щёлкнуло" — я решил поделиться прочитанным со своими коллегами в виде небольшого пересказа. Мне этот формат показался очень интересным. В итоге я поставил себе цель читать что-то новое и делиться прочитанным каждый день.

Обычно на подготовку одного поста уходит два часа, иногда больше, иногда меньше. Всё зависит от темы. Иногда тема понятна, и пост даётся легко. Иногда тема сложная, и для написания поста необходимо читать дополнительные статьи и код.

Один из основных источников информации — это twitter. Я там сижу под ником @myshov, кстати рекомендую зафолловить, так как ретвичу и твичу полезности, которые не попадают в канал. Все потенциально интересные ссылки сохраняю в заметках и потом просматриваю, удаляя не очень информативные. Потом выбираю наиболее интересную статью, читаю, погружаюсь в тему и публикую про неё пост.

Вот такой вот флоу.

Очень рад, что в итоге мой контент нашёл своего читателя. Спасибо за то, что читаете Defront.

P.S. Подключил к каналу чат для обсуждения материалов — @defrontchat. Welcome!

Посмотрел доклад 2018 года Расса Олсена про функциональное программирование — "Functional Programming in 40 Minutes".

В отличие от статей про ФП, в которых говорится забыть все концепции программирования, Расс говорит о том, что не надо их выкидывать — их надо взять и немного порефакторить. Он на примере показывает как существующие концепции, которые известны всем программистам живут в ФП. Рассказывает про "три столпа" функционального программирования — чистые функции, иммутабельность и работу с сайд эффектами. Работа с сайд эффектами разбирается на примере Clojure — Атомы/Агенты/Акторы.

Название доклада немного кликбейтное, но содержание хорошее. Доклад будет полезен тем, кто только начинает разбираться с ФП. Рекомендую посмотреть, если интересуетесь этой темой.

#talk #fp #clojure

https://www.youtube.com/watch?v=0if71HOyVjY

Джейсон Григсби — автор книги Progressive Web Apps (A List Apart) — попробовал заказать еду на сайте, но с первой попытки у него это не получилось. Он разобрался в причинах и написал про результаты своего небольшого исследования статью "An HTML attribute potentially worth $4.4M to Chipotle".

На сайте было сломано автодополнение данных кредитных карт. Данные карты были сохранены в браузер правильно, но при их вводе в форму с помощью автодополнения что-то шло не так. Причина оказалась в Angular-модуле ui-mask, он неправильно отсекал год истечения срока действия карты. Автор попробовал использовать вместо кастомной маски стандартные HTML5 средства валидации формы pattern="\d\d" и maxlength="2". Проблема с автодополнением года была решена.

Проводились исследования, которые показывают, что автодополнение ускоряет заполнение форм на 30%. Скорость заполнения форм в свою очередь влияет на конверсию в заказ. Джейсон провёл грубые расчёты, которые показали, что сайт Chipotle теряет более 4 миллионов долларов в год из-за проблем с автодополнением.

Рекомендации из статьи: если у вас e-commerce сайт, убедитесь, что автодополнение данных кредитных карт работает, добавьте кейс проверки автодополнения в тест-план, используйте корректные поля ввода в формах.

#ux #forms

https://cloudfour.com/thinks/an-html-attribute-potentially-worth-4-4m-to-chipotle/

🎂 Сегодня исполняется 25 лет Консорциуму Всемирной Паутины (W3C)!

https://www.w3.org/blog/2019/10/happy-25th-anniversary-world-wide-web-consortium/

Несколько дней назад Cloudflare анонсировал экспериментальную поддержку HTTP/3 на своих серверах — "HTTP/3: the past, the present, and the future".

Чтобы ответить на вопрос, какую проблему решает новая версия протокола, надо для начала разобраться с HTTP/2. Основная польза от HTTP/2 — мультиплексирование запросов в рамках одного TCP-соединения. То есть если запрашивать классическую web-страницу по HTTP/2, то js/css-файлы, изображения и другие ресурсы будут передаваться параллельно друг другу, не создавая соединение на каждый запрос.

Загвоздка заключается в том, что HTTP/2 работает поверх TCP. Для TCP нет разницы, передаются ли по нему данные с помощью HTTP/1.1 или HTTP/2. Если во время параллельной передачи данных с помощью HTTP/2, какие-то байты, например из изображения, будут потеряны, возникнет пустой промежуток в потоке, который должен быть восстановлен. TCP работает так, что все успешно доставленные байты после обнаружения потери (даже если они не относились к изображению) не могут быть доставлены в приложение. То есть они будут ждать, пока данные будут восстановлены. Эта проблема известна под названием “head-of-line blocking”. HTTP/3 решает эту проблему, используя новый транспортный протокол QUIC. Также QUIC уменьшает количество запросов, необходимых для установки соединения.

На данный момент поддержка HTTP/3 есть в Google Chrome Canary за флагом и в экспериментальной версии curl. Разработчики Firefox обещают поддержку в ближайшем будущем. Есть реализация HTTP/3 клиента и сервера от cloudflare — quiche.

Теперь остаётся только ждать, когда стабилизируется стандарт, чтобы началось его массовое внедрение. Для меня самая крутая фича из нового протокола, которую планируют добавить в будущем, "connection migration" — бесшовная и прозрачная миграция между сетями. Благодаря ему можно будет забыть про паузы во время трансляции видео при переключении с Wi-Fi на LTE, а носимые девайсы станут по-настоящему always connected.

#http #performance #announcement

https://blog.cloudflare.com/http3-the-past-present-and-future/

Пару дней назад Рик Вискоми в блоге web.dev написал пост про то, как измерять и исправлять нестабильность раскладки элементов на странице — "Fixing layout instability".

С версии Chrome 77 появилась возможность измерять смещение отображаемого контента во время его загрузки с помощью нового Layout Instability API. Это не критичная, но важная для UX метрика, с помощью которой можно измерить "приятность" загрузки данных.

В статье на примере тестового сайта рассматривается, как собрать эту метрику с помощью WebPageTest, и что можно сделать, чтобы контент не прыгал. Например, при загрузке веб-шрифтов стоит использовать font-display: swap, чтобы до загрузки кастомного шрифта отображался шрифт, использующийся в системе. Также можно использовать плейсхолдеры, если известно, какой тип контента будет загружен.

В статье про это не написано, но хочу добавить, что для предварительной оценки масштаба проблемы со смещением контента необязательно собирать метрику. Достаточно загрузить страницу с троттлингом соединения.

#ux #performance

https://web.dev/fixing-layout-instability

Прочитал статью про атаку, про которую как-то не приходилось слышать раньше — "Slow Loris attack using JavaScript on a PHP Server".

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

Современные web-серверы из коробки идут с защитой от этой атаки, но она актуальна для кастомных серверов. Один из вариатов защиты от атаки, описанный в статье, использование reverse-proxy на nginx, с ограничением числа одновременных соединений от одного ip-адреса.

#security #http #tcp

https://www.freecodecamp.org/news/slow-loris-attack-using-javanoscript-on-php-server/