Эмили Старк из команды Google Chrome поделилась советами о том, как эффективно читать спецификации web-стандартов — "Tips for reading web standards".

Многие стандарты обновляются часто по мере развития браузеров. Поэтому в первую очередь нужно смотреть последние черновики спецификаций (editor’s/latest draft), которые включают в себя все последние нововведения. Очень помогает в понимании спецификации вводная часть (explainer). Её Эмили советует читать от начала до конца, так как она содержит информацию для упрощения понимание спеки в целом. С другой стороны, чтобы разобраться в поведении какой-либо фичи, читать саму спецификацию от начала до конца не обязательно.

Статья небольшая, но полезная. Рекомендую почитать.

#spec

https://emilymstark.com/2021/03/14/tips-for-reading-web-standards.html

За прошедшие две недели в канале для патронов Defront было опубликовано десять постов:

— Ускорение рендеринга страниц сайта с помощью prefetch
— Ленивая загрузка компонентов React Native
— Лучшие практики и их влияние на производительность
— Опыт использования WebRTC в большом проекте
— Частые ошибки при работе с промисами и async/await
— Исследование производительности страницы с помощью Cloudflare Workers
— Тайпгарды TypeScript для валидации данных
— Мысли об управлении состоянием приложения
— Использование мобильного Safari для анализа производительности
— Влияние наложения элементов на лишние перерисовки

Становитесь патроном канала на Patreon, чтобы получить доступ к дополнительным постам в Defront Plus. На данный момент Patreon мой единственный источник дохода; все донаты идут на покупку еды, оплату аренды квартиры и т.п.

Спасибо всем, кто читает и поддерживает Defront!

https://www.patreon.com/myshov

Хемант — делегат TC39 — опубликовал статью, посвящённую "Error Cause" — предложению о добавлении в стандарт ECMAScript.

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

Для того чтобы причину оригинальной ошибки можно было найти в предсказуемом месте, например это важно при разработке DevTools, в пропозале "Error Cause" предлагается передавать оригинальную ошибку с помощью объекта со свойством cause вторыми параметром в конструктор объекта Error:

throw new Error('There was a problem', {
    cause: err
});

На данный момент пропозал "Error cause" находится на третьем этапе добавления в стандарт. Его поддержка уже есть в JS-движках Chakra и JavaScriptCore.

#js #proposal

https://dev.to/hemanth/error-cause-in-javanoscript-425d

В блоге DebugBear была опубликована статья, посвящённая распространённым проблемам при работе с <link rel="preload">, — "Common problems with rel='preload'".

Предзагрузка слишком большого числа ресурсов с большой вероятностью приведёт к медленной загрузке страницы. В этом случае канал будет перегружен, и в итоге страница загрузится медленнее по сравнению с тем, если бы на ней вообще не использовалась предзагрузка. Ещё одна частая проблема — предзагрузка шрифтов без атрибута crossorigin. Дело в том, что браузеры загружают шрифты в анонимном CORS-режиме (то есть без отправки кук). В случае с обычной предзагрузкой (без атрибута crossorigin ) куки отправляются, что приводит к расхождению запросов (один с куками, второй без кук), и из-за этого браузер будет загружать один и тот же шрифт два раза.

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

#performance

https://www.debugbear.com/blog/rel-preload-problems

Бен Фрейн рассказал о новом черновике спецификации вложенности в CSS — "CSS Nesting – the last piece of the puzzle".

Недавно Адам Аргайл представил сообществу черновик спецификации, над которым он работает вместе с Табом Аткинсом. В этой спецификации описывается синтаксис вложенности, который похож на аналогичный синтаксис из SASS и LESS. Основное отличие — нужно использовать @nest при размещения вкладываемого селектора в качестве потомка:

.selector {
    width: 100%;
    @nest .other-selector & {
        color: #333;
    }
}

