Тим Кадлек опубликовал пост с анализом производительности современных js-фреймворков — "The Cost of Javanoscript Frameworks".

Для анализа были использованы данные HTTP Archive: ~4,3 миллиона традиционных сайтов и ~5,5 миллионов мобильных. Оценивался объём js-файлов и время исполнения кода, использующего React, Angular, Vue.js и jQuery (добавлен for fun). По объёму кода на последнем месте для 90-го перцентиля оказались React (~2,2Mb) и Angular (~3,3Mb). По времени исполнении кода ситуация похоже, но для 90-го перцентиля на последнем месте оказался React (7,4 секунды), Angular (4,2 секунды). Для мобильных сайтов время выполнения кода для React вырастает более чем в три раза (~25 секунд), для Angular — примерно в полтора раза (~12 секунд).

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

#peformance #jsframeworks

https://timkadlec.com/remembers/2020-04-21-the-cost-of-javanoscript-frameworks/

Джастин Микауд в блоге WebKit написал статью про ускорение операции удаления свойства объекта в JavaScriptCore — "A Tour of Inline Caching with Delete".

Самая распространённая рекомендация для написания быстрого JS-кода — не использовать оператор delete. Как пример, в JavaScriptCore delete приводил к деоптимизации, из-за того что при удалении свойства движок использовал внутреннее представление js-объекта, которое не использует информацию об уже созданных ранее объектах. Для исправления этой проблемы потребовалось адаптировать механизмы, которые используются для кеширования общих частей объектов (Structure и Transitions). Исправление этой части сделало возможным генерацию инлайн-кэша (inline cache) на уровне JIT при удалении свойств объекта.

Инлайн-кэш — это техника оптимизации, использующаяся для ускорения операций работы с объектами, суть которой состоит в модификации генерируемого кода на основе результатов его предыдущего выполнения (интересный факт, эта оптимизация впервые появилась в Smalltalk). Информация, собранная при генерации инлайн-кэша, используется оптимизирующим компилятором. После всех исправлений в JavaScriptCore компилятор может производить дополнительные оптимизации оператора delete, например, полностью его удалять из генерируемого машинного кода, если он не влияет на работу программы.

Довольно хардкорная и интересная статья. Must read, если интересуетесь тем, как работают js-движки под капотом.

#performance #js #internals #webkit

https://webkit.org/blog/10298/inline-caching-delete/

Дмитрий Малышев из команды Firefox написал пост-апдейт про текущий статус разработки WebGPU — нового API для работы с видеокартами — "A Taste of WebGPU in Firefox".

Возможности WebGL не позволяют утилизировать весь потенциал современных видеокарт. Решить эту проблему призвано новое WebGPU API, над которым работают инженеры всех основных браузеров.

WebGPU предоставляет собой абстракцию над графическими API (DirectX12, Vulkan, Metal), изменяя подход к написанию приложений, которые используют вычислительные ресурсы видеокарт. Его основное отличие от WebGL — предоставление разработчикам большего количества рычагов для планирования и управления вычислениями. Например, благодаря ему можно распараллелить ресурсоёмкие задачи в web-воркерах, эффективно задействуя многоядерные процессоры. Или переиспользовать пакеты команд рендеринга, что открывает возможность портирования игр с открытым миром на web-платформу.

На данный момент рабочая группа WebGPU решила большую часть архитектурных проблем. Окончание основных работ над спецификацией и её имплементацией в браузерах планируется на конец 2020 года.

#webgl #webgpu #future

https://hacks.mozilla.org/2020/04/experimental-webgpu-in-firefox/

Гарри Робертс поделился своими мыслями по поводу влияния Brotli на производительность сайтов — "Real-World Effectiveness of Brotli".

Brotli — это алгоритм сжатия, который был представлен Google в 2013 году. На данный момент он поддерживается во всех актуальных браузерах. Использование Brotli вместо Gzip позволяет уменьшить объём передаваемых ресурсов до ~30%.

