Мануэль Матузович написал хорошую статью про проблемы автоматического тестирования доступности — "Building the most inaccessible site possible with a perfect Lighthouse score".

В статье рассказывается, как написать недоступный сайт, который будет выбивать в Lighthouse 100%. Для этого автор поэтапно делает html-страницу нечитабельной, недоступной для скринридеров, с неработающим режимом чтения в браузерах, не реагирующей на клики мыши и на нажатие клавиш клавиатуры. Каждое изменение не влияет на 100% показатель доступности в Lighthouse. Этим всем Мануэль доказывает, что полагаться только на инструменты автоматического тестирования доступности нельзя, их надо обязательно дополнять ручными проверками.

В общем, рекомендую почитать. В статье есть ссылки на хорошие статьи по теме.

#a11y #lighthouse

https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/
https://habr.com/ru/post/455016/ (перевод)

Для ускорения установки соединения с доменами, на которых находятся загружаемые ресурсы, используют хинты dns-prefetch и preconnect. Дэниэл Александерсен рассказал как их правильно использовать в статье "What to <link rel=dns-prefetch> and when to use preconnect".

Самая распространённая ошибка при использовании dns-prefetch — добавление доменов, ссылки на которые уже есть в html-документе. В этом нет особого смысла, так как браузер будет устанавливать соединение во время парсинга документа. Наибольшую выгоду от использования dns-prefetch можно получить, если домен неизвестен на момент парсинга документа, например, когда установка соединения с новым доменом происходит при выполнении загруженного кода. Другой хинт — preconnect — не только резолвит доменное имя, но и устанавливает TCP-соединение. Это может быть очень полезно на мобильных устройствах.

Если хотите узнать больше подробностей про использование dns-prefetch и preconnect, рекомендую почитать статью.

P.S. Передаю спасибо @oleg_log за ссылку.

#net #performance

https://www.ctrl.blog/entry/dns-prefetch-preconnect.html

Брайан Гринстед — разработчик Firefox — рассказал как происходила миграция интерфейса Firefox на web-компоненты — "The Firefox UI is now built with Web Components".

Для разработки интерфейса Firefox используется XUL (XML User Interface Language). Этой технологии уже больше двадцати лет. Впервые она появилась в прародителе Firefox — Netscape в 1997 году. XUL разрабатывался для унификации разработки интерфейса браузера на разных платформах (Windows, Linux, Mac OS X). Для описания внешнего вида и поведения элементов интерфейса браузера используется XBL (eXtensible Bindings Language). Пару недель назад XBL был полностью заменён на web-компоненты. Это важное событие для разработчиков браузера на пути к полному отказу от XUL в пользу стандартных web-технологий. Переход на web-технологии упростит кодовую базу и ускорит добавление новых фич.

По ходу переноса, конечно, были проблемы. Вот интересный случай из статьи: "Также был пользователь, у которого было открыто полторы тысячи вкладок. Он заметил сильные тормоза при открытии списка "All tabs". Оказалось, что он попал в пограничный случай, в котором алгоритм работал за O(N²). Проблема была исправлена".

Очень рекомендую почитать статью. Про опыт большого рефакторинга разработчики браузеров пишут нечасто.

#firefox #webcomponents #internals

https://briangrinstead.com/blog/firefox-webcomponents/

На Mozilla Hacks пару дней назад появилась статья Рейчел Эндрю про column-span — "Multiple-column Layout and column-span in Firefox 71".

В многоколоночной разметке контент непрерывно "перетекает" из одной колонки в другую. Эта разметка очень популярна в газетах и журналах, так как улучшает читабельность текста. Спецификация Multiple-column Layout описывает необходимые свойства для создания такой разметки. В рамках этой спецификации описывается свойство column-span, с помощью которого можно стилизовать элементы так, чтобы они занимали несколько колонок сразу, например, как заголовок в газете. С релизом Firefox 71 column-span будет поддерживаться во всех современных браузерах.

В статье рассказывается о том, как работает это свойство и какие были проблемы при его добавлении в спецификацию.

#css #specification #layout

https://hacks.mozilla.org/2019/11/multiple-column-layout-and-column-span-in-firefox-71/

Ришаб Рао из Yelp написал статью про то, как они используют subresource integrity при подключении скриптов со сторонних CDN — "Organizing and Securing Third-Party CDN Assets at Yelp".

