Николас Закас написал статью про ленивый доступ к свойствам объекта — "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
- Пара специфичных оптимизаций

Буквально за день до выхода статьи про веб-компоненты от GitHub Тайлер Уильямс рассказал об опыте использования веб-компонентов в GitLab — "Using web components to encapsulate CSS and resolve design system conflicts".

В GitLab веб-компоненты используются для инкрементального внедрения новой дизайн системы с изоляцией стилей. Для этого был создан специальный кастомный элемент slp-blog, в котором отображается статически сгенерированный HTML статьи с новым набором стилей. Если по какой-то причине загрузка JS-кода, отвечающего за инициализацию элемента, отваливается, то пользователь всё равно сможет прочитать статью, но без стилизации.

В общем, статья интересная. Почитайте, если хотите познакомиться с ещё одним сценарием использования веб-компонентов.

#webcomponents #css

https://about.gitlab.com/blog/2021/05/03/using-web-components-to-encapsulate-css-and-resolve-design-system-conflicts/

Вчера вышла новая версия Bootstrap. Марк Отто рассказал о всех изменениях в релизе — "Bootstrap 5".

Был добавлен новый компонент offcanvas, представляющий собой выезжающий сайдбар. Ему можно задавать позицию и бэкдроп. Добавлена новая реализация аккордеона, заменив старую на базе .card. Улучшена семантичность контролов форм. Также теперь все контролы поддерживают новый дизайн, унифицируя внешний вид между разными браузерами.

Упрощена работа с раскладкой элементов. Были удалены классы .form-group, .form-row и .form-inline.

Добавлены новые утилитарные классы : .d-grid, .fs, .fw, .overflow-visible, .overflow-scroll, .top-0, .top-50, .top-100 и другие. Появилось API для создания кастомных утилитарных классов.

Добавлена экспериментальная поддержка RTL (Right-to-Left).

#release #css

https://blog.getbootstrap.com/2021/05/05/bootstrap-5/

Кристоф Наказава из Facebook поделился большим количеством советов, которые помогли уменьшить размер зависимостей React Native на порядок — "Dependency Managers Don’t Manage Your Dependencies".

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

В статье рассказывается о том, как быстро найти тяжёлые пакеты, как выстроить процесс добавления новых пакетов в проект с отслеживанием их размера, как избежать проблем с устареванием зависимостей и т.п. Также в статье рассказывается про утилиты, которые полезно использовать при работе с зависимостями. Например, для поиска и удаления дубликатов можно использовать yarn-deduplicate, для поиска неиспользуемых зависимостей — depcheck.

#yarn #package

https://cpojer.net/posts/dependency-managers-dont-manage-your-dependencies

Крис Хагер написал руководство по настройке TypeScript-проекта — "Starting a TypeScript Project in 2021".

Руководство рассказывает про настройку сборки (используя esbuild), линтинга (eslint), тестов (jest), адаптацию Node.js для бесшовной работы с TypeScript (ts-node). Немного затрагивается тема настройки CI (GitHub Actions/GitLab CI) и генерации документации (TypeDoc).

В руководстве предлагается использовать esbuild, и это очень хороший совет. Однако стоит учитывать, что на данный момент поддержка код-сплиттинга в esbuild находится в экспериментальном статусе, поэтому для больших проектов (по крайней мере пока) лучше брать Webpack или Rollup.

#typescript

https://www.metachris.com/2021/04/starting-a-typescript-project-in-2021/

Варун Вачнар пообщался с разработчиками из Adobe, BBC, Twilio, Shopify, Peloton и обобщил подходы, которые они используют при тестировании UI — "How to actually test UIs".

В статье рассказывается о подходах тестирования интерфейсов, создаваемых с помощью компонентного подхода. Для обособленного тестирования компонентов команды используют Storybook, для тестирования поведения компонентов — Testing Library, для тестирования доступности — Axe, для E2E-тестов — Playwright и Cypress.

Есть раздел про визуальное тестирование (тестирование скриншотами), но там нет упоминания инструментов с открытым исходным кодом, например, Hermione, Gemini, cypress-image-snapshot.

Как бы то ни было, статья хорошая. Очень рекомендую почитать.

#testing #tool

https://storybook.js.org/blog/how-to-actually-test-uis/