На данный момент черновик ещё не стабилизировался, и синтаксис описания вложенности скорее всего поменяется, также он пока не поддерживается ни в одном браузере. Бен пишет, что через пару лет все браузеры будут поддерживать вложенность в CSS, и для многих проектов препроцессоры перестанут быть актуальны.

#css #proposal

https://benfrain.com/official-css-nesting-the-last-piece-of-the-puzzle/

Big news everyone!

Я присоединился к Russian MDN Team — буду помогать поддерживать русскоязычную часть MDN (перевод сайта, перевод и улучшение документации, ревью входящих пулл реквестов и т.п.) Моя работа над MDN — это волонтёрская деятельность, и она была бы невозможна без вас.

Спасибо за то, что читаете и поддерживаете канал!

Эрик Лоуренс из команды разработки Edge рассказал про особенности работы метода window.close в разных браузерах — "window.close() Restrictions".

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

Все браузеры реализуют close немного по-разному. Это связано с тем, что стандарт был написан уже после того, как close появился браузерах. Chromium, например, не проверяет, была ли страница открыта с помощью JS, а смотрят на наличие opener.

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

#js

https://textslashplain.com/2021/02/04/window-close-restrictions/

Chrome 92 будет предотвращать небезопасный доступ к сервисам локальной сети. Обо всех подробностях рассказали Эиджи Китамура и Титуан Ригоди в статье "Private Network Access (CORS-RFC1918) updates".

Сейчас сайты могут без проблем обращаться к ресурсам из локальной сети. Например, внешний сайт компании может отправлять какую-нибудь статистику в интранет-сеть для тех пользователей, у которых есть к ней доступ. Такая политика небезопасна, так как любой внешний сайт может отправить любой запрос не только к внутреннем сайтам, но и к роутеру или принтеру пользователя. Подобным образом в 2014 году были взломаны более 300 тысяч роутеров по всему миру.

Начиная с Chrome 90 браузер будет предупреждать о небезопасных запросах при обращении к ресурсам локальной сети. В Chrome 92 такие запросы перестанут работать по умолчанию. Чтобы они продолжали работать, сайт-инициатор запроса и целевой сайт должны работать по HTTPS. Также в будущем будут проверяться CORS-заголовки, разрешающие доступ к ресурсу (пока эта часть спецификации находится на стадии обсуждения).

#security #chrome

https://developer.chrome.com/blog/private-network-access-update/

Джереми Вагнер рассказал о своём опыте использования сервис воркеров — "Now THAT’S What I Call Service Worker!".

Джереми работал с сайтом клиента, который часто посещают пользователи с ненадёжным подключением к сети. Добавление сервис воркера со стандартной схемой кэширования всего ответа улучшило метрики производительности на 10-20%. Дальнейшее его улучшение с помощью сохранения заголовка и подвала сайта в оффлайнт-кеше и динамического формирования всей страницы в сервис воркере улучшило FCP на 40%, а LCP на 51%. В статье есть пример с подробной реализацией этой стратегии.

Выводы из статьи. Даже самая базовая интеграция сервис воркера даёт преимущества по сравнению с обычным HTTP-кешированием.

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

#performance #serviceworker

https://alistapart.com/article/now-thats-what-i-call-service-worker/

One more big news everyone!

У канала появился генеральный спонсор — Зарплата.ру. Зарплата.ру будет поддерживать всю мою работу для сообщества (Defront, MDN и т.п.) С ребятами из Зарплаты я знаком уже несколько лет. Они из Новосибирска, смело экспериментируют с технологиями у себя в компании и принимают участие в жизни IT-сообщества.

Зарплата.ру согласилась поддерживать Defront с сохранением полной независимости канала. Единственное изменение — в канале будут появляться дополнительные сообщения от спонсора два раза в месяц.

Я очень рад нашему сотрудничеству. Надеюсь, что оно будет очень продуктивным!

На прошлой неделе Ингвар Степанян рассказал о новых фичах девятой версии V8 — "V8 release v9.0".