Subresource integrity — это механизм, который позволяет гарантировать блокирование выполнения кода, который был скомпроментирован на стороне CDN-провайдера. Это достигается с помощью добавления атрибута integrity в тег noscript. В атрибуте находится хэш загружаемого скрипта. В Yelp не используют хэши, которые предоставляются CDN — они генерируют хэши сами. Для хэширования используют алгоритм SHA-384, так как он наименее подвержен атаке length extension. Суть этой атаки сводится к добавлению в скомпроментированный скрипт дополнительного текста таким образом, чтобы не менялся результат хэширования.

Рекомендую почитать статью, если интересуетесь темой безопасности.

#security #cdn #sri

https://engineeringblog.yelp.com/2019/11/organizing-and-securing-third-party-cdn-assets-at-yelp.html

P.S. Отписался в issue cdnjs про использование SHA-384 (https://bit.ly/2QHGYAx). Будет здорово, если SHA-384 будет использоваться по умолчанию. Сейчас там используется SHA-256.

В статье Эдди Османи "The cost of JavaScript in 2019", про которую я писал пару месяцев назад, есть рекомендация про ускорение загрузки в память больших объектов. Вместо использования обычных объектов в статье рекомендуется использовать JSON.parse().

Пару дней назад было опубликовано видео, в котором Матиас Байненс — разработчик V8 — объясняет, почему использование JSON.parse() быстрее. Для того, чтобы распарсить объект, который представлен в виде обычного литерала в коде JavaScript, парсеру необходимо совершить гораздо больше работы на этапе токенизации. Во время же исполнения JSON.parse('{"key": 123}') парсеру надо делать меньше работы, так как грамматика JSON гораздо проще грамматики JavaScript. Использование такого подхода даёт буст в скорости не только в V8 (1.7x), но и в движках других браузеров: JavaScript Core (Safari) — 2x, SpiderMonkey Firefox) — 1.2x. Webpack уже автоматически применяет эту оптимизации при импорте JSON-файлов, ещё можно воспользоваться Babel-плагином для автоматического преобразования объектов.

Ну что сказать. Повышайте Time to Interactive — используйте JSON.parse().

#js #performance #json

https://www.youtube.com/watch?v=ff4fgQxPaO0

Илья Стрельцын написал небольшой пост про развитие CSS — "CSS4 не будет… потому что он давно прошел. Встречайте CSS8!".

На данный момент не существует такого понятия как "версия CSS", потому что спецификация для упрощения поддержки была разбита на модули с независимым версионированием. Но было бы неплохо иметь какой-нибудь неофициальный ориентир для отслеживания развития спецификации в целом. Таким ориентиром Илья предлагает взять раздел "The Official Definition" документа "CSS Snapshot". У этого документа есть пять редакций c 2007 года. До разбития на модули у CSS было две версии, поэтому можно сказать, что актуальная на данный момент версия CSS — "CSS7".

В статье описаны основные вехи, которые происходили при развитии спецификации. Рекомендую почитать, если интересно узнать про историю развития стандарта.

#musings #css #specification

https://css-live.ru/css/css4-ne-budet-potomu-chto-on-davno-proshel-vstrechajte-css8.html

Иногда в интерфейсах можно встретить эффект "прыгающих цифр". Например, в таймере который отображает время или в числе, которое меняется при прокрутке слайдера. Робин Рэндл написал статью "The Smallest Difference" про исправление этого эффекта на примере таблиц.

В шрифтах OpenType для некоторых символов есть альтернативные глифы, отображение которых можно включать с помощью CSS. Для цифр есть альтернативный глиф перечёркнутого нуля, глифы старого и моноширинного стиля. Использование последнего стиля как раз и может решить проблему "прыгающих цифр". Для этого необходимо подключить OpenType-шрифт с такой возможностью (у меня заработало с шрифтом -apple-system) и добавить к необходимому контенту CSS-свойство font-variant-numeric: tabular-nums;. Использовании tabular-nums в таблице с большим количеством чисел очень положительно сказывается на читабельности. В статье есть гифка, где хорошо виден эффект от применения этого свойства.

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

#css #ui #ux

https://www.robinrendle.com/notes/the-smallest-difference.html

Валерий Щавель из Яндекс.Карт рассказал на хабре про опыт использования WebAssembly — "Как мы внедряли WebAssembly в Яндекс.Картах и почему оставили JavaScript".

