Нолан Лоусон предлагает следить не только за размерами бандла, но и за другими параметрами, влияющими на опыт работы с сайтом — "JavaScript performance beyond bundle size".

Нолан предлагает обращать внимание не только на размер бандла, но и на стоимость работы кода в рантайме (время парсинга, компиляции и исполнения), на энергоэффективность и объём потребляемой памяти.

Профилировка кода может помочь найти проблемные библиотеки, которые забивают главный поток. Для удобного анализа результата работы профилировщика можно использовать плагин для Webpack — mark-loader. С помощью метода performance.measureUserAgentSpecificMemory, который будет включён по умолчанию в Chrome 89, можно получить информацию о потребляемой памяти с учётом iframe'ов. Для понимания того, насколько сильно сайт съедает батарею, можно использовать профилировщик или Performance Monitor.

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

#performance

https://nolanlawson.com/2021/02/23/javascript-performance-beyond-bundle-size/

Уил Бойд рассказал про малоизвестные особенности использования псевдоэлементов ::before и ::after — "Diving into the ::before and ::after Pseudo-Elements".

Статья начинается с самых основ использования ::before и ::after. Затем в ней рассматриваются более изощрённые сценарии использования: создание декоративных линий и декоративной ленты, работа с кавычками ( content: open-quote; и content: close-quote; ), использование изображений в content, установка их альтернативного текста ( content: url(logo.png) / 'logo of the site'; ) и т.п.

Хорошая статья. Рекомендую заглянуть, если хотите узнать больше про ::before и ::after.

#css

https://codersblock.com/blog/diving-into-the-before-and-after-pseudo-elements/

Алекс Руденко из команды разработки Chrome DevTools написал статью про добавление поддержки редактирования стилей, создаваемых с помощью CSS-in-JS-библиотек — "CSS-in-JS support in DevTools".

Возможность редактирования CSS-in-JS стилей появилась в Chrome 85. Для поддержки редактирования стили должны быть представлены как статический текст. В случае с CSS-in-JS статического текста нет, так как такие стили размещаются в памяти во внутренней структуре данных CSSOM. Для добавления возможности редактирования их стали преобразовывать в текст. Для синхронизации мутируемых стилей был добавлен новый механизм, который оповещает бэкенд DevTools при изменении стилей с помощью CSSOM API.

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

#internals #chrome #cssinjs

https://developers.google.com/web/updates/2021/02/css-in-js

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

— Опыт Facebook в уменьшении времени исправления багов
— Как разрабатывается Sublime Text
— Надёжное тестирование производительности
— 10 лет работы над D3
— Почему в Amazon отходят от использования термина "технический долг"
— Оптимальные настройки качества сжатия для WebP и AVIF
— Интервью с Райаном Далом
— Не используйте React.Fragment в переиспользуемых компонентах
— Способы оптимизации загрузки JavaScript-приложений и сайтов
— Мысли о современной web-разработке

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

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

https://www.patreon.com/myshov

Сегодня вышел Chrome 89. Пит Лепаж и Джеселин Ин рассказали про новинки релиза.

Добавлена поддержка top level await для JavaScript-модулей.

Стали доступны по умолчанию новые API для работы с железом — WebHID, WebNFC и Web Serial. С их помощью web-приложения могут взаимодействовать с устройствами пользователя без установки драйверов или каких-либо дополнительных программ.

PWA-приложения можно установить только в том, случае когда они поддерживают offline-режим. Ранее была возможность обойти это требование. Начиная с Chrome 89 этот обходной путь будет триггерить сообщение с предупреждением в консоль, а в Chrome 93 будет заблокирован.

Добавлена поддержка Web Share API и Web Share Target API для удобной передачи любых данных из одного web-приложения в другое.

Очень много изменений в инструментах разработчика. Lighthouse был обновлён до седьмой версии. Улучшена работа с куками. Можно ставить точки останова на исключения, вызванные нарушениями Trusted Type. Добавлена поддержка эмуляции устройств со складным экраном и многое другое.

#chrome #release

https://developer.chrome.com/blog/new-in-chrome-89/
https://developers.google.com/web/updates/2021/01/devtools

В Chrome 89 была добавлена поддержка import maps. Гай Бедфорд рассказал, какие преимущества несёт эта фича с точки зрения производительности — "Import Maps Release & Module CDN Launch".

Благодаря поддержке import maps можно использовать bare specifiers в импортах. То есть не import something from './path/to/something.js', а import something from 'something'. По сути это есть не что иное, как соответствие спецификаторов и соответствующих им путей до модулей:

<script type="importmap">
{
  "imports": {
    "something": "./path/to/something.js"
  }
}
</script>