В регулярных выражениях появилась поддержка флага /d, благодаря которому в результате выполнения регулярки (match object) появляется свойство indicies с позициями текущих скобочных групп (capturing group).

На порядки ускорен доступ к полям родительского объекта с помощью super.

Последовательность токенов for ( async of теперь больше не парсится.

В WebAssembly появилась экспериментальная поддержка инлайна враппера JS-to-Wasm для более эффективного преобразования параметров функций при их передаче из JS в Wasm. Эта фича будет особенно полезна в тех случаях, когда вызов Wasm-функции находится на горячем участке JavaScript-кода.

На данный момент V8 v9.0 находится в бете. Стабильная версия выйдет вместе с Chrome 90.

#v8 #release

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

Джаред Уайт рассказал о своей боли при работе с фронтенд-библиотеками и инструментами — "The Shocking Immaturity of JavaScript".

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

Решение проблемы — быть честнее со своими пользователями. Если библиотека находится в экспериментальном режиме, надо об этом рассказать в readme или добавить alpha к номеру версии. Если у инструмента или библиотеки есть ограничения, надо об этом тоже написать и в самом лучшем случае посоветовать подходящие альтернативы.

Не все проекты страдают от подобных проблем. Автор советует брать пример с LitElement, PostCSS, Shoelace и Webpack.

#musings #js #opensource

https://dev.to/jaredcwhite/the-shocking-immaturity-of-javanoscript-c70

Google в сотрудничестве с другими вендорами и партнёрами создали инициативу Compat2021

В рамках неё будет проведена работа по улучшению совместимости 5 критических для разработчиков CSS фич:
- Flexbox
- Grid
- position: sticky
- aspect-ratio
- transforms

Эти фичи выбраны на основе опросов разработчиков, статистики с HTTP Archive, анализа багов Chromium, Gecko и WebKit, результатов тестов Web Platform tests и самых популярных запросов Can I Use.

https://web.dev/compat2021/

Сегодня вышла новая версия Firefox. Крис Миллс рассказал о всех новинках релиза — "In March, we see Firefox 87".

Из экспериментального статуса вышла поддержка события beforeinput и метода getTargetRanges() для гибкого управления поведением при редактировании текста. С их помощью можно эргономично предотвратить редактирование любой части текста, сделать автоматическую замену вводимых нецензурных слов звёздочками и т.п.

Дефолтное значение Referrer-Policy было заменено на strict-origin-when-cross-origin. Это означает, что по умолчанию браузер не будет включать путь и GET-параметры в Referer.

В DevTools появилась поддержка prefers-color-scheme для эмуляции текущей выбранной темы операционной системы. В инспекторе страницы теперь можно удобно устанавливать псевдокласс :target на выбранном DOM-узле.

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

Отключена поддержка Backspace для навигации по истории, чтобы предотвратить случайные переходы при заполнении форм. Для её включения (не делайте этого) нужно поменять опцию browser.backspace_action в about:config.

В версии для macOS была добавлена поддержка скринридера VoiceOver.

#firefox #release

https://hacks.mozilla.org/2021/03/in-march-we-see-firefox-87/

Джек Арчибальд начал писать серию статей про производительность сайтов команд Формулы-1 — "Who has the fastest F1 website in 2021? Part 1".

В первой части он рассказывает про сайт команды Альфа Таури. На медленном соединении и слабом устройстве страница загружается больше минуты. Одна из основных проблем связана с тем, что рендеринг блокируется CSS, который используется для трекинга используемых шрифтов. Также на сайте есть предзагрузка изображений, которые используются в карусели в верху страницы. Изображения загружаются с большим приоритетом и занимают канал, который мог бы быть использован для загрузки критических ресурсов. Также на сайте есть неоптимизированные изображения, на которых можно было бы сэкономить больше 200kb. Джек попробовал оптимизировать сайт — время его полной загрузки снизилось до 7 секунд.

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

#performance

https://jakearchibald.com/2021/f1-perf-part-1/

Как оказалось в статье про CSS Nesting есть много неточностей. Роман Дворнов рассказал, как на самом деле обстоят дела с этой спецификацией в последних постах своего канала https://news.1rj.ru/str/gorshochekvarit Рекомендую заглянуть и подписаться на его канал.

Никита Прокопов из JetBrains написал статью про внутреннее устройство эмоджи — "Emoji under the hood".

В самом простом случае эмоджи — это одна кодовая позиция (то есть символ) из Unicode-таблицы. Сами изображения эмоджи находятся в шрифтах операционной системы: Apple Color Emoji (macOS/iOS), Segoe UI Emoji (Windows), Noto Color Emoji (Android). Приложения и сайты могут поставлять свой уникальный набор глифов эмоджи.

Большой набор эмоджи создаётся с помощью комбинации нескольких кодовых позиций Unicode — кластера графем. Например, два эмоджи можно объединить в один с помощью кодовой позиции U+200D (ZERO-WIDTH JOINER). Если эмоджи представляют людей, им можно задать оттенок кожи с помощью специальных модификаторов U+1F3FB..U+1F3FF и т.п.

Очень интересная статья. Рекомендую почитать всем.

#programming

https://tonsky.me/blog/emoji/

Швета Пандитрао и Мустафа Эмре-Асер из команды разработки Chrome рассказали о грядущем использовании HTTPS в качестве дефолтного протокола для навигации по интернету — "A safer default for navigation: HTTPS".

На сегодняшний день HTTPS использует подавляющее число сайтов. Поэтому начиная с Chrome 90 сайты по умолчанию будут открываться по HTTPS при вводе их адреса без указания протокола. Это позволит немного сократить время на установку HTTPS-соединения.

При переходе на сайт без поддержки HTTPS Chrome будет откатываться на использование HTTP. То есть если ваш сайт работает по HTTP, в новых версиях Chrome он будет загружаться немного медленнее из-за первичной попытки установки HTTPS-соединения.

#chrome #performance

https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html

Джейк Арчибальд написал вторую часть из серии статей про оптимизацию производительности сайтов команд Формулы-1 — "Who has the fastest F1 website in 2021? Part 2".

Во второй части Джейк исследует производительность сайта Alfa Romeo. На сайте подключается скрипт, который скрывает экран загрузки. Он загружается с очень низким приоритетом, из-за чего экран загрузки отображается очень долго. Проблема заключается в том, что скрипт подключается внизу страницы с атрибутом defer. Поэтому браузер сначала начинает загружать изображения и другие ресурсы, а затем сам скрипт. Проблема была решена переносом скрипта в <head>.

Ещё была проблема с основным изображением сайта, которое отображалось после загрузки JS-бандла. Как оказалось, разработчики использовали полифил для создания адаптивных изображений. Этот полифил был заменён на <picture>, так как он поддерживается во всех актуальных браузерах.

После всех исправлений время загрузки сайта снизилось с 20 секунд до 3 секунд.

#performance

https://jakearchibald.com/2021/f1-perf-part-2/

Марк Ноттингем — участвует в разработке протоколов HTTP — написал статью о том, как читать RFC — "How to Read an RFC".

Любой RFC-документ — архивный документ. Это означает, что при исправлении ошибок и опечаток должен быть выпущен новый RFC под новым номером, а предыдущий RFC должен быть объявлен устаревшим. Для проверки статуса любого RFC-документа Марк советует использовать сайт tools.ietf.org. RFC-документы очень часто подробно описывают поведение протоколов. Поэтому попытка прочитать спецификацию "между строк" может привести к неправильной имплементации протокола.

Полезная статья. В первую очередь рекомендую почитать всем, кто периодически заглядывает в RFC.

#spec

https://www.mnot.net/blog/2018/07/31/read_rfc