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

— Почему Wrike перестаёт использовать Dart для новых проектов
— Как убедить начальство в том, что производительность имеет значение
— Преимущества и недостатки Headless CMS
— Почему дизайн-система должна быть несовершенна
— Нативные методы для форматирования даты и времени в JavaScript
— Не пишите свою функцию для парсинга параметров URL
— Порядок элементов в HTML и доступность
— Стилизация с заделом на будущее
— Использование Makefile вместо npm-скриптов
— Как правильно скрывать видео на мобильных

Становитесь патроном канала на Patreon, чтобы получить доступ к дополнительным постам в Defront Plus. Моя работа над каналом — это единственный заработок. Все донаты идут на поддержку канала, покупку еды, оплату аренды квартиры и т.п.

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

https://www.patreon.com/myshov

Когда были представлены метрики Web Vitals ребята из Google упомянули, что они будут учитываться при ранжировании результатов поиска. Вчера была опубликована статья, рассказывающая о том, когда это произойдёт — "More time, tools, and details on the page experience update".

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

Также в этой статье было сделано несколько смежных анонсов. С середины июня сайтам не обязательно распространять свой контент в виде AMP, чтобы попасть в раздел "Top Stories" (новости), учитываться будет только скорость загрузки страниц. Значки AMP-страниц будут удалены из результатов поиска. Signed Exchanges (SXG) можно будет подключить к любым страницам. Благодаря SXG сайты могут делегировать распространение контента другому сайту, сохраняя URL оригинального сайта (поддержка SXG есть только в Chromium).

#performance #seo #google

https://developers.google.com/search/blog/2021/04/more-details-page-experience

Вчера вышла новая мажорная версия Node.js. Бетани Григгс рассказала про новинки релиза — "Node.js 16 available now".

Node.js 16 — это current-ветка, которая перейдёт в статус LTS в октябре 2021 года. В статье есть напоминание, что поддержка Node.js 10 будет прекращена в конце этого месяца (апрель 2021).

V8 был обновлён до версии 9.0. В этой версии была добавлена поддержка пропозала RegExp Match Indices и оптимизирован доступ к полям родительского объекта с помощью super.

Был добавлен Timers Promises API — альтернативный набор функций на базе промисов для работы с таймерами.

Продолжается адаптация API веб-платформы: добавлена экспериментальная поддержка Web Crypto API, стабилизировалась реализация AbortController, добавлены buffer.atob() и buffer.btoa().

Npm обновлён до версии 7.10.0. API для разработки нативных аадонов Node-API (бывший N-API) обновлён до версии 8. Добавлена поддержка Stable Source Maps v3.

#nodejs #release

https://nodejs.medium.com/node-js-16-available-now-7f5099a97e70

Эрик Белли объясняет на примерах, почему CSS — это сильно типизированный язык — "CSS is a Strongly Typed Language".

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

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

#css

https://css-tricks.com/css-is-a-strongly-typed-language/

Барри Поллард написал руководство по оптимизации метрик Web Vitals — "An In-Depth Guide To Measuring Core Web Vitals".

Web Vitals — это пользовательский опыт сайта, облачённый в цифры. Раньше для его измерения использовался Performance Score из Lighthouse. Он включает в себя набор метрик, которые не полностью совпадают с набором метрик Web Vitals. По этой причине хорошая оценка Performance Score потенциально может включать в себя плохую оценку, например, метрики CLS.

Отчёты из Google Search Console — основной инструмент для наблюдения за тем, как метрики Web Vitals будут влиять на поисковую выдачу Google. Данные для этого отчёта собираются с реальных пользователей, которые согласились делиться статистикой о посещённых сайтах (Chrome User Experience Report — CrUX). Данные агрегируются за последние 28 дней по 75-ому перцентилю, поэтому исправление производительности сайта начнёт отображаться в отчёте не сразу. Возможно, что нужно будет подождать несколько недель.

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

#performance

