Фред Шот — автор библиотеки pika — опубликовал статью с рекомендациями по настройке bundler-free окружения для разработки современных web-приложений — "Building without bundling: How to do more with less".

Может возникнуть резонный вопрос: "Зачем избавляться от бандлера?". В начале статьи Фред подсчитывает количество времени, которое отнимает у разработчиков сборка проекта. Для больших проектов, которые запускаются за 42 секунды и пересобираются за 11 секунд, время ожидания может занимать более часа (для 40-часовой рабочей недели).

Если вы используете у себя в проекте модульную систему из ES2015, сборка проекта необязательна, так как все современные браузеры уже поддерживают модульность в JS. Проблема остаётся с node_modules, которые могут содержать спецификаторы, которые браузер не сможет разрезолвить, или с node-специфичным кодом, например, process.env.NODE_ENV. Для решения этих проблем Фред предлагает использовать его библиотеку pika, которая преобразует код из node_modules в esm-бандлы. По сравнению с традиционными бандлерами у такого подхода есть преимущество — это преобразование надо запустить только один раз после npm install. Для работы с JSX предлагается использовать библиотеку htm.

Описанный в статье подход — это возврат к той простоте, с которого начинался web. Очень рекомендую прочитать статью, если у вас большое приложение, которое собирается долго и вы хотите что-то с этим сделать.

#bundler #web #dx

https://blog.logrocket.com/building-without-bundling/

Пару дней назад была представлена web-версия Apple Music. Web-версия также как и десктопная использует Ember, но с добавлением web-компонентов. Макс Линч — один из создателей Ionic — написал свои мысли по этому поводу в статье "Apple Just Shipped Web Components to Production and You Probably Missed It".

Макс пишет о том, что в сообществе очень много споров по поводу компонентных js-фреймворков и web-компонентов, так как они решают по сути одну и ту же задачу создания интерфейсов из переиспользуемых блоков. Тот факт, что Apple использует почти 50 компонентов у себя в приложении (нотификации, контролы для управления подкастами, видеоплейер и т.п.) говорит о том, что существует ниша для их применения. Например, их можно использовать для создания таких компонентов, которые могут быть использованы с разными фреймворками (скорее всего Apple решает именно эту задачу). Для создания web-компонентов в Apple music используется SencilJS, которая служит основой для Ionic.

Здорово видеть примеры удачного использования современных возможностей web-платформы в больших приложениях.

#webcomponents #ember #jsframeworks

https://dev.to/ionic/apple-just-shipped-web-components-to-production-and-you-probably-missed-it-57pf

В блоге NPM была опубликована статья, посвящённая проблемам безопасности при работе с зависимостями, — "AppSec POV on Dependency Management".

В статье рассматриваются подходы, которые могут снизить риск атаки. Первое, на что стоит обращать внимание при выборе пакета, метрики качества (наличие тестов, актуальные версии зависимостей и т.п.) Стоит посмотреть на активность поддержки пакета. Если версии выходят нерегулярно или последнее обновление выходило очень давно, есть риск, что пакет может попасть в руки злоумышленников. Именно это произошло с пакетом event-stream в прошлом году.

Есть пара советов, что делать при исследовании потенциально-опасных пакетов. Для безопасной установки можно использовать npm install --ignore-noscripts. В этом случае скрипты установки не будут выполняться. Можно запустить npm audit для проверки наличия уязвимостей в зависимостях. Для того чтобы можно было запустить аудит без установки пакетов, следует использовать флаг --package-lock-only.

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

#npm #security

https://blog.npmjs.org/post/187496869845/appsec-pov-on-dependency-management

Эяль Эйзенберг из Wix рассказал про свой опыт уменьшения бандла приложения с помощью React Lazy/Suspense и код-сплиттинга — "Trim the Fat From Your Bundles Using Webpack Analyzer & React Lazy/Suspense".