Внедрение Brotli иногда может быть гораздо сложнее, чем включение опции в панели CDN. Гарри провёл эксперимент, чтобы понять, стоит ли вкладывать в этом случае много сил для его поддержки, или можно обойтись обычным Gzip. Как оказалось, уменьшение объёма ресурсов на 30% не гарантирует, что на 30% улучшатся другие метрики. При сравнении работы разных сайтов переход с Gzip на Brotli не дал большого прироста производительности: общий объём передаваемых ресурсов снизился на 5.8%, а метрика First contentful paint (FCP) улучшилась всего лишь на 3.5%.

В конце статьи Гарри подводит итог. Если у вас есть возможность включить Brotli, этим стоит воспользоваться. Если же внедрение Brotli влечёт за собой недели разработки, то имеет смысл продолжать использовать Gzip.

#compression #performance #brotli

https://csswizardry.com/2020/04/real-world-effectiveness-of-brotli/

Прочитал пост Видита Бхаргавы про проблемы тёмных тем на OLED дисплеях — "Designing a Dark Theme for OLED iPhones".

В темах, которые используют настоящий чёрный цвет (#000), возникает две проблемы при отображении на OLED-дисплеях: смазывание изображения и эффект халяции.

Изображение смазывается из-за того, что чёрные пиксели в OLED-дисплеях по сути отключены. При их включении проходит небольшой промежуток времени, что при движении контента приводит к смазыванию изображения. Для того, чтобы от него избавиться, нужно настоящий чёрный цвет заменить на почти чёрный серый цвет (#050505). Таким образом пиксели не будут выключаться и эффекта смазывания не будет. Такой подход вызывает немного большее потребление энергии, но эти затраты практически неотличимы от энергозатрат при отображении чёрного цвета.

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

Хорошая статья. Если на вашем сайте (или в приложении) есть чёрная тема, то статью стоит почитать.

#mobile #a11y #ux

https://medium.com/lookup-design/designing-a-dark-theme-for-oled-iphones-e13cdfea7ffe

25 апреля npm немного поштормило. Ошибка в пакете is-promise, привела к поломке трёх миллионов зависимых проектов. Форбс Линдсей — автор библиотеки — написал постмортем.

После добавления поддержки ESM новый файл index.mjs не был добавлен в секцию files в package.json. Также в секции exports идентификатор модуля был без префикса ./. Из-за опубликованного кода перестал работать require вида require('is-promise/index'), require('is-promise/index.js'), require('is-promise/package.json').

С момента публикации сломанной библиотеки до её полного фикса прошло четыре часа. Для предотвращения проблем в будущем был удалён .npmignore и добавлен прогон тестов для Node.js 12 и 14, также были добавлены тесты, использующие npm pack для проверки публикуемого API и настроена публикация пакетов из CI. Разработчики Node.js в свою очередь обновили документацию, уточнив, что package.exports должен явно включать в себя все необходимые точки входа.

#npm #postmortem #esm #nodejs

https://medium.com/@forbeslindesay/is-promise-post-mortem-cab807f18dcc

В последней подборке новостей Web Platform News увидел небольшой пост про проблемы ленивой загрузки iframe — "The <iframe loading="lazy"> attribute is not ready".

В августе 2019 в Chrome появилась поддержка атрибута loading для ленивой загрузки изображений и iframe'ов. Атрибут loading для изображений уже стандартизирован, но loading для iframe остаётся экспериментальной фичей. В статье “Native lazy-loading for the web” команда разработки Chrome не акцентировала на этом внимание (сейчас статью исправили), поэтому эта фича стала появляться на production-сайтах.

На данный момент <iframe loading="lazy"> работает только в Chromium. При этом в текущей реализации есть известные проблемы, исправление которых может поломать сайты, которые уже начали использовать iframe loading Так как разработчики стандартов руководствуются принципом "don't break the web", есть риск, что эти баги будут увековечены в окончательном стандарте. Поэтому если вы уже начали использовать loading для iframe, от него стоит временно отказаться.

#html #lazy #chrome #problem

https://webplatform.news/issues/2020-04-27

команда chrome в своих маркетинговых статьях регулярно «забывает» упомянуть о том, что их экспериментальные фичи никем не одобрялись

https://news.1rj.ru/str/defront/491

многие привыкли называть safari ie за т.н. медлительность в принятии фич, между тем — это единственное, что спасает от падения в бездну монополии гугла

https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-577839892
сама статья гугла, продвигающая нестандартный adoptedStylesheets

в тот раз пронесло, если же в этот раз им удастся навязать своё мнение, взяв пользователей в заложники, то это будет окончательной установкой монополии в вебе в самых худших её проявлениях

это недопустимо.

В постмортеме инцидента с is-promise одна из проблем была в конфиге, в который не был добавлен новый файл. Это случилось из-за того, что автора библиотеки запутало наличие файла .npmignore. Когда писал пост про постмортем, нашёл статью Джефа Дики про вред .npmignore — "For the love of god, don’t use .npmignore".

В npm есть два механизма для исключения попадания ненужных файлов в пакет: файл .npmignore (blacklist) и секция files в package.json (whitelist). По умолчанию npm игнорирует файлы, которые находятся в .gitignore, но при добавлении в проект конфига .npmignore .gitgnore перестаёт учитываться. Из-за этого нюанса у автора статьи утекли данные для аутентификации в S3, поэтому он рекомендует использовать только белый список файлов в package.json (явное лучше неявного). Но .npmignore может быть полезен, когда надо исключить раскиданные по проекту юнит-тесты __test__ / *.test.js и т.п.

К советам из статьи стоит прислушаться. Как минимум, можно начать с подозрением относиться к .npmignore.

#npm

https://medium.com/@jdxcode/for-the-love-of-god-dont-use-npmignore-f93c08909d8d

Вирендра Сингх опубликовал статью про анализ производительности CSS-анимаций — "Performance monitoring in CSS animations".

Анимации могут быть причиной притормаживающего интерфейса. Это происходит тогда, когда браузеру необходимо перевычислять стили (Recalculate Style), создавать слой с элементами (Layout), рендерить его (Paint) и совмещать с другими слоями (Composite Layers) на каждый кадр анимации. Распространённый трюк для снижения количества операций — вынос анимаций на GPU. Chrome делает это автоматически, если анимируются свойства transform, opacity, filter.

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

Статью стоит почитать, если хотите узнать немного больше про возможности Chrome Dev Tools.

#performance #css #chrome

https://medium.com/chegg/performance-monitoring-in-css-animations-f11a21d0054f

Нашёл в дизайн-доках Chromium статьи про создание форм авторизации: "Password Form Styles that Chromium Understands", "Create Amazing Password Forms".

Браузеры и менеджеры паролей помогают пользователям автоматически заполнять поля форм авторизации. Для того чтобы вся эта "магия" работала правильно, нужно использовать семантическую вёрстку и придерживаться определённых правил. Например, чтобы менеджеры паролей смогли подхватить отправленные данные, после успешного логина должен произойти переход на новую страницу или этот переход должен быть сэмулирован с помощью history.pushState или history.replaceState. Для ускорения заполнения формы, поля ввода пароля и логина нужно разметить атрибутами autocomplete="current-password" и autocomplete="username". Если у поля стоит атрибут autocomplete="new-password" браузер или менеджер паролей будут показывать интерфейс для создания пароля.

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

#html #ux

https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
https://www.chromium.org/developers/design-documents/create-amazing-password-forms

Команда разработчиков Chrome активно контрибьютит в инструменты js-экосистемы и фреймворки. Хуссейн Джирде написал статью про один из таких кейсов сотрудничества — "Improved Next.js and Gatsby page load performance with granular chunking".

В Next.js и Gatsby в бандл commons попадал код, который использовался более чем на 50% страниц. Такая настройка была не очень эффективна, так как общий код оставшихся 50% страниц не разделялся между чанками. Для решения этой проблемы была адаптирована стратегия, в которой с помощью SplitChunksPlugin:
— все модули больше 160kb выносятся в индивидуальные чанки;
— создаётся отдельный чанк frameworks с кодом, который используется на всех страницах ( react, react-dom и т.п.);
— создаётся столько общих чанков, сколько webpack посчитает нужным создать, но не более 25.

Такие настройки позволяют улучшить скорость загрузки и улучшить утилизацию кеша при переходе между страницами. При переходе на новую стратегию разделения чанков общий размер генерируемого js-кода на production-сайтах уменьшился в среднем на 20%.

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

#webpack #performance

https://web.dev/granular-chunking-nextjs/

Мне регулярно присылают предложения о размещении рекламы в канале. Но я буду продолжать считать (глупо наверное звучит), что Defront будет лучше, если он будет без рекламы.

Тем не менее канал существует в том числе благодаря вашей поддержке на патреоне. Хочу выразить благодарность моим патронам: Андрею, Артёму, bafonins, brqte, Роману, Сергею, Владу, Денису и Дмитрию. Ребята, большое вам спасибо! И ещё хочу поблагодарить всех за то, что читаете канал и рассказываете про него своим друзьям и коллегам.

Если вам нравится то, что я делаю, и хотите поддержать канал, то это можно сделать тут https://www.patreon.com/myshov.

#спасибо

Колин Эберхарт — участвует в разработке многих проектов — написал статью про использование D3 для визуализации очень больших объёмов данных — "Rendering One Million Datapoints with D3 and WebGL".

Колин разрабатывает D3FC (набор компонентов для создания интерактивных диаграмм поверх D3). Недавно туда была добавлена поддержка WebGL. В статье на примере визуализации данных из репозитория цифрового контента научных библиотек HathiTrust рассказывается, как использовать эти компоненты.

Датасет HathiTrust состоит из одного миллиона объектов и занимает 70Mb. Если его читать полностью перед отрисовкой, то пользователь некоторое время не будет видеть график. Гораздо лучше рендерить график по мере получения данных. Для этого можно использовать Streams API. При наведении курсора мыши на каждую точку желательно показывать описание. Но опять же из-за большого объёма данных будут тормоза, если использовать линейный поиск для получения нужной точки. Для оптимизации поиска в примере используется структура данных Quadtree (идёт из коробки с D3).

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

#d3 #dataviz #webgl

https://blog.scottlogic.com/2020/05/01/rendering-one-million-points-with-d3.html

Пару недель назад Брайан Ким представил сообществу новый фреймворк Crank.js — "Introducing Crank".

Crank.js был вдохновлён React. Он использует JSX для создания компонентов. Компоненты могут создаваться с помощью генераторов function * (), такой подход позволяет использовать нативные конструкции языка для работы с жизненным циклом компонента. Также благодаря тому, что компоненты могут быть асинхронными, из коробки становятся доступны возможности, которые даёт Suspense в React.

Потыкал его час. Работа с асинхронными запросами в компонентах выглядит органично. Для работы с событиями Crank использует интерфейс EventTarget, который используется в DOM. Работа с событиями императивна, в принципе нормально, но после React выглядит непривычно.

Брайан сделал очень большой упор на работу с нативными возможностями платформы. Один из пунктов его критики React, как раз заключается в том, что React старается переизобрести рантайм для UI, когда браузер уже им и является. Дэн Абрамов на Reddit написал пост с объяснением, почему React использует такой подход.

Пока рано говорить о судьбе Crank.js, но тем не менее это очень интересный эксперимент, отголоски которого мы, возможно, увидим в других фреймворках/библиотеках.

#jsframeworks #announcement

https://bit.ly/3deCWYj (пост Дэна)
https://crank.js.org/blog/introducing-crank

Стефан Джудис написал небольшую статью про использование альтернативного текста с псевдоэлементами — "The CSS "content" property accepts alternative text".

Псевдоэлементы before и after часто используются для стилизации элементов на странице с помощью свойства content. Но content может негативно влиять на доступность, так как он озвучивается скринридерами. Для решения этой проблемы можно задавать альтернативный текст прямо в CSS.

/* css */
.new-item::before {
  content: "★" / '';
}

/* html */
<a href="new-things">go to new things</a>

В примере выше альтернативный текст для символа звезды пустая строка. Без него скринридеры озвучили бы html как "black star go to new things".

Поддержка этой фичи есть только в Chromium-based браузерах. В Safari есть поддержка экспериментального и устаревшего свойства alt. Только в Firefox на данный момент невозможно задать альтернативный текст для content.

#css #a11y

https://www.stefanjudis.com/today-i-learned/css-content-accepts-alternative-text/

Вчера вышла новая версия Firefox. Крис Миллс и Гарольд Киршнер рассказали про новинки релиза — "Firefox 76: Audio worklets and other tricks".

С этой версии доступны аудио ворклеты (Audio worklets) — новое API для обработки аудио. С помощью аудио ворклетов игры и VR-приложения, работающие в web'е, могут накладывать в реальном времени эффекты на звук, например, реверберацию, эхо и т.п. без ущерба для производительности. Аудио ворклеты работают вне основного потока браузера. При комбинации аудио ворклетов с WebAssembly появляются возможности для создания real-time гитарных процессоров и полноценных приложений для синтеза звука. Также благодаря этой фиче пользователям Firefox больше не надо скачивать дополнительные аддоны для работы Zoom.

В элементе <input> исправлена ошибка при использовании атрибутов min и max, когда минимальное значение было больше максимального для элементов с типами time, date, month, week.

Есть немного изменений в JavaScript Intl API. Теперь можно использовать опции numberingSystem и calendar в конструкторах Intl.NumberFormat, Intl.DateTimeFormat, Intl.RelativeTimeFormat.

Конструктор IntersectionObserver в качестве опции root можно передавать document. В таком случае границами для отслеживания пересечений будет вcё окно.

В CSS добавлены константы для системных цветов из CSS Color Module Level 4. С помощью них можно легче адаптировать страницу или web-приложение под цвета операционной системы.

Было сделано много улучшений в инструментах разработчика. В отладчике можно скрывать (blackbox files) целые директории кода. При копировании стека вызовов копируются полные url до файлов скриптов, это полезно при создании отчётов об ошибках. Теперь можно автоматически изменять размер колонок панели "Network" при двойном клике на разделителе. Был улучшен инспектор веб сокетов. В Firefox Developer Edition в DOM-инспекторе доступна вкладка "Compatibility", которая показывает в каких браузерах доступны CSS-свойства, используемые на странице.

#firefox #release

https://hacks.mozilla.org/2020/05/firefox-76-audio-worklets-and-other-tricks/

Денис Хрипков написал статью про оптимизацию генерируемого кода css-модулей — "Как уменьшить размер бандла — стратегия однобуквенных классов в css-modules".

По умолчанию в css-модулях генерируются имена классов, которые плохо сжимаются gzip/brotli. В статье предлагается альтернативный способ формирования имён. Каждый класс файле заменяется одной буквой, а после неё подставляется хэш от полного пути css-файла. Получаются такие имена:

/* first.css */
.a_k3bvEft8 { }
.b_k3bvEft8 { }
[...]
/* second.css */
.a_oRzvA1Gb { }
.b_oRzvA1Gb { }
[...]

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

Советую заглянуть в статью, если используете css-модули в своём проекте.

#css #compression #performance

https://habr.com/ru/post/499162/
https://dev.to/denisx/reduce-bundle-size-via-one-letter-css-classname-hash-strategy-10g6 (перевод на английский)

Спецификация ECMAScript 2020 будет официально выпущена в июне. Набор новых фич и улучшений утверждён и уже не будет меняться. Среди нововведений можно найти улучшенный раздел про порядок перечисления свойств объекта с помощью цикла for-in, над которым работал Кевин Гиббонс

Исторически спецификация практически не накладывала ограничения на порядок перечисления свойств при использовании for-in, так как не удавалось достичь консенсуса по этой теме. Одна из причин разногласий была в том, что у каждого движка есть свои особенности реализации. Большие изменения в этой части спецификации означали бы большой объём работы для разработчиков всех движков. Тем не менее есть негласные правила при работе c for-in, которым должны следовать разработчики браузеров, чтобы не сломать web. Эти правила и были закреплены в ES2020.

Теперь спецификация гарантирует, что при использовании for-in сначала будут идти свойства, ключи которых обычные числа (в порядке возрастания ключа). Затем свойства, ключи которых строки (в хронологическом порядке их добавления). А затем свойства, созданные с помощью Symbol (в хронологическом порядке их добавления). Это поведение не гарантируется для случаев, когда во время перечисления свойств изменяется прототип, удаляются или добавляются новые свойства в объект или его прототип, изменяется прототип или когда у свойства изменяется параметр enumerable. Также спецификация гарантирует порядок только для обычных объектов, то есть порядок не гарантируется для Proxy, Array, arguments и т.п.

#js #specification #es2020 #history

https://github.com/tc39/proposal-for-in-order
https://tc39.es/ecma262/#sec-enumerate-object-properties
https://tc39.es/ecma262/#sec-ordinaryownpropertykeys

Сегодня вышло мажорное обновление ESLint 7.0.0. Каких-то глобальных изменений нет, но есть много ломающих изменений, которые накопились со времени разработки шестой версии.

Основные изменения:

ЕSLint больше не будет работать на Node.js 8, так как эта версия устарела.

Изменены правила, поставляющиеся с ядром линтера: в eslint:recommended были добавлены правила no-dupe-else-if, no-import-assign и no-setter-return, правила, связанные с Node.js, объявлены устаревшими и перенесены в плагин eslint-plugin-node.

Проверка файлов по умолчанию будет подхватывать опцию overrides[].files без необходимости явного перечисления расширений с помощью команды --ext.

Начиная с этой версии, пути до файлов, передаваемые с помощью --config и --ignore-path, будут резолвиться относительно рабочей директории.

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

Изменился набор файлов, который игнорируется по умолчанию. В новой версии без дополнительных настроек будут игнорироваться все директории node_modules, даже если они находятся в поддиректориях. Больше не будут игнорироваться bower_components/* и .eslintrc.js.

В служебные комментарии теперь можно добавлять описание после --

// eslint-disable-next-line a-rule -- тут легаси

#tool #announcement

https://eslint.org/blog/2020/05/eslint-v7.0.0-released

Дилан Ванн написал статью про подход к миграции большого проекта на TypeScript — "How to Incrementally Migrate 100k Lines of Code to TypeScript".

Основная идея статьи — использование снапшотов ошибок компиляции для помощи в миграции. У всех js-файлов расширение меняется на ts, запускается компиляция. Все ошибки компиляции собираются в объект, с которого снимается снапшот с помощью toMatchSnapshot и записывается в файл. Этот файл попадает в систему контроля версий и становится отправной точкой для улучшения типизации проекта — каждый новый пулл реквест не должен увеличивать количество ошибок в этом файле.

Подобный подход можно применять не только с TypeScript, но и c Flow, ESLint.

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

#typenoscript #migration

https://dylanvann.com/incrementally-migrating-to-typenoscript/