https://www.smashingmagazine.com/2021/04/complete-guide-measure-core-web-vitals/

Николас Закас написал статью про ленивый доступ к свойствам объекта — "The lazy-loading property pattern in JavaScript".

Если в объекте есть свойство, значением которого является результат выполнения тяжёлого вычисления, то имеет смысл отложить это вычисление до того момента, пока не произойдёт обращение к свойству. Николас предлагает использовать паттерн, который позволяет не только откладывать вычисление, но и кеширует результат его выполнения:

const object = {
  get data() {
    const actualData = someExpensiveComputation();

    Object.defineProperty(this, "data", {
      value: actualData,
      writable: false,
      configurable: false,
      enumerable: false
    });

    return actualData;
  }
};

Этот подход можно использовать с любыми объектами и классами.

#js #performance

https://humanwhocodes.com/blog/2021/04/lazy-loading-property-pattern-javascript/

Алексей Трехлеб из Uber написал статью про изменение размера изображения с помощью алгоритма Seam Carving — "Изменение размеров изображения с учётом его содержимого в JavaScript".

Основная идея алгоритма Seam Carving заключается в изменении размера изображения с сохранением пропорций объектов изображения с помощью удаления "швов" — последовательности смежных пикселей с наименьшей энергией, идущих от одного края изображения к другому. Пикселем с наименьшей энергией считается такой пиксель, который очень похож на свои соседние пиксели. Для вычисления этой метрики используется формула:

const lEnergy = (lR-mR) ** 2 + (lG-mG) ** 2 + (lB-mB) ** 2;
const rEnergy = (rR-mR) ** 2 + (rG-mG) ** 2 + (rB-mB) ** 2;
const result = Math.sqrt(lEnergy + rEnergy);

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

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

#algorithm

https://trekhleb.dev/blog/2021/content-aware-image-resizing-in-javascript/
https://vas3k.club/post/9637/ (на русском языке)

Франсуа Хендрикс рассказал о том, как сделать библиотеку, у которой не было бы проблем с три-шейкингом — "How To Make Tree Shakeable Libraries".

Недостаточно поправить конфиг сборки приложения, чтобы бандлер смог выкинуть неиспользуемый код библиотеки. Сама библиотека не должна мешать этому процессу. Eё код должен быть написан с использованием ESM и разбит на большое число небольших модулей, которые экспортируют только один кусок логики. При сборке библиотеки нужно настроить её бандлинг с сохранением структуры. Это нужно делать для того, чтобы бандлеры могли применять оптимизации, опираясь на информацию из поля sideEffects package.json.

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

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

#performance #bundle #library

https://blog.theodo.com/2021/04/library-tree-shaking/

Сходил в гости к веб-стандартам. Обсудили новые версии Node.js, Firefox, Chrome и Safari. Разобрались в том, почему Google борется за быстрый веб. Ну и немного поговорили про Defront.

Выпуск №279. Вадим Макеев, Александр Мышов, Андрей Мелихов про Defront, Firefox 88, Node.js 16, бету Chrome 91, XHR как дискету, внезапный popup, AMP и Core Web Vitals.

Слушайте на Ютубе https://youtu.be/A7HWbbx1qMQ
Ссылки на сайте https://web-standards.ru/podcast/279/

В блоге DebugBear была опубликована статья, посвящённая отладке проблем производительности сайта с помощью Chrome DevTools, — "Profiling site speed with the Chrome DevTools Performance tab".

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

Совет из статьи. Часто возникает ситуация, когда сложно понять взаимосвязи между активностями во время загрузки страницы, так как они происходят почти одновременно. Для упрощения отладки можно "растянуть" по времени эти активности с помощью троттлинга сети и CPU.

Полезная статья. Рекомендую заглянуть.

#performance #debug

https://www.debugbear.com/blog/devtools-performance

Ахмад Шадид написал статью про CSS Container Queries — "Say Hello To CSS Container Queries".