В начале статьи автор пишет про меры, которые можно предпринять на этапе разработки, чтобы размер приложения внезапно не вырос. Для оценки размера подключаемой библиотеки её стоит проверить c помощью сервиса Bundlephobia. Для того чтобы размер импортируемых библиотек всегда был на виду, можно использовать плагин import-cost (есть поддержка VS Code, Vim, WebStorm, Atom). Далее в статье разбирается пример динамической загрузки кода с помощью React.lazy и React.Suspense, который позволяет вынести часть кода в отдельный чанк. Выглядит он так:

const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    <div>
      <React.Suspense fallback={<div>Loading...</div>}>
        <OtherComponent />
      </React.Suspense>
    </div>
  );
}

После всех оптимизаций размер бандла удалось уменьшить на 80%.

Статья хорошая с примерами из реальной практики. Если не знаете, куда копать при оптимизации размера приложения на React, то эта статья может помочь.

#performance #webpack #react

https://www.wix.engineering/post/trim-the-fat-from-your-bundles-using-webpack-analyzer-react-lazy-suspense

Михай Парпарита из Quip написал статью про то, как они отлаживают своё приложение — "How Quip Builds In-Product Debugging Tools".

Основная мысль статьи — стоит немного потрудиться и сделать инструмент, который будет помогать в отладке. Такая инвестиция времени быстро возместится в будущем.

Quip использует много подобных инструментов. Например, для визуализации взаимосвязи уровня данных и представления у них есть "Overlay Id", который для каждого компонента показывает соответствующие данные модели. Есть инструмент для отладки редактора, который в инлайн-режиме отображает отладочную информацию об отображаемых сущностях. Такой подход исключает затраты времени на открытие инструментов разработчика и потерю фокуса из редактора. Есть небольшой инструмент, который показывает в оверлее количество ререндеров компонента. Реализуется он так: в каждый компонент инжектится componentDidUpdate, который увеличивает счётчик и записывает его в data-атрибут. Значение атрибута отображается поверх компонента с помощью CSS:

.debug-react-rerender-count:after {
    content: attr(data-debug-react-rerender-count);
    // other styles for positioning and color
}

Мне статья понравилась. В ней есть интересные идеи, которые можно применить в своём проекте.

#dx #debug

https://quip.com/blog/how-quip-builds-inproduct-debugging-tools

Сегодня прочитал статью Прити Сэм про создание анимированных иконок сайта — "The Making of an Animated Favicon".

Для создания анимированной favicon, можно использовать canvas, в котором с течением времени (или как реакция на сигнал от сервера) будет рисоваться индикатор загрузки. После каждой перерисовки получившийся результат переносится в тег <link>:

const canvas = document.querySelector('canvas'),
// [...] тут код отрисовки [...]
favicon.href = canvas.toDataURL('image/png');

С примером из статьи есть проблема. Если перейти на соседнюю вкладку, то анимация в Chromium-based браузерах останавливается. Это возникает из-за того, что Chromium останавливает таймеры на неактивных вкладках. Чтобы обойти это ограничение, можно использовать web-воркеры.

#web #trick

https://css-tricks.com/the-making-of-an-animated-favicon/

Два дня назад вышла новая версия Chrome 77. По каким-то причинам в этот раз не было отдельной публикации на официальном сайте, но появилось несколько видео на youtube.

В Chrome 77 появилась поддержка Largest Contentful Paint. Про эту метрику я писал ранее. С её помощью можно отследить время появления основной части контента на странице. Была добавлена поддержка Form Participation API. Благодаря ему можно создавать Custom Elements, которые будут вести себя как полноценные элементы управления стандартных форм. Также в рамках этого api у форм появилось событие formdata, на который можно повесить обработчик для модификации отправляемых данных перед submit.

В инструментах разработчика тоже есть несколько нововведений. Теперь можно скопировать стили dom-узла (контекстное меню на элементе -> copy -> copy styles). Цветовая тема соответствует настройкам операционной системы. Добавили визуализацию сдвига контента. На вкладке "Network" появилась индикация того, что ресурс был загружен из Prefetch Cache. На вкладке "Application" видны push-сообещния и нотификации от сервис-воркеров. Можно логировать эти события до трёх дней даже при закрытых инструментах разработчика.