Благодаря import maps можно обеспечить кэширование кусков JS-приложения без каскадной инвалидации кода при обновлении нижележащих зависимостей. То есть они открывают возможность эффективного кэширования при инкрементальном обновлении web-приложений.

На данный момент поддержка import maps есть только в Chrome 89. Для других браузеров доступен полифилл.

#js #esm #performance

https://jspm.org/import-map-cdn

В блоге CSSSR была опубликована статья про судьбу первых web-браузеров — "История фронтенда: Браузер, который умел всё".

В статье рассказывается про WorldWideWeb — самый первый браузер, над которым работал Тим Бернерс-Ли и который позднее был переименован в Nexus. Рассказывается про систему организации данных для Macintosh — некий прообраз современного веба, но без поддержки сети. С помощью этой системы была сделана знаменитая игра Myst. Ещё в 1991 году вышла первая версия ViolaWWW — браузер, который поддерживал добавление на страницу апплетов-приложений на языке Viola.

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

#web #history

https://blog.csssr.com/ru/article/frontend-history-the-browser-that-could-do-everything/
https://www.youtube.com/watch?v=7nrDctGYOIk

Юна Кравец рассказала о недавних изменениях в Chrome, которые позволяют вынести обработку анимаций на GPU — "Updates in hardware-accelerated animation capabilities".

Chrome уже очень давно обрабатывает некоторые CSS-трансформации на GPU. В Chrome 89 на GPU также стали обрабатываться SVG-анимации. С точки зрения разработчиков, делать ничего не нужно, GPU подхватывает такие анимации автоматически. Также теперь с помощью GPU обрабатываются трансформации, использующие в качестве единиц измерения проценты. В будущих релизах Chrome будет добавлено GPU-ускорение анимаций CSS-свойств background-color и clip-path.

#chrome #css #performance

https://developer.chrome.com/blog/hardware-accelerated-animations/

Амит Шин рассказал о том, как получить позицию курсора мыши на чистом CSS — "How to Map Mouse Position in CSS".

Идея заключается в создании сетки элементов, в каждой ячейке которой задаются кастомные свойства с координатами:

.cell:nth-child(42):hover ~ .content {
  --positionX: 1;
  --positionY: 3;
}

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

#css #trick

https://css-tricks.com/how-to-map-mouse-position-in-css/

Недавно вышло новое официальное руководство по TypeScript, над которым шла работа с 2018 года. Орта Терокс рассказал обо всех основных изменениях — "Announcing the New TypeScript Handbook".

Новая версия руководства была полностью переработана. Теперь это не набор статей, а полноценная книга, которую можно рекомендовать всем, кто только начинает изучать TypeScript. В руководстве нет разделов, связанных с JavaScript, поэтому для совсем начинающих оно не подходит. Чтобы не перегружать читателей информацией, все редкие кейсы использования TypeScript были перемещены в справочник. Руководство доступно онлайн на основном сайте, а также его можно скачать в форматах pdf/ePub для чтения в оффлайне.

#typescript #book

https://devblogs.microsoft.com/typescript/announcing-the-new-typescript-handbook/

Ромэйн Ленз написал статью о том, почему не нужно использовать Express.js — "Why you should drop ExpressJS in 2021".

Ромэйн пишет о том, что Express.js тормозит в развитии. Пятая версия находится в альфе уже шесть лет. Так как JavaScript развивается и разработчики начинают использовать современные фичи, это приводит к проблемам при использовании Express.js. Например, при использовании async/await в мидлварах появляются утечки памяти. Начиная с версии Node.js 15, такой код приводит к крэшам программы.

Вместо Express.js Ромэйн предлагает использовать Fastify или AdonisJS.

#nodejs

https://dev.to/romainlanz/why-you-should-drop-expressjs-in-2021-711

Бэн Шмидт — профессор университета Нью-Йорка — поделился своими мыслями о том, почему JavaScript может захватить Data Science в ближайшем десятилетии — "Javascript and the next decade of data programming".

Бэн пишет о том, что всё больше интерфейсов для интерактивной работы с данными строится поверх web-технологий. Основная причина — скорость. Если традиционным инструментам для визуализации данных нужно несколько минут для обработки данных, то для JavaScript-кода нужно всего лишь несколько секунд. Ситуация в будущем станет ещё лучше, когда во всех браузерах появится поддержка спецификации WebGPU, благодаря которой можно будет вынести обработку данных на GPU. Более того с некоторыми ограничениями можно задействовать GPU для обработки данных уже сегодня с помощью WebGL. Ещё автор статья возлагает большие надежды на WebAssembly, благодаря которому в будущем могут появиться удобные инструменты для работы с данными.

#js #datascience #musings

http://benschmidt.org/post/2020-01-15/2020-01-15-webgpu/

Иан Бин дал несколько рекомендаций по использованию шрифтов — "System fonts don’t have to be ugly".

