Денис Хрипков написал статью про оптимизацию генерируемого кода 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/

Том МакРайт поделился мыслями про текущее состояние дел в современном вебе — "Second-guessing the modern web".

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

В статье нет призывов к уничтожению SPA-приложений, но есть призыв задуматься. В современном вебе при оптимизации используемых абстракций мы получаем в результате те преимущества, которые можно получить, просто не используя эти абстракции. Отсюда возникает вопрос. Действительно, ли есть ценность во всей сложности построения современных web-приложений? Универсального ответа нет и не может быть. У каждого проекта есть свой набор уникальных проблем — где-то больше подходит SPA-подход, а где-то достаточно обычного html и css.

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

#web #performance #musings

https://macwright.org/2020/05/10/spa-fatigue.html

Гюёнг Ким в блоге Igalia рассказал про новую систему межпроцессорного взаимодействия Chromium — "How Chromium Got its Mojo?".

Chromium использует мультипроцессорную архитектуру для безопасности и устойчивости к сбоям. Внутри него работают разные процессы: renderer process, browser process, GPU process, utility process и т.п. Для общения между процессами используется IPC (Inter-process Communication). Команда Chromium решила отказаться от IPC и разбить браузер на большое количество маленьких сервисов. Для этого был разработан Mojo.

Mojo — это фреймворк для взаимодействия между процессами внутри браузера. Он отвечает за доставку сообщений между процессами и позволяет интегрировать большое количество компонентов без необходимости их линковки, сокращая время сборки и упрощая работу с частями кода, написанными на C++, Java, JavaScript. На данный момент идёт активная работа над миграцией кода, использующего Chromium IPC, на Mojo.

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

#internals #chromium

https://blogs.igalia.com/gyuyoung/2020/05/11/how-chromium-got-its-mojo/

Сегодня вышла новая версия TypeScript 3.9. Дениэл Розенвассер рассказал про новинки релиза в статье "Announcing TypeScript 3.9".

В TypeScript 3.9 были исправлены проблемы с медленной компиляцией, которые были обнаружены в material-ui, styled-components и других библиотеках. Было слито шесть пулл-реквестов каждый из которых ускоряет компиляцию на 5-10%. Один из внутренних проектов Microsoft после перехода на версию 3.9 сократил время компиляции с 29 секунд до 10 секунд.

Была исправлена ошибка выведения типов при использовании Promise.all`и `Promise.race. Эта проблема проявляла себя при оборачивании в промис значения, которое могло быть null или undefined.

Добавлена поддержка служебного комментария // @ts-expect-error, который можно использовать в юнит-тестах для тестирования кейсов корректной обработки ошибок в JavaScript-коде.

Расширена проверка функций в условных выражениях. Теперь компилятор будет сообщать об ошибке, если в тернарном операторе находится функция, которая не вызвыается.

Релиз нового оператора awaited для рекурсивного разворачивания промисоподных типов был отложен из-за обнаруженных проблем.

Была улучшена интеграция с редакторами. В JavaScript-файлах теперь работает автоимпорт модулей в CommonJS-стиле: const fs = require("fs");. Средства для рефакторинга сохраняют все переносы строк как в оригинальном коде. Был добавлен quick-fix для вставки забытого return. Была исправлена проблема с Language Server, который не подхватывал tsconfig.json, который полностью состоял из ссылок на другие конфиги (Solution-style).

Есть ломающие изменения. Optional Chaining с Non-Null Assertions теперь парсится немного по-другому. Символы "}" и ">" больше нельзя использовать в строках внутри JSX. Была улучшена проверка типов для пересечений объектов с опциональными свойствами и общими несовместимыми свойствами и т.п.

#typenoscript #release #announcement

https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-3-9/

Через несколько минут начнеся конференция React Europe, которая в этом году бесплатная и пройдёт онлайн на YouTube.

https://www.youtube.com/watch?list=PLCC436JpVnK31LZG2cNINhlEQ1KTm39BR&v=41Ia291KIvI&feature=emb_noscript

Райан Дал — автор Node.js — два дня назад представил первую стабильную версию нового рантайма для JavaScript- и TypeScript-приложений — "Deno 1.0".

Deno — это переосмысление V8-рантайма с учётом ошибок, которые были допущены при дизайне Node.js. Очень большой упор был сделан на безопасность. При запуске любого кода надо явно указывать, что может использовать скрипт (сеть, файловую систему и т.п.) Отказ от EventEmitter в пользу промисов в корне решил проблему с back-pressure. Есть встроенная поддержка TypeScript.

