Браузерное расширение Resource Override для фронтендеров

Иногда возникает нужда переопределить какой-то ресурс для дебага. Например, сервер возвращает сломанный JSON, а хочется протестировать починенный, не делая релиз. Или вы сделали фикс библиотеки, которая лежит на CDN, и хотите посмотреть, как она себя ведёт в проекте.

В Chrome и Safari есть возможность подменять файлы на уровне DevTools. Но динамику так не протестировать, к тому же каждый отдельный файл подменять, когда хочется подменить целую папку, муторно.

Марио Хаманн делится браузерным расширением, которое работает как прокси. Если вам нужно подменить обращения к каким-нибудь ресурсам по маске, оно умеет подменять на другие ресурсы с сохранением этой самой маски.

А ещё при помощи этого расширения можно «патчить» чужие сайты в Интернете.

Не скажу, что это что-то очень уж новое. Подменять ресурсы можно разными способами. Патчить продакшен разные расширения вроде Tampermonkey тоже позволяют довольно давно. Но расширений-прокси 2-в-1 до этого не видел, показалось интересным, чтобы поделиться.

https://mariohamann.com/resource-override-for-frontend-development

Видео с альфа-прозрачностью на веб-страницах

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

- AVIF не подходит. Он умеет в анимации и прозрачность, под капотом использует видеокодек AV1, но Safari прозрачность не поддерживает, а использовать img для воспроизведения видео в принципе не самый правильный подход, потому что браузеры обрабатывают анимации по-другому.

- VP9 и HEVC уже лучше. Но на момент написания статьи в Chrome для Android был баг с прозрачностью, а в Firefox на Android часто останавливается воспроизведение.

- Собрать видео двойной высоты, где верхняя половина — видео, а нижняя половина — маска для видео, а потом при помощи WebGL маскировать одно другим. Вот такой подход у Джейка сработал везде, где нужно.

Чтобы вам не писать шейдеры самостоятельно, Джейк собрал веб-компонент, который берёт рендеринг на себя. И в статье приложил инструкцию, какие настройки применять в ffmpeg для каждого из форматов.

https://jakearchibald.com/2024/video-with-transparency/

Project manager, program manager и product manager — зоны ответственности, навыки и образование

Видео выходного дня. Юлия Белозёрова объясняет, чем отличается Project Manager от Program Manager и Product Manager, и делится советами, на что стоит сделать упор, если хотите делать карьеру в одной из веток.

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

https://www.youtube.com/watch?v=HapZUWiWvWA

State of CSS 2024

У меня в планах на вечер сегодня пройти опрос State of CSS. Стараюсь делать это каждый год, чтобы своим мнением влиять на приоритеты браузеров. А браузерные деврелы результаты этих опросов точно используют, официально про это упоминают. И разработчики спецификаций на результаты смотрят. Так что всё не зря.

Для тех, кто никогда не участвовал в State of CSS: это такой опрос, где много вопросов про то, какие фичи вы знаете, какие нравятся, чего не хватает в CSS, какие фреймворки помогают или мешают работать и так далее.

Присоединяйтесь.

https://survey.devographics.com/en-US/survey/state-of-css/2024

Частые заблуждения про оптимизацию LCP

Если вы работаете с оптимизацией перфоманса страниц, то метрика LCP (Largest Contentful Paint) точно попадалась вам на глаза. Это время от начала загрузки страницы до отрисовки самого большого блока во вьюпорте. Таким блоком может быть и текст, но часто это какая-то картинка, привлекающая внимание. И так как LCP является важной составляющей Core Web Vitals, приходится эту метрику оптимизировать.

В статье Брендана Кенни разбирается миф о том, что для оптимизации LCP достаточно сделать картинки меньше по размеру: использовать современные форматы изображений, сжимать картинки.

На самом деле до отрисовки картинки есть ещё несколько этапов, которые можно посчитать в секундах: время до первого байта, время на задержку запроса за ресурсом, время загрузки ресурса и время рендеринга. И, как показывает статистика, на 75-м перцентиле исследованных сайтов с высокими значениями LCP время на загрузку составляет меньше 10% от всего времени LCP. Да, эти 10% тоже важно оптимизировать, но как будто стоит обратить внимание на остальные этапы.