Во всех операционных системах есть предустановленный набор очень качественных шрифтов. Они могут составить хорошую конкуренцию модным web-шрифтам. Иан предлагает по умолчанию использовать системные шрифты (Georgia, Charter, Palantino, Hoefler, San Francisco, Helvetica, Segoe UI, Arial и т.п.) для оформления текстов на сайте, а web-шрифты оставить только для редких случаев, когда системный шрифт не подходит. Благодаря такому подходу отпадает проблема оптимизации web-шрифтов, и в целом сайт будет загружаться быстрее.

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

#typography #performance

https://iainbean.com/posts/2021/system-fonts-dont-have-to-be-ugly/

Два года назад Зак Лезерман у себя в твиттере в качестве шутки предложил идею написать кому-нибудь статью, как сделать медленную HTML-страницу, которая бы была быстрой для Lighthouse. Барри Полларду удалось это сделать, о чём он рассказал в статье "Making the slowest 'fast' page".

Сделать медленную страницу, которая бы смогла заработать 100 баллов в Lighthouse, очень трудно. Барри пошёл другим путём — он сделал быструю страницу и "замедлил" её с помощью увеличения времени воспринимаемой производительности. Для этого он перекрасил текст сайта в белый цвет и, спустя 10 секунд, вернул его в нормальный вид.

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

#performance

https://www.tunetheweb.com/blog/making-the-slowest-fast-page/

Алон Кочба из Wix рассказал об опыте улучшения производительности сайтов, сделанных с помощью их конструктора — "How Wix improved website performance by evolving their infrastructure".

Несколько лет назад Wix-сайты представляли собой SPA-приложения, которые рендерились в браузере клиента. Это было основной причиной неудовлетворительной производительности. В прошлом году ребята добавили поддержку серверного рендеринга. Страницы сайтов теперь раздаются с помощью CDN и кэшируется на стороне браузера и сервера. Пользовательская информация больше не попадает на страницу, но подтягивается на стороне клиента. Также была добавлена поддержка HTTP/2 и brotli.

В статье нет информации о том, насколько улучшилась метрики Web Vitals, но в целом разработчики довольны проделанной работой.

#performance

https://web.dev/wix/

Алекс Котлярский из Facebook рассказал про историю развития React API — "React API evolution".

Прошло уже почти восемь лет с момента релиза первой публичной версии React. За этот период подход к написанию компонентов поменялся несколько раз. Сначала компоненты создавались с помощью React.createClass причём в версии 0.3.0 нужно было самостоятельно биндить методы, использующие this, с помощью React.autoBind. В 0.4.0 автобиндинг был включён по умолчанию. Затем официальным механизмом для создания компонентов стали ECMAScript классы и функциональные компоненты. По ходу дела разработчики стали использовать High Order Components (HOC) для композиции поведения компонентов. HOC не были идеальным решением для работы с поведением, поэтому в 2019 году ребята из команды React представили хуки.

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

#react #history

https://frantic.im/react-api-evolution

Майк Уэст в блоге Chromium написал статью про средства предотвращения неявных утечек данных между сайтами в пределах одного процесса браузера — "Mitigating Side-Channel Attacks".

Браузеры полагаются на концепцию origin для предотвращения явной утечки данных между сайтами. Но существуют атаки по сторонним каналам, которые могут обойти ограничения браузера и прочитать любые пользовательские данные любых сайтов. Например, с помощью атаки Spectre можно было читать данные сайтов-соседей, которые попадали в один браузерный процесс. Для этого небезопасный сайт example.com мог добавить на страницу ресурс другого сайта ( <img src="https://email.com/user_emails.json" /> ) и получить доступ к его содержимому через единое адресное пространство памяти процесса. Чтобы предотвратить Spectre, браузеры по умолчанию отключили небезопасные API и включают их лишь только для тех сайтов, которые можно изолировать между разными процессами (Site Isolation).

Для предотвращения атак подобного типа можно использовать другие методы, даже если браузер не поддерживает Site Isolation:

— Ограничение ответов со стороны сервера на основе анализа HTTP-заголовков Sec-Fetch-*,
— Ограничение возможности загружать ресурс как подресурс (то есть как в примере с img выше) с помощью cross-origin-resource-policy (CORP),
— Предотвращение загрузки документа в iframe'ах с помощью X-Frame-Options: SAMEORIGIN и CSP-политик,
— Ограничение доступа к window opener'а с помощью Cross-Origin-Opener-Policy (COOP),
— Предотвращение атак MIME-type confusion с помощью X-Content-Type-Options: nosniff и установки корректных заголовков Content-Type.

#security

https://blog.chromium.org/2021/03/mitigating-side-channel-attacks.html

Эмили Старк из команды 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-javascript-425d