Есть ограничения. Deno несовместим с Node.js из-за значительных отличий в API. Также он не использует CommonJS, работа с внешними модулями децентрализована. Для подключения модулей используется синтаксис ES2015 с указанием прямой ссылки на код, рантайм его скачает и закеширует. Также Deno уступает Node.js в скорости работы HTTP-сервера, но не драматически.

Компиляция и сборка TypeScript отнимает время при запуске приложения, значительно уступая в начальной скорости запуска кода в Node.js. Райан серьёзно рассматривает вариант замены тайпчекера от Microsoft на более производительную реализацию на Rust.

#release #announcement #deno

https://deno.land/v1

В начале июня выйдет седьмое издание "JavaScript: The Definitive Guide" (книга с носорогом). Дэвид Флэнаган вспоминает былое и рассказывает, какие фичи платформы больше не актуальны и описания которых не будет в книге — "JavaScript Features To Forget".

Не будет информации про arguments. В современном js вместо него используют ...args. У конкатенации строк раньше были проблемы с производительностью, поэтому появился паттерн, когда строки добавлялись в массив и затем объединялись с помощью .join(). С развитием движков и после добавления в стандарт шаблонных строк это больше не актуально. Не будет ничего про document.write(). Он активно использовался в эру pre-DOM для изменения страницы во время её парсинга. Ничего не будет про <frameset> и <frame>. Фреймы давно изжили себя, так они портят пользовательский опыт. Не будет в книге описания методов document.getElementById(), document.getElementsByName() и т.п. В современном вебе вместо них используют более гибкие document.querySelector() и document.querySelectorAll().

Формально новая версия Definitive Guide не будет больше "definitive". Седьмое издание будет рассказывать только про актуальные возможности платформы, для всего унаследованного добра остаётся шестое издание книги.

#js #history #book

https://davidflanagan.com/2020/05/12/javanoscript-to-forget.html

Айзек Шлутер опубликовал первую статью про изменения в следующей версии npm — "npm v7 Series - Introduction".

В первой статье Айзек делает обзор всех фич, которые будут доступны в седьмой версии. В ней будет улучшен процесс работы с пакетами. Будет добавлена поддержка воркспейсов и возможность переопределения пакетов. Будет упрощён вывод результата выполнения разных команд. Вывод npm audit в новой версии занимает гораздо меньше места, показывая только самую необходимую информацию. В кодовой базе был сделан большой рефакторинг, благодаря которому npm стал работать быстрее. Появится интеграция с yarn. Процесс установки пакетов будет учитывать yarn.lock. Yarn.lock также будет обновляться вместе с package-lock.json при добавлении в проект новых пакетов.

В следующих статьях про npm v7 будет более подробное описание работы всех новых фич.

#npm #announcement

https://blog.npmjs.org/post/617484925547986944/npm-v7-series-introduction

Максим Эзьер написал большое руководство по работе с WebGL — "WebGL guide".

В руководстве с азов объясняется создание интерактивной трёхмерной сцены без использования сторонних библиотек. Используется только чистый JS и WebGL. В самом начале есть раздел про математику, которая необходима для работы с графикой. Затем объясняется процесс создания простых двумерных и трёхмерных сцен с подробным объяснением примеров исходного кода. Есть пример текстурирования объектов и работы с источниками света. В конце статьи есть список наиболее распространённых ошибок. Про них полезно знать при отладке кода.

В общем, если хотели потыкать WebGL, рекомендую заглянуть в это руководство.

#webgl #tutorial

https://xem.github.io/articles/webgl-guide.html

Инженеры из Google пару недель назад представили инициативу, помогающую разработчикам создавать более производительные сайты — "Web Vitals".

Тема производительности веба очень большая. На ней можно построить карьеру, помогая другим с оптимизацией сайтов. Обычно такие специалисты или агентства, предоставляющие подобные услуги, стоят дорого. Для поддержки разработчиков, у которых нет ресурсов для полного погружения в тему производительности, Google представил новую инициативу Web Vitals. Web Vitals — это набор метрик и их показателей, которые помогают выявить проблемы производительности, ухудшающие пользовательский опыт.