Брендан советует обращать внимание на следующие этапы:
- Оптимизировать TTFB, время до первого байта. Если у вас нет CDN, а у пользователя слабая сеть, то на TTFB может уходить около 2.5 секунд (на исследованных сайтах), а это очень много.
- Сделать так, чтобы важный ресурс запрашивался заранее. Подсказать браузеру через <link rel="preload">, например. И пока парсер реально дойдёт до картинки в коде и дождётся выполнения всех синхронных JS-операций, за это время часть полезной работы уже будет проделана.
- Исследовать задержки рендеринга. Возможно, где-то у вас есть кусок JS, который тормозит запрос за картинкой или отрисовку во вьюпорте. Этот совет в том числе и другие метрики улучшит.

Больше полезных чисел — по ссылке.

https://web.dev/blog/common-misconceptions-lcp

Есть ли будущее у Node.js? / Андрей Мелихов и Кирилл Мокевнин

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

https://youtu.be/98qu3CqRNb8

Базовые комбинации клавиш для ссылок с фокусом

Эрик Бейли столкнулся с необходимостью создания синтетических ссылок: ведут себя как нативные ссылки, но нативными ссылками не являются. И много усилий потратил на то, чтобы исследовать, как реагируют сфокусированные ссылки на разные комбинации клавиш: Shift + Enter, Function + Enter, Control + Enter, Option + Enter, Alt + Enter, Command + Enter.

Важные выводы:
- Cmd и Ctrl — не одно и то же. Alt и Option — тоже. Потому что разные операционные системы воспринимают их по-разному, чаще игнорируя кнопки от конкурирующих производителей. В коде их нужно разделять.
- На мобильных ОС браузеры верят в существование клавиатур, поэтому поддерживают сокращения тоже. На мобилке можно подключать внешнюю клавиатуру.
- Такие сокращения — важные пользовательские привычки. Поэтому если уж делаете синтетические ссылки, постарайтесь не сломать нативное поведение.
- Нативное поведение проще всего реализовать, используя нативные элементы.

https://ericwbailey.website/published/basic-keyboard-shortcut-support-for-focused-links/

Как быстро конвертировать Chrome-расширение в Safari-расширение

Нина Торгунакова показывает, как из готового расширения для Chrome реализовать расширение для Safari. Про подготовку расширения для Chrome было здесь. Большую часть работы берёт на себя встроенный в XCode конвертер, но так как Safari не умеет многих вещей, которые работают в расширениях для Chrome, местами нужно пописать код на Swift.

Бонусом есть инструкция, как подготовить расширение для публикации в App Store.

https://evilmartians.com/chronicles/how-to-quickly-and-weightlessly-convert-chrome-extensions-to-safari

Пробелы в HTML сломаны

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

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

А ещё при помощи CSS можно сделать так, чтобы пробелы начали либо учитываться все сразу, либо только переносы строк, либо ещё как-то.

Чтобы банально не пересказывать статью, просто советую её прочитать, там хорошие примеры на разобраться.

Дуглас подсветил интересную проблему. По сути у нас сейчас нет способа задать неубираемый пробел явно спецсимволом. Мы можем задать между словами обычный пробел — но его судьба очень шаткая, сильно зависит от того, блочный или инлайновый контекст, что написано в CSS, есть ли вокруг флекс-контейнер и так далее. У нас есть неразрывный пробел &nbsp, который одновременно не даёт пробел убрать (потому что это особенный пробел), но при этом ещё и не даёт разделить слова между собой. Но если мы хотим дать возможность переносить слова, но не давать их слепить браузеру, когда перенос не нужен — такого символа нет. При этом в статье есть примеры вроде CMS и прочих мест, где такие пробелы вставить иногда нужно.

Ещё одна интересная мысль: prettier и прочие форматтеры могут ломать вёрстку. Просто потому, что наличие или отсутствие пробела — это не прихоть для форматирования кода, а вполне себе необходимость для корректной вёрстки. У prettier есть настройка для уважительного отношения к пробелам от автора, но по умолчанию она включена в нестрогий режим, а силу дефолта не стоит недооценивать. Теперь хоть буду понимать, почему иногда ломается вёрстка, а не просто убирать пробел и радоваться, что каким-то чудом заработало.