В Яндекс.Картах объекты перед отрисовкой разбивают на треугольники прямо в браузере. Это ресурсоёмкая задача, которую решили попробовать вынести на уровень WebAssembly. Ребята сделали прототип, который использует wasm, и внедрили его в своё TypeScript-приложение. Скорость обработки тайлов выросла в несколько раз, но появилась просадка из-за накладных расходов на передачу данных из wasm в js. Также вырос размер бандла (в комментариях пишут, что это скорее всего из-за неиспользуемых фич emnoscripten). В итоге от WebAssembly на данный момент решили отказаться.

Статья интересная. Советую почитать, если интересуетесь темой WebAssembly.

#webassembly #experience #yandex

https://habr.com/ru/company/yandex/blog/475382/

Medium и похожие сайты при добавление ссылок в пост магическим образом превращают их в виджеты. Например, ссылка на твит может превратиться в текст из твита, а ссылка на youtube — в видеоплеер. Дрю Маклеллан рассказал, как это работает — "Programmatically Discovering Sharing Code With oEmbed".

Некоторые ресурсы дают возможность встраивания своего контента на других сайтах, предоставляя специальный код. Если мы хотим "разворачивать" ссылки в виджеты на своём сайте, можно взять этот код и немного его доработать так, чтобы он формировался динамически. Но это неудобный вариант, если надо обрабатывать ссылки с большого количества сервисов. Для решения этой проблемы была разработана спецификация oEmbed. Суть её простая. Если вы запросите страницу с youtube-видео (или с другим ресурсом, который поддерживает oEmbed), там в теге link будет ссылка на json, в котором будет вся необходимая информация для встраивания на страницу: <link rel="alternate" type="application/json+oembed" href="http://www.youtube.com/oembed..." noscript="Some video">.

Про oEmbed узнал сегодня впервые, хотя он существует с 2008 года.

#web #specification

https://www.smashingmagazine.com/2019/11/programmatically-discovering-sharing-code-oembed/

Увидел сегодня в твиттере ссылку на статью про код ревью от разработчика из Red Hat Дэвида Лойда — "10 tips for reviewing code you don’t like".

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

1. сделайте из возражения вопрос;
2. избегайте преувеличений;
3. не насмехайтесь;
4. ведите диалог в позитивном ключе;
5. помните, что не у всех одинаковый опыт;
6. не преуменьшайте сложность того, что неочевидно;
7. проявляйте уважение;
8. управляйте ожиданиями (и своим временем);
9. говорите "пожалуйста";
10. начинайте обсуждение, если возникает недопонимание.

Статья хорошая. Очень рекомендую почитать всем, кто работает в команде или занимается поддержкой open source проекта.

#musings #codereview #programming

https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like/

Недавно в Node.js 13.2.0 появилась стабильная поддержка ECMAScript modules. Это событие можно считать началом "Великого исхода с CommonJS на ESM". Шучу. CommonJS будет продолжать жить и здравствовать, пока вся экосистема JS не перейдёт на нативную модульную систему. Тем не менее разработчикам библиотек теперь надо иметь в виду, что пакеты могут быть импортированы в CommonJS- и ESM. Какими способами можно поддержать оба окружения, Аксель Раушмайер рассказал в статье "Hybrid npm packages (ESM and CommonJS)".

Основным механизмом для создания гибридных пакетов будет новое поле exports в package.json, поддержка которого находится в экспериментальном режиме за флагом --experimental-conditional-exports. Благодаря ему один и тот же спецификатор импорта можно будет использовать как в CommonJS, так и в ESM. Логика работы exports похоже на switch-case. Символ точки используется для обозначения main:

{
  "type": "commonjs",
  "main": "./commonjs/entry.js",
  "exports": {
    ".": {
      "require":  "./commonjs/entry.js",
      "default": "./esm/entry.mjs"
    }
  }
}

Node.js поддерживает условия: require — для импортов из CommonJS, node — для Node.js, default — для всех импортов, не попавших под условие require и node. Другие платформы и инструменты могут поддерживать свои собственные условия, например: browser, electron, deno, react-native.

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

#esm #nodejs #npm

https://2ality.com/2019/10/hybrid-npm-packages.html

Скорее всего мы все сталкивались с эффектом "прыгающей страницы", когда при чтении статьи на экране смартфона текст прыгает из-за загружающихся изображений. Как этого избежать, Крейг Баклер рассказал в статье "Jank-free page loading with media aspect ratios".