#chrome #release

https://www.youtube.com/watch?v=S8aVB3IfOR4
https://www.youtube.com/watch?v=R8KzoMoKhnM

Дэвид Петер из Mailchimp написал статью про то, каких подходов при тестировании придерживается их команда — "Designing automated tests for React".

В статье очень много дельных мыслей, к которым стоит прислушаться. Например, следует придерживаться баланса при написании тестов — огромное количество тестов само по себе может стать проблемой, так как тесты это код, который следует поддерживать и писать. Зачастую на написание тестов может уходить больше времени, чем на написание фичи. Но при этом было бы глупо совсем отказываться от тестов, поэтому надо хорошо взвешивать, что тестить, а что оставить в покое. Ещё из статьи запомнилось то, что html создавался без учёта динамичных пользовательских интерфейсов. ARIA-атрибуты позволяют выражать недостающую семантику для элементов страницы, и этим фактом следует пользоваться при написании тестов.

Единственное, что у меня вызвало вопросы — отказ от снепшот-тестирования. Автор пишет, что снепшоты не выражают намерений. Я считаю, что их интент состоит в том, что они закрепляют контракт на уровне того, какую вёрстку должен генерировать компонент (мини-аналог скриншот-тестирования). Но при этом их стоит использовать благоразумно (например, не более одного снепшот-теста на компонент), так как большое количество снепшотов сложно ревьювить, и на них просто могут перестать обращать внимание.

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

#testing #react

https://increment.com/testing/designing-automated-tests-for-react/

Зак Лезерман рассказал, как он ускорял загрузку web-шрифтов на CSS Tricks в статье "Developing a Robust Font Loading Strategy for CSS-Tricks".

Для того чтобы избежать FOIT (Flash of Invisible Text) и FOUT (Flash of Unstyled Text), Зак разбил исходные файлы шрифтов (regular и bold) на две части. Первая часть содержала информацию о кёрнинге (для предотвращения reflow документа) и минимальный набор глифов, которые необходимы для отображения латиницы и самых популярных символов, которые могут встречаться в заголовках статей на CSS Tricks. Вторая часть содержала всё остальное: лигатуры, хинтинг, кириллицу и т.п. Первый два файла загружаются с помощью preload, вторая часть — с помощью CSS Font Loading API.

Так как файлы первого этапа весят всего по 13kb, они успевают загружаться до рендеринга документа. Более полная версия шрифта подгружается позже, но это не портит пользовательский опыт.

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

#typography #web

https://www.zachleat.com/web/css-tricks-web-fonts/

Сара Хигли поделилась своими мыслями по поводу доступных тултипов в статье — "Tooltips in the time of WCAG 2.1".

Web Content Accessibility Guidelines (WCAG) — это набор рекомендаций w3c по созданию доступного контента. WCAG покрывает много разных кейсов, но в нём нет явных рекомендаций, что делать с тултипами. Вся проблема в том, что у тултипов может быть разная семантика в зависимости от контекста. Более того, в тултипе могут отображаться интерактивные элементы, что вызывает ещё больше вопросов.

Для тултипов с контролами внутри Сара рекомендует использовать паттерн disclosure button, а для информационных тултипов даёт целый список советов:

- Тултипы должны появляться только на интерактивных элементах
- Тултип должен явно описывать контрол, на котором он был вызван
- Используйте aria-describedby и aria-labelledby для ассоциирования UI-контрола с тултипом
- Не используйте атрибут noscript для тултипов
- Не помещайте важную информацию в тултипы
- Предоставьте возможность закрыть тултип как с помощью клавиатуры, так и с помощью указателя
- Не закрывайте тултип, если пользователь водит по нему указателем мыши
- Не используйте таймаут для закрытия тултипов

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

#ui #a11y #wcag

https://sarahmhigley.com/writing/tooltips-in-wcag-21/

Ребята из Slack продолжают радовать статьями про своё новое приложение. В этот раз они написали про использование сервис воркеров в web-версии — "Service Workers at Slack: Our Quest for Faster Boot Times and Offline Support".