В конце автор предлагает совсем уж безумную идею: переписать формат HTML, чтобы как в языках программирования появилась сущность «строка», то есть использовать тройные кавычки или ещё какие-то отделители от другой разметки, которые бы давали парсеру понять, что эту строку надо обрабатывать по-особенному. Но тут я немножко выпал в осадок, идея кажется слишком безумной, чтобы когда-нибудь такое появилось в реальности. Но кто знает. У нас же не просто так существует doctype у документов, теоретически такой режим возможен.

https://blog.dwac.dev/posts/html-whitespace/

Насколько мой фронтенд плох?

Видео выходного дня. Семён Левенсон объясняет разницу между рефакторингом и реинжинирингом, предлагает плохометры для оценки качества кодовой базы (на основе идеи Ильи Климова) и показывает несколько примеров, как такие плохометры автоматически собирать.

https://youtube.com/watch?v=T43jrG1ewTc

CLI для caniuse

Брамус собрал консольную утилиту, чтобы смотреть на данные caniuse прямо из терминала. Причём можно ещё и подключить автодополнение для bash/zsh/fish.

Поигрался — выглядит интересно. Если надо быстро посмотреть поддержку, без деталей, то экономит время. Но полноценной заменой caniuse, конечно, эта утилита не станет. Уж слишком я люблю с фильтрами разными на сайте играться. И не всегда помню правильное название CSS-фичи, ищу по ключевым словами, а утилита от Брамуса не всегда понимает, что я от неё хочу.

https://github.com/bramus/caniuse-cli

Состояние ES5 в вебе

Филип Уолтон ещё в 2017 году показал технику, которая позволяет для старых браузеров загружать отдельный транспилированный в ES5 код, а для современных — свежий модный ES6. В этом году он решил проверить, используют ли популярные библиотеки до сих пор ES5 как дефолт, когда как будто в этом уже нет нужды.

- Babel превращает строчку console.log([1, 2, 3].at(-1)) в 11217 байт кода, используя при этом 71 зависимость.
- Из популярных современных бандлеров только Babel и TypeScript используют транспиляцию в ES5 по умолчанию. Остальные сборщики всё-таки опираются на «современные браузеры».
- Популярные библиотеки тоже постепенно переходят на подход с современным синтаксисом в коде по умолчанию, без поставки ES5-версии. Хотя React и Lodash всё ещё содержат только ES5-код при подключении как зависимость.
- При этом Филип проанализировал топ популярных сайтов через HTTP Archive и обнаружил, что 89% сайтов подключают хотя бы один файл, где есть ES6+ фича без транспиляции. То есть в старых браузерах всё равно что-то сломается.
- То, во что превращается исходный код, должен решать пользователь, а не библиотека. Если мне зачем-то всё ещё нужно превращать мой код в ES5-бандл, я могу настроить сборку сам.
- На сборщик надейся, а сам тестируй. Какая бы сборка у вас ни была, собирайте клиентские ошибки, тестируйте приложения в популярных браузерах, не бойтесь автотестов с настроенными браузерными фермами.

https://philipwalton.com/articles/the-state-of-es5-on-the-web/

display: contents

Очередной подробный гайд от Ахмада Шадида по тому, как пользоваться некоторыми особенностями CSS. На этот раз про свойство display: contents.

Напомню, display: contents — это указание браузеру вынести элемент выше по дереву для учёта в потоке. Самый частый пример, который приводят, это списки. Например, если нужно поднять элементы списка выше в дереве, чтобы они с другими элементами лежали в одном флекс-контейнере.

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

Важно, display: contents может ломать доступность в списках, таблицах и прочих значимых для скринридеров элементах. Так что применяйте осторожно.

https://ishadeed.com/article/display-contents/

TypeScript 5.6

Очередные приятные новинки. Почитал релиз-ноуты, нашёл для себя много поводов обновиться.

1. Проверки на nullish и truthy. Грубо говоря, в TS завезли аналог проверки no-constant-binary-expression из ESLint, хотя это не совсем так. Представьте, что вы где-то опечатались и внутри if написали код, который всегда true. Линтеры умеют такое подсвечивать, теперь умеет и TypeScript. За исключением явного задания if (true), потому что такое вы скорее всего пишете осознанно, например, для дебага или вебпака.