Web Vitals включает в себя подмножество Core Web Vitals — набор метрик, на которые разработчики должны обращать внимание в первую очередь. Туда входят:
— Largest Contentful Paint (LCP) говорит о времени загрузки основного контента на странице. LCP считается хорошим, если он происходит в первые 2.5 секунд после начала загрузки.
— First Input Delay (FID) измеряет интерактивность. Для хорошего ux страницы должны обеспечить FID в пределах 100мс.
— Cumulative Layout Shift (CLS) измеряет визуальную стабильность. Для хорошего ux страницы должны обеспечить CLS в пределах 0.1.

В течение ближайших месяцев будут обновлены Lighthouse, Chrome DevTools, PageSpeed Insights, Search Console’s Speed Report, в них будут добавлены функции, помогающие в улучшении Core Web Vitals. Для понимания того, как обстоят дела с метриками сейчас, можно использовать библиотеку web-vitals или Web Vitals Chrome Extension.

#performance #announcement #google

https://web.dev/vitals/

В блоге v8 была опубликована четвёртая часть серии статей про структуру спецификации ECMAScript — "Understanding the ECMAScript spec, part 4".

Парсеры просматривают наперёд ограниченное число токенов (finite lookahead), чтобы понять, какую конструкцию языка представляет собой данный кусок текста программы. Иногда возникают ситуации, когда finite lookahead не хватает. Например, нельзя за ограниченное число токенов однозначно отличить список аргументов от выражения в скобках.

Для обработки подобных ситуаций в спеке используется покрывающая грамматика (cover grammar). Она вводит дополнительные символы, которые учитывают все возможные синтаксические конструкции и которые можно временно использовать как плейсхолдеры. Эти символы уточняются после парсинга проблемной части текста программы. Для списка аргументов и выражения в скобках в спеке используется символ CoverParenthesizedExpressionAndArrowParameterList (CPEAAPL).

Очень интересная статья. Рекомендую почитать, если хотите ещё лучше понимать спецификацию ECMAScript.

#js #specification #tutorial

https://v8.dev/blog/understanding-ecmanoscript-part-4#using-cpeaapl-in-productions

Вчера вышла новая версия Chrome. Пит Лепаж рассказал про все новинки релиза — "New in Chrome 83".

Из origin trial вышел Trusted Types API. Он позволяет избежать распространённых DOM-based XSS атак, блокируя прямой доступ к потенциально небезопасным частям web-платформы (innerHTML, изменение содержимого noscript, eval, setTimeout и т.п.) Trusted Types API можно включить с помощью заголовка CSP require-trusted-types-for 'noscript'.

Были обновлены встроенные html-контролы — унифицирован внешний вид, улучшена поддержка клавиатуры и тач-ввода. Над этой фичей работала команда Edge.

В рамках origin tirals доступны performance.measureMemory() — новое API для мониторинга потребления памяти страницей и Native File System API для упрощения работы с файлами в веб-приложениях.

Была добавлена поддержка изолированных окружений, которые гарантируют безопасность при использовании SharedArrayBuffer, performance.measureMemory(), JS Self-Profiling API.

В Chrome Dev Tools теперь можно эмулировать проблемы со зрением. Также можно эмулировать разные локали. При проблемах с Cross-Origin Embedder Policy на панели "Network" будет отображаться соответствующая отладочная информация. Перенесли пункт меню "Settings" в подменю "More tools".

#announcement #chrome #release

https://developers.google.com/web/updates/2020/05/nic83

Роберто Витилло опубликовал в своём блоге статью про TCP — "What every developer should know about TCP".

Есть распространённое ошибочное предположение, что при отправке данных с помощью TCP пропускная способность канала связи не зависит от времени задержки. В статье объясняется, почему это не так.

При установке соединения сетевой стек операционной системы ищет наиболее подходящее количество пакетов (congestion window), которое можно отправить за один round-trip и которое не зафлудит канал получателя. Время доставки такой порции данных определяется с помощью round-trip time (RTT). Теоретическая максимальная пропускная способность зависит от этих двух показателей: Bandwidth = WinSize / RTT. Именно по этой причине сервера стараются размещать ближе к своим пользователям.

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

#performance #net

https://robertovitillo.com/what-every-developer-should-know-about-tcp/

Флориан Раппл рассказал про текущее состояние микрофронтендов — "The State of Micro Frontends".

Микрофронтенды — это подход к организации приложения, когда команды в рамках одного продукта могут делать фичи, используя разные технологии, и релизить их независимо друг от друга. Микрофронтенды могут быть реализованы по-разному, поэтому существуют разные фреймворки для построения микрофронтендов, покрывающие специфические требования: qiankun, piral, mosaic, micromono и т.п.