При первой загрузке приложения в кеш сервис воркера помещаются html, звуковые файлы, шрифты, js и css-файлы. Для того чтобы хранящиеся файлы не устаревали, кастомный плагин webpack формирует манифест, который встраивается в установочный код сервис воркера. Изменение кода сервис воркера инициирует его установку, в результате которой происходит загрузка всех файлов из манифеста и их сохранение в кеш. При таком подходе всегда будет загружаться не самая последняя версия клиента. Но на этот шаг пошли осознанно, чтобы сократить время загрузки клиента. Теперь приложение с прогретым кешом стартует в два раза быстрее. Чтобы приложение не устаревало, в фоне регулярно происходит проверка наличия обновлений.

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

Статья хорошая, но, скорее всего, будет интересна не всем.

#serviceworker #experience

https://slack.engineering/service-workers-at-slack-our-quest-for-faster-boot-times-and-offline-support-3492cf79c88

Брайан Карделл — один из участников w3c — приоткрыл завесу над тем, как в последние годы в web-платформе появляется поддержка новых стандартов — "Beyond Browser Vendors".

За каждым браузером есть компания, которая выделяет бюджет на его разработку. Этот бюджет определяет размер команды разработчиков и тот объём задач, который они могут зарелизить. Чаще всего в приоритет ставятся задачи, которые отвечают специфичным запросам компании, что вполне логично. Брайан пишет, что ему как контраргумент на это утверждение приводят гриды. На первый взгляд кажется, что разработчики браузеров смогли договориться между собой и приоритизировать имплементацию гридов так, чтобы их поддержка появилась примерно в один промежуток времени (март 2017 года). Но это не так.

Первое предложение "Frame-Based Layout" появилось в 1996 году, как попытка реализовать грид-подобную систему, управляемую с помощью CSS. Этот пропозал не был имплементирован. В 2005 году Берт Росс опубликовал предложение "CSS Advanced Layout", которое в 2009 году переродилось в "CSS Template Layout", но опять этот пропозал не был имплементирован. В 2011 году Microsoft переосмыслила предыдущие подходы и представила сообществу "Grid Layout", его реализация появилась вместе с IE10. Но на этом всё и остановилось, так как Microsoft решала свои внутренние задачи с внедрением этого стандарта.

Примерно в это же время web становился всё более и более открытым — стал прозрачнее процесс стандартизации, основную часть рынка поглотили браузеры с открытым исходным кодом. Этот факт позволил другим компаниям участвовать в разработке стандартов. В итоге, внедрением гридов в Chrome и Safari занималась Igalia — консультационное агентство, где работает Брайан. Работу полностью профинансировал Bloomberg. Подобным образом в Chromium была добавлена поддержка ResizeObserver, BigInt, private fields, MathML и других фич. Брайан не говорит о том, что вендоры плохие и ничего не делают, наоборот, он говорит о том, что они тоже участвуют в разработке, как минимум в ревью и в дальнейшей поддержке кода.

Ставлю этому посту свой любимый тег — history. Очень рекомендую почитать статью всем, кто интересуется историей web'а.

#musings #history #web

https://bkardell.com/blog/Beyond.html

Пару дней назад в код v8 была добавлена реализация предложения "Top-level await" (Stage 3). Про этот пропозал в канале ещё ничего не было, поэтому хочу написать небольшое объяснение того, какую проблему он решает.

Top-level await добавляет поддержку await на верхнем уровне модуля, то есть вне асинхронных функций, которые декларируются с помощью async. Это позволяет превратить модуль в некое подобие большой асинхронной функции. При импорте такого модуля асинхронный код, помеченный с помощью ключевого слова await, будет останавливать выполнение импортирующего модуля до того момента, пока все зависимости не будут зарезолвлены. Вот пример преобразования "асинхронного модуля" с помощью top-level await:

// было
import { process } from "./some-module.mjs";
export default (async () => {
  const dynamic = await import(computedModuleSpecifier);
  const data = await fetch(url);
  const output = process(dynamic.default, data);
  return { output };
})();