2. Методы Iterator Helper. В ECMAScript на 3-м уровне пропозала появились методы map, filter, reduce, take и другие для итераторов. TypeScript готовится к ним заранее. Не только поддержали новые методы, но и добавили новые встроенные типы IteratorObject и AsyncIteratorObject, которые позволят типизировать то, с чем работает итератор.

3. Строгая проверка итераторов `--strictBuiltinIteratorReturn`. Раньше было сложно определить, что вернёт итератор, поэтому по сути TS работал с типом any, а это убивает сам смысл типизации. В строгом режиме проверок теперь TS умеет определять типы умнее и начнёт выдавать полезные ошибки в случае неправильного использования результатов итераторов.

4. Поддержка Arbitrary Module Identifiers. В JavaScript можно сначала в модуле написать export { banana as "🍌" };, а потом в месте подключения модуля написать import { "🍌" as banana } from "./foo" — и это будет работать. Я не очень понимаю, для чего это нужно, кроме как для каких-то специфических способов именовать методы вроде MyLib::MyMethod, для совместимости по имени с бекендом, например. Но теперь в TS это поддержали, можно давать странные имена импортируемым сущностям.

5. Опция `--noUncheckedSideEffectImports`. Раньше TS мог игнорировать файлы, которые подключаются через import "some-module";, но не существуют. Такие подключения как раз называют импортами сайд-эффектов, потому что обычно оно нужно, чтобы выполнить какой-то код внутри модуля, но не импортировать ничего именованного. И так часто подключают CSS-файлы внутри компонентов. С включённой опцией TS теперь начнёт ругаться, если файл найти не может. Выключить конкретные маски можно, в статье есть пример.

6. Опция компилятора `--noCheck`. Убирает ненужные проверки типов для вывода новых файлов. По сути если у вас так настроен запуск tsc, что какие-то файлы с типами не нужны, то их и не будет проверять, экономя время. То есть если вы хотите просто быстро сгенерировать JS, не проверяя типы — осторожно, но можно.

7. `--build` без учёта ошибок зависимостей. Раньше если при билде TS находил ошибку типов в зависимостях, то падал и не давал сборке продолжаться. Теперь он постарается завершить сборку любой ценой, но начнёт всегда создавать файл .tsbuildinfo, куда будет писать информацию об ошибках. Чтобы вернуть старое поведение, нужно добавить в запуск опцию --stopOnBuildErrors.

8. Для быстрой работы в редакторах кода добавили языковому сервису TS возможность анализировать не весь файл целиком, а его видимые регионы. При редактировании огромных файлов сервису на каждый ввод символа нужно быстро реагировать, но это не всегда возможно, если анализировать весь файл сразу. По тестам над файлом checker.ts из самого TS время анализа первого региона из файла стало 143ms, а раньше полная диагностика файла занимала 3330ms.

9. Починили поведение `override`. Теперь проверки стали строже, требуют наличие перезаписываемого метода в базовом классе.

https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-6/

State of HTML 2024

Ещё один опрос про состояние веба, на этот раз про HTML. Можете повлиять на то, какие новые возможности работы с элементами появятся в будущем. И заодно узнать про те, что уже есть — вопросы составлены таким образом, что можно чему-то научиться в процессе.

Набрал 340 баллов. Из 49 фичей, упомянутых в опросе, применял на практике 25, слышал о 18. Не зря в подкасте смотрим в релиз-ноуты браузеров, мало какая новинка прошла мимо.

https://survey.devographics.com/en-US/survey/state-of-html/2024

Текстовые альтернативы для эмодзи в скринридерах

Наткнулся на старую заметку Стива Фолкнера про то, как звучат в скринридерах эмодзи. Забавно, что одни и те же эмодзи где-то smiling (улыбающийся), где-то grinning (ухмыляющийся), а где-то beaming (сияющий). То есть визуально это одно и то же, но если интерфейс слушать — это разные смыслы.

Мораль: подбирайте эмодзи аккуратно, чтобы нечаянно не ухмыльнуться вместо доброй улыбки 🙂

https://html5accessibility.com/stuff/2022/01/17/short-note-on-emoji-text-alternative-variations/

ts-blank-space