Для управления контекстным отображением компонентов можно использовать медиавыражения, но они не подходят для случаев, когда компонент может быть размещён в контейнерах с разной шириной. Эту проблему решают выражения от контейнера (Container Queries). Благодаря им у нас появляется возможность задавать элементам стили, которые зависят от размера контейнера:

@container (min-width: 400px) {
  .c-article {
    display: flex;
    flex-wrap: wrap;
  }
}

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

На данный момент выражения от контейнера доступны только в Chrome Canary за экспериментальным флагом.

#css #experimental

https://ishadeed.com/article/say-hello-to-css-container-queries/

Джон Дэвис в блоге WebKit рассказал о новых возможностях Safari 14.1, который зарелизился пару дней назад, — "New WebKit Features in Safari 14.1".

В CSS добавлена поддержка гэпов для флексбоксов. Добавлены индивидуальные свойства трансформации элементов: scale, rotate, translate. Также Safai для macOS теперь поддерживает поля для ввода даты и времени.

В JavaScript появилась поддержка приватных полей и публичных статических полей класса. В Internationalization API добавлены новые методы: Intl.DisplayNames, Intl.ListFormat, Intl.Segmenter. В методе Intl.DateTimeFormat добавлена поддержка опций dateStyle и timeStyle. Имплементирован пропозал WeakRef.

Добавлена реализация Paint Timing API. На данный момент он предоставляет информацию по двум метрикам: first-paint и first-contentful-paint. Web Speech API начал предоставлять средства для распознавания речи. Решены некоторые проблемы совместимости в Web Audio API, добавлены Audio Worklets. Добавлена реализация MediaRecorder API для записи аудио и видео. Появилась поддержка WebM (открытый формат для хранения видео). Улучшена приватность Storage Access API. Добавлен механизм для приватного отслеживания кликов — Private Click Measurement (PCM).

WebAssembly теперь умеет работать с потоками, добавлена интеграция с JavaScript BigInt, добавлен новый sign-extension operator (эта фича реализована автором телеграм-канала @webnya).

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

#release #safari

https://webkit.org/blog/11648/new-webkit-features-in-safari-14-1/

Джейк Арчибальд взял небольшую паузу в анализе производительности сайтов команд Формулы-1 и попробовал найти причину медленной загрузки сайта Google I/O — "Performance-testing the Google I/O site".

На слабом устройстве сайт Google I/O загружается за 26 секунд. Основная проблема заключается в том, что это SPA-приложение — для отображения описания докладов, времени и аватарок нужно загрузить около 5Мб JS и JSON. Сайт не использует код-сплиттинг, поэтому в бандл попадает много второстепенного кода. Есть проблемы с загрузкой кода для авторизации — он загружается со стороннего сервера, затрачивая секунду на установку соединения. Также для отображения одной иконки меню загружается относительно тяжёлый иконочный шрифт.

Сайт Google I/O работает почти также медленно как сайт МакЛарен, уступая последнее место сайту Ферарри.

#performance

https://jakearchibald.com/2021/io-site-perf/

Джо Сэпл, Майкл Доусон и Бэттани Григгс из команды разработки Node.js рассказали о том, что нам стоит ожидать от Node.js в будущем — "What's Next, The Future of Node.js".

В Node.js 14 была добавлена экспериментальная поддержка AsyncLocalStorage API, который упрощает обмен данными между асинхронными вызовами. Скоро будут стабилизированы основные части этого API (уже есть готовый пулл реквест).

В Node.js 16 появилась стабильная поддержка Source Maps v3. На данный момент можно включить поддержку сорсмапов для стектрейсов, но работа по их внедрению ещё не закончена.

В рамках добавления поддержки ECMAScript Modules идёт работа над Loader API, с помощью которого можно писать свои лоадреы для трансформации импортируемого кода (например, можно написать лоадер, который будет автоматически транспилировать TypeScript-файлы при их импорте). Также идёт работа над добавлением JSON Modules, WASM Modules и top-level await. Некоторые API уже доступны за экспериментальным флагом.