// стало
import { process } from "./some-module.mjs";
const dynamic = import(computedModuleSpecifier);
const data = fetch(url);
export const output = process((await dynamic).default, await data);

Добавление в стандарт top-level await упростит работу с динамическими импортами и модулями, предоставляющими асинхронные ресурсы, например, соединение с базой данных.

#future #async #tc39

https://github.com/tc39/proposal-top-level-await

Нашёл в твиттере ссылку на интересную статью Николаса Закаса 2015-го года — "The bunny theory of code".

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

Почему так происходит? Мы редко начинаем писать что-то с нуля в существующем проекте. В первую очередь мы ищем то, как данную проблему решали наши коллеги. Если решение было найдено, то с большой вероятностью оно будет скопировано в новый файл, так как закомиченный код неявно выступает неким гарантом качества. Поэтому стоит делать всё возможное, чтобы поддерживать это качество. Например, с помощью хорошего код ревью, воркшопов, обсуждения спонтанно возникших паттернов (“accidental standards") и т.п.

Читал статью с улыбкой. Николас хорошо описал, как работают разработчики с кодом. По крайней мере, лично я стараюсь не изобретать велосипед в рабочем проекте, но сначала ищу, не был ли этот велосипед изобретён другими.

#musings #programming

https://humanwhocodes.com/blog/2015/05/14/the-bunny-theory-of-code/

Олег @oleg_log Ковалёв скинул в личку ссылку на интересную статью — "Wikipedia's JavaScript initialisation on a budget". В ней рассказывется про то, как ребята из Wikipedia оптимизировали загрузку JavaScript-кода на клиент.

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

Уменьшение размера было достигнуто благодаря реструктуризации загружаемых скриптов. Например, в одной фиче использовалось 248 разных модуля. Идентификаторы этих модулей попадали в манифест, тем самым увеличивая его размер. Спустя полгода после обнаружения проблемы число модулей удалось снизить до 42. Самое крутое то, что в итоге они смогли достигнуть своей цели в 28kb на размер манифеста (было 36kb, стало 27kb). Такой размер гарантирует, что ресурс будет доставлен на клиент не более чем за две сессии отправки http-пакетов (bursts of packets).

На первый взгляд кажется, что 9kb, которые были сэкономлены, не очень много, но для Wikipedia это складывается в 4 терабайта сэкономленного траффика каждый день.

#performance #http

https://phabricator.wikimedia.org/phame/post/view/175/wikipedia_s_javanoscript_initialisation_on_a_budget/

Реми Шарп написал небольшой пост про то, почему в теге <head> не появляется поддержка новых элементов — "Head is locked".

В <head> могут находится элементы noscript, meta, style, noscript, base и link. Если поместить любой другой элемент в <head>, он будет перемещён внутрь <body>, так работают браузеры. Если бы в стандарте появились новые элементы внутри <head>, то в браузерах без поддержки этих элементов, будет отображаться лишняя информация, нарушая принцип обратной совместимости HTML. Именно по этой причине тег <link> эксплуатируется для разных целей (link rel="preconnect" и т.п.)

#history #html

https://remysharp.com/2019/09/13/head-is-locked

Случайно нашёл небольшую статью про CSS-свойство scroll-behavior, которое является частью чернового стандарта CSS View Module.

При переходе по ссылкам на внутренние части страницы с помощью якорей (ссылки начинающие на символ # ) страница прокручивается резко. Плавную прокрутку можно сделать с помощью JavaScript, но тоже самое можно реализовать с помощью scroll-behavior. Это CSS-свойство поддерживает два значения: auto — для обычного резкого перехода, smooth — для плавной прокрутки к якорю.

Со scroll-behavior: smooth есть две основные проблемы: он не поддерживается в Safari, и он может вызывать укачивание у пользователей. Поддержку в Safari стоит только ждать, а с укачиванием можно побороться с помощью отключения плавного скролла с использованием media query prefers-reduced-motion.

#css #experimental

https://css-tricks.com/almanac/properties/s/scroll-behavior/

В блоге WebKit около двух недель назад появилась статья про статус поддержки WebGPU API в Safari — "WebGPU and WSL in Safari".

Железо и архитектура видеокарт постоянно улучшается. Одновременно с их развитием появляются новые программные API, которые умеют c ними эффективного работать. На сегодняшний день есть Direct3D 12 от Microsoft, Metal от Apple и Vulkan от Khronos Group. Эти API работают на более низком уровне абстракции по сравнению с OpenGL, поэтому они более производительны. Проблема в том, что они не доступны на всех платформах, то есть не могут быть использованы для web'а. Для того чтобы решить эту проблему, разрабатывается новый стандарт для работы с видеокартами — WebGPU.

WebGPU предоставляет набор JavaScript API, с помощью которого рендеринг объектов отделяется от процесса их валидации, тем самым предоставляя разработчикам возможность эффективного управления процессом рендеринга. В статье есть график результатов синтетического бенчмарка. Там видно, что прирост производительность по сравнению с WebGL может увеличиться до семи раз. Есть планы по поддержке WebGPU API из WebAssembly в будущем. В статье ещё немного рассказывается про Web Shading Language (WSL) — новый язык шейдеров, поддержка которого появилась в Safari TP 91. Его основная особенность в том, что он создавался с нуля для поддержки всех платформ и графических API, которые поддерживает WebGPU.

Мне лично непонятно, какая судьба будет у WebGL 2.0. С учётом того, что в разработку WebGPU активно инвестирует Apple, есть риск, что поддержка WebGL 2.0 в Safari так и останется на экспериментальном уровне.

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

#webgpu #experimental #safari

https://webkit.org/blog/9528/webgpu-and-wsl-in-safari/

Рекомендую хороший канал @drbrain4web, посвящённый web-разработке (JavaScript и PHP). Ведёт канал fullstack-разработчик Георгий Астахов.

Каждый день в канале публикуются:
- актуальные авторские статьи и переводы,
- тренды,
- примеры кода,
- интересные задачи.

Front & Back. @drbrain4web ждёт вас.

https://news.1rj.ru/str/drbrain4web

Нолан Лоусон недавно написал пост про особенности разработки сайтов под KaiOS — "The joy and challenge of developing for KaiOS".

KaiOS — это набирающая популярность операционная система для бюджетных телефонов. Она очень популярна в Индии. По количеству устройств KaiOS занимает второе место после Android.

В статье рассказывается, как начать разрабатывать под эту операционную систему. KaiOS построена на базе Firefox OS, в основе которой лежит Firefox 48. То есть все приложения в системе — это запакованные web-приложения (html, js, css). Устройства на базе KaiOS, очень ограничены в характеристиках, например, в статье для разработки автор использует Nokia 8110 4G. У этого телефона обычный экран (не сенсорный) с разрешением 240x320. Навигация в системе происходит с помощью клавиатуры. Нолан пишет, что адаптация его проекта под KaiOS помогла с a11y, так как интерфейс стал полностью доступен с клавиатуры.

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

#mobile #web

https://nolanlawson.com/2019/09/22/the-joy-and-challenge-of-developing-for-kaios/

В сервисе Google Fonts появилась поддержка вариативных шрифтов. На данный момент она доступна как бета-версия (возможно изменение api в будущем) по адресу https://fonts.googleapis.com/css2.

Если на сайте используется семейство шрифтов с разной насыщенностью и разной шириной глифа (например, condensed), то каждая вариация будет представлена отдельным файлом шрифта. Из-за этого общий объём загружаемых шрифтов на сайтах с богатой типографикой может легко превысить несколько сотен килобайт. Вариативные шрифты решают эту проблему, представляя каждый глиф как контур и предоставляя возможность управления этим контуром. Каждая вариация отрисовывается браузером динамически. Благодаря этому один файл шрифта может использоваться для разных видов типографики.

На данный момент поддержка вариативных шрифтов есть во всех актуальных браузерах. Если интересно узнать больше про особенности их работы, то рекомендую почитать статью "Introduction to variable fonts on the web".

#typography #web

https://codepen.io/nlwilliams/full/JjPJewp