Появляется всё больше способов собирать из TypeScript исполняемый JavaScript. Компания Bloomberg поделилась своим решением. Их компилятор ts-blank-space работает по принципу «заменить все лишние символы на пробелы». И это неплохо работает во многих случаях.

- По сути отстреливание типов — давно рабочий способ. Тот же Node.js научился недавно делать так же для TS-файлов, когда нужно запустить код.

- Замена всякого вспомогательного на пробелы — интересная идея, позволяющая избавиться от source map. Использование source map не бесплатное, при этом в случае ошибки всё ещё хочется посмотреть в исходный код. Позиции оригинальных символов при замене на пробелы не изменяются, профит.

- К сожалению, придётся отказаться от фичей TS, которые всё-таки влияют на рантайм: enum, namespace, module и парочки других.

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

- Подход настолько простой, что на их бенчмарке сборка быстрее tsc в 5.6 раз.

- Это опенсорс. Можете сами посмотреть, как оно под капотом устроено. И законтрибьютить, если захочется.

Попробовал у себя на двух проектах. На супер-простом серверном завелось всё без проблем. На большом проекте с легаси и tsx развалилось, конечно. Так что пробовать лучше на небольших проектах.

https://bloomberg.github.io/ts-blank-space/

Никита Дубко и Александра Шинкевич: Зачем разработчику выступать?

Видео выходного дня. Сходили с моим замечательным другом Сашей Шинкевич в гости в подкаст к Cloud.ru Tech. Делились мыслями про то, что такое личный бренд, стоит ли его развивать, для чего существуют конференции и нужно ли пробовать себя в роли спикера. Заодно про веб-технологии поговорили в общем и про «Веб-стандарты» как сообщество.

https://www.youtube.com/watch?v=0giBnxrTTGY

Улучшаем перфоманс рендеринга при помощи content-visibility

Нолан Лоусон делится интересным примером того, как одним осознанным применением полезного CSS-свойства можно принести много пользы.

Представьте, что у вас есть библиотека, которая помогает работать с тысячами различных картинок. У Нолана это веб-компонент emoji-picker-element, который как в Slack умеет в кастомные эмодзи. Если в такой компонент добавить 20000 эмодзи, то по сути это необходимость отрендерить не меньше 20000 DOM-элементов. Если же для каждого эмодзи нужно несколько DOM-элементов, простым умножением приходим в ужас.

Чтобы не писать свой виртуальный список, Нолан пошёл на следующие ухищрения:
1. Добавил для каждого списка эмодзи content-visibility: auto; и contain-intrinsic-size, который считался на основании количества эмодзи в списке. Такими командами вы разрешаете браузеру не рендерить контент, чтобы экономить время. Этим приёмом получилось ускориться уже на 15%.
2. Свёл количество DOM-элементов до минимального, то есть на один эмодзи — один элемент. Для этого саму картинку перенёс в background-image. Это не сломало a11y, так как оставшийся элемент всё ещё содержал всё необходимое.
3. Написал свой простой аналог loading=lazy для картинок на основе IntersectionObserver, чтобы избавиться от ненужных запросов за этими самыми картинками. В итоге получил общий прирост производительности от 35% в Firefox до 40% в Chrome.

Заодно из статьи я узнал, что существует ивент с именем contentvisibilityautostatechange. Это не кот по клавиатуре прогулялся, а специальный ивент для отслеживания изменения content-visibility: auto.

https://nolanlawson.com/2024/09/18/improving-rendering-performance-with-css-content-visibility/

Работа с буфером обмена при помощи JavaScript

Короткий цикл статей Реймонда Кэмдена про то, как работать с буфером обмена в веб-приложениях. Когда-то у нас для таких целей был Flash, но сейчас его в браузере так просто не запустишь, даже если очень надо.

Реймонд рассказывает про Clipboard API, как с его помощью читать HTML-код, как обрабатывать бинарные файлы (например, картинки) и что там с безопасностью вообще. Понравился пример, как можно скопировать в буфер обмена урл и сразу же записать в буфер QR-код с этим урлом.

Про чтение: https://frontendmasters.com/blog/reading-from-the-clipboard-in-javanoscript/
Про запись: https://frontendmasters.com/blog/writing-to-the-clipboard-in-javanoscript/