Команда разработчиков 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.

#typescript #migration

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

Том МакРайт поделился мыслями про текущее состояние дел в современном вебе — "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. Была улучшена проверка типов для пересечений объектов с опциональными свойствами и общими несовместимыми свойствами и т.п.

#typescript #release #announcement

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

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

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

Райан Дал — автор 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/javascript-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-ecmascript-part-4#using-cpeaapl-in-productions