Планируется добавление Fetch API. Fetch требует много работы, но есть вероятность, что он попадёт в Node.js в конце этого года.

Также команда разработки сейчас проводит опрос, который поможет спланировать развитие Node.js на ближайшие десять лет.

#nodejs #talk

https://www.youtube.com/watch?v=vrnToZP47Ro
https://nodejs.medium.com/next-10-years-of-node-js-understanding-the-needs-of-the-node-js-constituencies-2f95a1df6a6f

Недавно была опубликована статья, в которой рассказывается про работу с базой данных на статических сайтах — "Hosting SQLite databases on Github Pages".

Когда нужно организовать доступ к большому массиву данных (в режиме read only), а поднимать полноценный бекенд не хочется, можно воспользоваться решением из статьи. Автор реализовал виртуальную файловую систему для sql.js — WebAssembly-версии SQLite. Движок SQLite думает, что работает с обычным файлом, но все запросы на чтение транслируются в HTTP Range запросы к файлу базы данных на сервере. Для хостинга базы можно использовать GitHub Pages, Netlify и т.п.

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

#webassembly #staticsite

https://phiresky.github.io/blog/2021/hosting-sqlite-databases-on-github-pages/

В блоге CSSSR была опубликована вторая часть статьи про историю фронтенда — "История фронтенда: JavaScript как отражение новой эпохи".

Во второй части рассказывается про историю появления и развития веб-стандартов. HTML и JavaScript пережили похожий процесс: сначала была жёсткая конкуренция браузеров с хаотичным внедрением фич, затем предпринималась попытка стандартизации, которая была отвергнута сообществом (XHTML) или стала неудачной из-за слишком больших амбиций (ECMAScript 4), потом был застой, а затем продуктивная работа вместе с сообществом. HTML и JavaScript стали живыми стандартами, которые обновляются каждый год и поддерживаются всеми браузерами.

Рекомендую почитать статью, если интересуетесь историей развития веба. Ещё есть видеоверсия, но статья интереснее (имхо).

#history #web

https://blog.csssr.com/ru/article/frontend-history-java-script-as-a-reflection-of-a-new-era/
https://www.youtube.com/watch?v=sgyoKkAfGpU (видео)

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

— Сравнение производительности JavaScript и WebAssembly
— Великий SameSite конфуз
— Эффективная разработка с помощью декомпозиции задач
— Прохождение алгоритмического интервью на позицию старшего разработчика
— Современный мобильный веб и его тестирование
— Третья эпоха JavaScript
— Миграция фронтенда Sentry на TypeScript
— Лучшие практики разработки куки-баннеров
— Сравнение CSS и CSS-in-JS
— Культ лучших практик

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

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

https://www.patreon.com/myshov

Кристьян Оддссон рассказал об опыте использования веб-компонентов в GitHub — "How we use Web Components at GitHub".

В 2018 году GitHub завершил модернизацию фронтенд-кода, который был очень сильно завязан на jQuery. С того момента ребята разработали Ruby-фреймворк ViewComponent для создания независимых компонентов-вьюх и библиотеку Catalyst для упрощения разработки веб-компонентов, которая была вдохновлена Stimulus и LitElement.

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

#webcomponents

https://github.blog/2021-05-04-how-we-use-web-components-at-github/
https://github.com/github/github-elements (репозиторий компонентов)

P.S. Благодарю Олега Ковалёва (@oleg_log) за наводку на статью.

V8 релиз v9.1

- Включили private brand checks по умолчанию (было за флагом), что позволяет использовать оператор in с приватными полями, то есть #foo in obj
- Включили top-level await по умолчанию (было за флагом). Стоит отметить что фича уже включена в Chrome 89 по умолчанию, видимо на подходе Node.js
- Пара специфичных оптимизаций