Страница сдвигается из-за того, что в макетах с отзывчивым дизайном мы не можем задать жёсткие размеры у изображений, чтобы браузер зарезервировал для них место, так как размер может быть любым. Но браузер может рассчитать размер изображения, зная пропорции изображения и его ширину или высоту. В будущих версиях Chrome и Firefox появится поддержка определения пропорций на основе атрибутов width и height. Также разрабатывается спецификация для нового CSS-свойства aspect-ratio. Но пока поддержка пропорций не появится во всех браузерах, можно использовать трюк с пропорциональным отступом (если для padding использовать проценты, то отступ будет высчитываться на базе ширины элемента).

Концептуально проблема с "прыгающей страницей" решена в спецификации Scroll Anchoring. Проблема в том, что на данный момент эта спека не поддерживается Safari и, соответственно, всеми браузерами на iOS.

Статья на удивление очень подробная для такой специфичной темы. Очень рекомендую почитать.

#css #specification #ui

https://blog.logrocket.com/jank-free-page-loading-with-media-aspect-ratios/

Недавно увидел твит от разработчика Chrome, в котором он написал, что перевод пропозала Temporal в stage 3 запланирован на февраль. Temporal — это современная замена объекта Date. В 2017 году Мэгги Джонсон-Пит написала две статьи про причины добавления в стандарт нового объекта — "Fixing JavaScript Date".

API существующего объекта Date было скопировано в 1995 году из Java. Это были ранние годы для Java, поэтому java.Util.Date там был плохо проработан. Всё было настолько плохо, что в Java 1.1, которая была выпущена в 1997 году, фактически все существующие методы были объявлены устаревшими и заменены новыми. В JavaScript не было исправлений Date из-за того, что это бы сломало web.

Спустя 20 лет было решено сделать независимую реализацию API для работы с датами и временем, которая получила название Temporal. Её ключевые отличия от Date: иммутабельность, исправленный парсинг строки в дату, исключение дополнительной секунды, добавлены методы для работы с временными зонами, предусмотрено будущее расширение спецификации для работы с негригорианскими календарями и т.п.

Библиотеки для работы со временем потеряют свою актуальность, после того как Temporal будет поддержан во всех браузерах. Для того чтобы не сломать старые браузеры, можно будет пользоваться полифиллом.

#date #tc39 #history #future

https://maggiepint.com/2017/04/09/fixing-javanoscript-date-getting-started/
https://maggiepint.com/2017/04/11/fixing-javanoscript-date-web-compatibility-and-reality/

C 2009 года проходит событие, когда весь декабрь на сайте calendar.perfplanet.com публикуются статьи про производительность. Первого декабря появилась статья Стояна Стефанова, про то как отслеживать деградацию производительности компонентов — "JavaScript component-level CPU costs".

Стоян предлагает измерять производительность количеством инструкций, которые требуются процессору для рендеринга компонентов. Количество инструкций, в отличие от времени, более предсказуемая величина, так как она не сильно зависит от окружения. Получить количество инструкций можно с помощью трассировки в Chrome. Автоматизировать сбор метрик можно с помощью Puppeteer. Но не всё так гладко, так как для выполнения одного и того же кода может требоваться разное количество инструкций из-за сборщика мусора или оптимизаций. Чтобы корректно подсчитать метрику, не рекомендуется запускать один и тот же код несколько раз. Для того чтобы исключить операции, вызванные GC, необходимо вычесть количество инструкций GC (можно получить в трассировке) из общего количества инструкций.

Идея интересная, но мне кажется сомнительным гонять эти проверки перед каждым коммитом, как предлагается в статье.

#performance #ui #chrome

https://calendar.perfplanet.com/2019/javanoscript-component-level-cpu-costs/

Вчера вышел Firefox 71. Крис Миллс из Mozilla рассказал о последних новинках в браузере — "Firefox 71: A year-end arrival".

В этом релизе очень много сил было вложено в инструменты разработчика. Сейчас панель с консолью открывается на 40% быстрее. Добавили многострочный редактор кода для консоли (попробовал, очень удобная штука). Есть изменения в панели "Network": теперь можно искать по всем загруженным ресурсам, блокировать загрузку любых ресурсов и дебажить вебсокеты. Во время отладки рядом со строками кода появляется inline-превью переменных (также как в Chrome Dev Tools). Если в панели с брекпойнтами на событиях поставить галку "log", то браузер будет логировать события в консоль, не останавливая выполнение кода.