Микрофронтенд — это не серебряная пуля, которая может решить все известные проблемы. Но в определённых случаях он может быть полезен. Такой подход для своих продуктов используют IKEA, Microsoft, SAP, Spotify и другие компании.

#architecture

https://blog.bitsrc.io/state-of-micro-frontends-9c0c604ed13a

В блоге Chromium была опубликована статья про исследования, которыми подкреплялись пороговые значения недавно анонсированных Web Vitals — "The Science Behind Web Vitals ".

Web Vitals состоит из трёх метрик — Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) и First Input Delay (FID). Пороговые значения для них были выбраны с учётом поведения реальных пользователей. Например, одно из исследований говорит о том, что пользователи мобильных устройств обычно сохраняют внимание около 4-8 секунд. Если за это время страница не загрузилась, это означает, что для них общее время загрузки будет состоять из актуального времени загрузки плюс количество времени, в течении которого они не смотрели на устройство, после того как страница была загружена. Ещё одно исследование говорит о том, что пользователи замечают проблемы с отзывчивостью интерфейса, если время задержки до визуального фидбека находится в районе 150 миллисекунд.

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

#performance #metrics

https://blog.chromium.org/2020/05/the-science-behind-web-vitals.html

Пару недель назад инженеры из facebook опубликовали статью про редизайн главного сайта социальной сети — "Rebuilding our tech stack for the new Facebook".

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

Для работы с CSS используют своё CSS-in-JS решение, которое на стадии сборки приложения извлекает стили из кода компонентов в CSS-файлы. При извлечении стилей используется подход Atomic CSS, в котором одно правило представляется отдельным классом. Благодаря Atomic CSS удалось уменьшить общий объём стилей на 80% по сравнению со старой версией facebook. Кроме извлечения стилей CIJ-библиотека упрощает работу с относительными размерами шрифтов для улучшения a11y. Разработчики могут использовать в коде компонентов размеры в пикселях, на этапе сборки они автоматически преобразуются в rem'ы.

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

#facebook #cssinjs

https://engineering.fb.com/web/facebook-redesign/

Томас Штейнер из Google опубликовал пост про новое API — "The requestVideoFrameCallback API".

Метод requestVideoFrameCallback() находится у элемента <video>. Он позволяет регистрировать колбэк, который будет выполняться при отправке каждого кадра видеопотока в композитор, то есть на этапе рендеринга изображения. Эта фича предназначена для эффективной обработки видео в браузере, для синхронизации с внешними звуковыми источниками, для видео-анализа и "зеркалирования" видео в canvas. Частота, с которой вызывается колбэк, минимальное значение от частоты экрана и частоты кадров видео.

На данный момент поддержка requestVideoFrameCallback API есть только в Chromium, разработчики Firefox тоже заинтересованы в реализации этой фичи. Если всё взлетит, то вполне возможно, что через пару лет в браузере будет работать Adobe Premiere.

#video #api

https://blog.tomayac.com/2020/05/15/the-requestvideoframecallback-api/

Иван Акулов проанализировал js-бандлы и флоу загрузки web-приложения Notion и дал много советов по улучшению его производительности — "Case study: Analyzing Notion app performance".

Приложение загружается долго, это особенно заметно на смартфонах среднего ценового сегмента — время загрузки достигает 12 секунд. Больше всего времени уходит на парсинг и выполнение JS. В решении этой проблемы может помочь код-сплиттинг и удаление ненужного кода. Notion использует lodash, чтобы удалить из его кода неиспользуемые методы юзают babel-plugin-lodash. Notion для работы с датами использует moment, вместо этой библиотеки лучше использовать современные и оптимизированные альтернативы, например, date-fns. Также в бандле приложения было найдено три разных версии core.js — библиотеки полифиллов. Такое происходит, когда приложение и зависимости используют core.js разных версий. Для решения этой проблемы можно настроить маппинг модулей с помощью resolve.alias в конфиге wepback. В статье есть рекомендация транспилировать модули в CommonJS с помощью babel-плагина plugin-transform-modules-commonjs с опцией lazy. Такая оптимизация позволяет отложить выполнение js-кода, который можно не выполнять на этапе инициализации приложения.

Очень большая и хорошая статья. Обязательно почитайте, если разрабатываете SPA.

#performance #bundle

https://3perf.com/blog/notion/