В CSS была включена поддержка clip-path: path для создания произвольных масок. Включена поддержка сабгридов. Добавлен column-span для многоколоночных макетов. Высота и ширина изображений теперь влияют на внутреннее свойство aspect-ratio, которое позволяет автоматически выделять место под изображения в отзывчивых макетах.

Есть несколько улучшений в JavaScript и платформе. Добавлен Promise.allSettled. Частично реализован Media Session API, который позволяет отправлять в операционную систему информацию о проигрываемом контенте на странице, например, номер трека, названии альбома, песни и т.п. Включили поддержку расширения WebGL OVR_multiview2, которое используется для производительной отрисовки VR-контента.

Самая заметная пользовательская фича — "картинка в картинке" для видео. Включена по умолчанию пока только в Windows.

#release #firefox

https://hacks.mozilla.org/2019/12/firefox-71-a-year-end-arrival/

Джонатан Блоу — известный разработчик из мира игровой индустрии — в этом году приезжал в Москву, где он выступил с докладом "Preventing the Collapse of Civilization".

Развитие компьютерной индустрии и добавление абстракций идут бок о бок. Со временем число абстракций растёт, увеличивая сложность. С увеличением сложности увеличивается количество багов и снижается надёжность программ. В девяностых-двухтысячных среди вендоров железа и ПО была популярна фраза "Five 9s". Она означала, что система будет доступна 99.999% времени. Сейчас этот термин вышел из оборота.

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

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

#talk #musings

https://www.youtube.com/watch?v=pW-SOdj4Kkk

Вчера на calendar.pefrplanet.com была опубликована статья Ника Джансма — разработчика Akamai — про оптимизацию библиотеки для сбора RUM (Real User Metrics) — "Boomerang Performance Update".

Boomerang — это библиотека с открытым исходным кодом. Она используется под капотом mPulse (сервис для сбора RUM-метрик от Akamai). В 2017 году был проведён аудит Boomerang, который выявил узкие места. Загрузчик основного скрипта использовал динамически создаваемый iframe. На старых девайсах создание iframe несло дополнительные издержки, увеличивая время инициализации на 20-40мс. После перехода на link preload в браузерах, которые его поддерживают, время инициализации уменьшилось до 1мс. Для сбора таймингов ресурсов сайта, они используют префиксное дерево (Trie), которое также было неоптимизировано. После исправления функция оптимизации дерева стала работать в четыре раза быстрее. Чтобы уменьшить размер основного скрипта, алгоритм хеширования MD5 был заменён на FNV-1. Скрипт уменьшился на 8 килобайт.

Статья очень интересная. Рекомендую почитать всем, кто интересуется темой оптимизации сайтов.

#performance #algorithm #library

https://calendar.perfplanet.com/2019/boomerang-performance-update/

В этом году на React Conf был хороший доклад от Джен Крейгтон — "React is Fiction".

Джен в университете изучала литературу и хотела писать книги, но в итоге стала web-разработчиком. В докладе она рассказывает про принципы, использующиеся при написании книг, и как они ложатся на разработку на примере React-компонентов. Принцип "показывайте, а не рассказывайте" очень сильно пересекается с декларативностью. "У каждого персонажа должна быть мотивация" — с поиском подходящих границ между разными компонентами. "Пишите то, что знаете" — про баланс между KISS и DRY.

Доклад очень хороший. Рекомендую посмотреть, даже если вы не используете React.

#talk #react #musings

https://www.youtube.com/watch?v=kqh4lz2Lkzs

Майк Ритмюллер несколько недель назад поделился своими мыслями про управление стилями в современных приложениях — "CSS Architecture for Modern JavaScript Applications".

Майк пишет про то, что использование современных подходов для управления стилями без планирования может вызвать проблемы в будущем. Например, переиспользование компонентов может стать невозможным, если не использовать принципы абсолютно независимых блоков. Недостаточно поделить макет на прямоугольники — нужно спланировать раскладку и то как с ней будут взаимодействовать презентационные компоненты. Для управления состоянием предлагает использовать переосмысленные типы состояний, позаимствованные из SMACSS. В статье есть пример этого подхода, но он мне показался сложным для восприятия. Имхо, для описания сложных состояний компонентов хорошо подходит старый-добрый БЭМ.

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

#css #musings #architecture

https://www.madebymike.com.au/writing/css-architecture-for-modern-web-applications/