CPUpro

Давно пользуюсь JsonDiscovery для анализа JSON. Рома Дворнов в принципе если что-то выпускает в паблик, то оно классное. Если ещё не пробовали — вот.

Сегодня Рома написал про ещё один инструмент, на этот раз для профилирования. Думаю, вы не раз видели огромные флеймчарты во вкладе Performance в DevTools. И я тоже сталикивался с тем, что для сложных приложений, где очень много библиотек, функции вызываются на rAF, подписки всякие на события, вкладка Performance сильно виснет.

В релизе 0.5.0 инструмента CPUpro упор сделан на перформанс. По сути это как вкладка Performance, больше подходящая для анализа больших файлов с информацией о профилировании. Есть разбиение по модулям, пакетам, функциям и категориям. Есть удобная фильтрация на регулярных выражениях.

Попробовал на profile-файлах для клиентских приложений и Node.js. Для серверного подходит лучше, очень много ценной информации о том, какие пакеты медленные, какие больше всего при обработке запросов крутят CPU. Удобство как раз в группировке, которой нет в обычной вкладке Performance. Для клиентских интересно было посмотреть, как браузерные расширения тормозят страницу и как часто срабатывает Garbage Collector. И всё это работает очень шустро (вижу под капотом куски Json Discovery, который очень хорош для обработки больших файлов).

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

https://github.com/lahmatiy/cpupro/releases/tag/v0.5.0

Прокачка навыков TypeScript

С интересом наблюдаю, как развивается система типов в TypeScript. Уже и строковые шаблоны подвезли, и дополнительные встроенные типы.

Но не всегда понятно, как на практике проверить, что я правильно понял написанное в Release Notes. А тут наткнулся на интересный сервис, где много задачек на TypeScript, разбиты они на категории и по сложности. И в декабре, оказывается, был свой Advent of TypeScript. Залип в этот адвент и не отлипал, пока всё не прошёл. Точнее, два задания я честно своровал из уже готовых решений, но по крайней мере разобрался в них. Валидация судоку на типах — это небольшой разрыв мозга, но смог сам.

Кстати, решая задачи, можно на практике убедиться, что TypeScript настолько Тьюринг-полный, что позволяет производить сложные вычисления только на типах. Когда смог написать конвертер из бинарной записи в десятичную — был доволен собой. Понятно, что вряд ли мне пригодятся задачи из адвента в работе. Но теперь сложные типы во всяких библиотеках, которые сами парсят роутинг в приложении, читаются гораздо проще.

https://typehero.dev/

Наложение градиента поверх элемента

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

Не задумывался, но для этого же можно использовать border-image. По сути в него можно поместить градиент, который заполняет весь элемент. И он всё ещё будет под текстом, потому что так работает рендеринг.

.overlay {
  border-image: fill 0 linear-gradient(#0003, #000);
}

Попробую в нескольких местах отказаться от псевдоэлементов с аболютным позицинированием и игрой в z-index. Такой приём выглядит сильно проще.

https://frontendmasters.com/blog/quick-trick-using-border-image-to-apply-and-overlay-gradient/

Ещё один дашборд про веб-фичи

На Google I/O показали новый дашборд про то, какие фичи уже реализованы в браузерах. В отличие от caniuse там есть показатели прохождения Web Platform Tests (причём более удобно, чем это сделано на WPT, имхо), плюс можно посмотреть привязку фичи к Baseline.

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

https://webstatus.dev/

Новости фронтенда на канале Виталия Зюзина

Не только меня же читать. К тому же я знаю, многие ко мне в канал пришли после поста Виталия про папку с интересными фронтендерскими каналами.

Виталий каждую неделю собирает большой список интересностей, каждый раз нахожу для себя что-то интересное. Не реклама, просто советую 🙂

https://news.1rj.ru/str/web_platform/111

Заметка о подсвеченном тексте

В CSS уже довольно много способов выделить на странице что-то, с чем взаимодействует пользователь. Выделенный текст? Держи ::selection. Грамматическая ошибка? На тебе ::grammar-error. Поиск по странице? Пока нет, но скоро будет ::search-text.

Адриан Розелли напоминает, что любые выделения на странице должны соответствовать критериям доступности. Контраст фона выделения и фона под ним — 3:1. Контраст текста поверх фона выделения — 4.5:1.

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

https://adrianroselli.com/2024/05/a-brief-note-on-highlighted-text.html

Minimum Lovable Product

Не так давно София Валитова показала мне парочку интересных статей про такой термин, как MLP — Minimum Lovable Product. Скорее всего вы слышали про Minimum Viable Product (MVP). «Ребята, у нас дедлайны, давайте сейчас MVP, потом нормально сделаем».

MVP — это минимально необходимое, чтобы выжить. MLP — это минимально необходимое, чтобы продукт полюбили.

В чём отличия MLP от MVP:

- MVP мы делаем, чтобы проверить гипотезу. Мы ещё плохо понимаем рынок, но хотим собрать что-то, чем пользователи хоть кое-как, но будут пользоваться. MLP же подразумевает, что мы сразу делаем то, что люди полюбят, то есть вполне себе изучаем рынок и пользователей заранее.

- MVP можно делать тогда, когда вы первые. Дешёвых файлохранилищ ещё нет, а вы Dropbox. Или вы придумали такой алгоритм сжатия данных, который лучше всех в мире, и маркетинг ему как будто не очень нужен, а инвесторы — нужны (кто понял отсылку, тот понял). MLP же чаще всего делают тогда, когда рынок уже заполнен альтернативами, и чтобы вам выделиться, надо сделать что-то «вау».

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

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

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

Мы как раз сейчас делаем один такой сервис, который вроде как технический, но так хочется сделать его живым и душевным 🙂

https://www.aha.io/roadmapping/guide/plans/what-is-a-minimum-lovable-product

@starting-style и transition-behavior для анимаций появления

Вот оно, применение новых фичей в CSS в комбинации, которая как будто много кому будет полезна. Идём по шагам:

1. Новое правило @starting-style. Описывает стили, которые у элементов устанавливаются в тот момент, когда их ещё нет, но как только они появятся, с них стартует анимация. Например, при вставке в DOM нового узла.

2. transition-behavior: allow-discrete говорит браузеру «анимировать» дискретные значения типа display: none. То есть изменение таких свойств произойдёт не мгновенно на первый же кадр анимации, а через transition-duration.

3. Применяем это на относительно свежий dialog и вполне себе свежий popover. Играем с opacity, scale и display (раз он у нас теперь отложенный).

4. Посыпаем сверху @media (prefers-reduced-motion: no-preference), не забываем о доступности.

На выходе получаем классные анимации появления модалок, всплывашек и, при желании, чего угодно, что появляется из ниоткуда (`display: none`, в смысле). Причём если раньше у вас этого просто не было, то добавив такое прогрессивным улучшением у пользователя по сути вы ничего не ломаете.

Адам Аргайл объясняет каждый шаг и показывает на примере, как оно может работать.

https://nerdy.dev/using-starting-style-and-transition-behavior-for-enter-and-exit-stage-effects

BlurHash

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

BlurHash интересен тем, что по сути строка L6PZfSi_.AyE_3t7t7R**0o#DgR4 — это полноценная картинка. На сервере при сборке или загрузке картинки в ваше файлохранилище нужно запустить ecnode, который эту строку выдаст. А на клиенте нужно вызвать функцию decode, которая эту строку превратит в то самое цветное пятно, похожее на картинку.

Из минусов — это canvas. Подменять canvas на картинку тяжелее, чем просто внутри img подменить src. И для отрисовки этого canvas на клиент надо затащить тот самый скрипт, который превратит набор символов в картинку-пятно. То есть для статических сайтов и отрисовки LCP я бы это точно не использовал. И ещё нужно точно знать размеры картинок, что не всегда возможно.

Но если у вас SPA, которое пользователь крайне редко закрывает, при этом перемещается по страницам с картинками постоянно, то один раз в начале загрузить библиотеку (и закэшировать при помощи service worker) — и вот уже приятная экономия на скорости загрузки данных.

Как сайд-эффект — такие пятна можно использовать, чтобы прятать нежелательный контент за клик. Для интриги или для соблюдения законодательства.

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

https://blurha.sh/

Cycle Time, Feature Time, Lead Time. Радуем пользователей быстрее при помощи графиков

На недавней Podlodka TeamLead Crew делился своим опытом, как искать бутылочные горлышки в процессах. Уже много лет разбираюсь в Cycle Time команд и стараюсь сделать так, чтобы пользователи новые фичи получали быстрее, качество при этом не проседало, а команда разработки не занималась скучным и приводящим к выгоранию. И всё по одним и тем же графикам Cycle Time.

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

https://youtu.be/_5ibUw93kEo

Современный гайд по CSS-фигурам

Колоссальное. Темани Афиф давно делится демками и статьями, как при помощи CSS рисовать всякое интересное. Бывает же такое, что нам надо сверстать что-нибудь «эдакое». Хочется, но сложно и не можется.

В сборнике есть и clip-path, и разные сочетания background-image, и математика, и маски, и другие техники. Всё адаптивное и кастомизируемое. Сохранил себе в закладки, если вдруг надо будет верстать, чтобы просто копировать в проект.

https://www.smashingmagazine.com/2024/05/modern-guide-making-css-shapes/

Рандомный совет по CSS

Ещё один проект Темани Афиф. Переходите по ссылке (именно по ней, там редирект на конкретную статью) — получаете полезный рецепт. Пока все, что я накликал, были интересные.

https://random.css-tip.com/

Из ESLint и Prettier в Biome

Недавно у себя в бложике перебрался на Biome. Собственно, для этого бложик и держу как пет-проект, чтобы в нём играться с разными интересными технологиями.

Китти Жирадель делится своим опытом переезда на Biome в проекте побольше моего бложика. Из интересного:
- Есть команда biome check, которая пройдётся по вашей кодовой базе и даст советы, что делать с ошибками. Попробовал на большом проекте — понравилось то, что сообщения об ошибках по-настоящему информативны, а не просто «ой, что-то упало».
- Китти всё ещё не хватает некоторой функциональности. Biome не умеет в GraphQL, иногда ломает код при банальной сортировке импортов, нет многих плагинов.
- Чего я не знал, так это про опцию --staged, которая позволяет избавиться от husky и прочих отдельных пакетов. Не хватает качественной работы с CSS, чтобы совсем отказаться от инструментов для pre-commit.

Слышал мнения, что Biome скорее всего долго не протянет, но мне пока нравится, буду играться с ним дальше.

https://kittygiraudel.com/2024/06/01/from-eslint-and-prettier-to-biome/

Тестирование типов TypeScript

Иногда проекты дорастают до такого уровня, что нужно проверять сами типы. Например, у вас в разных местах приложения есть типы, которые должны быть почти одинаковые, но одно приходит из бекенда и генерируется на основе какого-то контракта, а второе давно написали на клиенте, чтобы привязать к React. В такие моменты иногда возникает желание написать тесты на типы.

Адам Ракис из Spotify показывает по шагам, как написать тип TypesMatch<A, B>, который вернёт true, если типы и правда совпадают. Итоговый вариант выглядит просто, но интересно почитать, как к нему Адам приходит. А затем этот специальный тип можно использовать для тестирования существующих типов, банально запуская tsc на файлике с «тестами».

Знаю, что есть уже готовые библиотеки, который решают ровно такую задачу. В том же typehero.dev они активно используются. Но всегда интересно разобраться, как эти библиотеки под капотом устроены.

https://frontendmasters.com/blog/testing-types-in-typenoscript/

Как подсидеть тимлида

Видео выходного дня. Старенький, но всё ещё актуальный доклад Егора Толстого. Если вы уже тимлид или собираетесь им стать, помните:

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

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

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

- Если кажется, что вы ничего полезного не делаете («раньше вот код писал, а теперь просто по встречкам хожу»), то во-первых, вы не одиноки, а во-вторых, начните вести дневник выполненных дел. Я, например, уже 5 лет веду вики-страничку «Дневник доброжелюбного бородача», в которую записываю всякую важную активность: что делал, что улучшил, какой процесс запустил. Очень помогает приглушить синдром самозванца.

В докладе есть ещё несколько дельных советов, рекомендую.

https://youtu.be/aJv6uQMChm0

Что нового в браузерах за месяц

Ох, как же мне теперь удобно станет статистику для докладов собирать!

Патрик Броссет собрал страничку, которая берёт данные из пакета web-features (большой сборник веб-фич), склеивает это с browser-compat-data и раз в сутки самообновляется. В итоге можно не просто смотреть, какие фичи есть в браузерах, а отслеживать, что появляется в каждом отдельном браузере каждый месяц. Эдакий общий сборник релизов. Очень удобно.

Например, с мая text-wrap: balance работает во всех свежих версиях Interop-браузеров. А с апреля везде есть popover.

https://web-platform-dx.github.io/web-features-explorer/monthly/

CSS anchor positioning API

С нетерпением жду, когда все браузеры поддержат CSS Anchor Positioning. С ним ведь можно будет отказаться от отдельных библиотек для тултипов во многих случаях, всё на CSS — мечта.

Юна Кравец показывает и рассказывает, как работать с «якорями», какие новые свойства, директивы и функции появились в CSS. Поиграться можно уже в Chrome 125.

Статья с подробностями: https://developer.chrome.com/blog/anchor-positioning-api
Демка: https://anchor-tool.com/

Что не так с Emoji

Видео выходного дня.

В 2017 году Лёша Авдеев на конференции Web Standards Days в Минске рассказывал о том, как работают эмодзи в браузерах и операционных системах (да, именно с того дня я называю эмоджи эмодзи). Лёша показал, как собираются эмодзи из нескольких в один, какие шрифты отвечают за их отрисовку, как их обрабатывать при помощи JavaScript и почему соц. сети в итоге рисуют картинки, а не используют шрифты.

Думаете, что-то изменилось за 6.5 лет?

https://youtu.be/DUwZpLBSuiI

Единица измерения `cap`

Ахмад Шадид столкнулся с задачей, когда нужно между словами добавить расстрояние, равное высоте прописной буквы. И обычно такое решается подбором пикселей или em, если знаешь метрики шрифта. Особо искушённые пользователи CSS могут прикрутить ex. Но на самом деле современные версии браузеров умеют в единицу измерения cap, которая равна той самой высоте прописной буквы. Браузер ведь и так знает метрики шрифта, а значит может и эту высоту передать в CSS.

В статье есть хороший пример, когда нужно сделать блок высотой с текст без отступов. Для такой задачи cap подходит как нельзя лучше.

https://ishadeed.com/article/css-cap-unit/

<dialog> с заблокированным скроллом

Скорее всего у вас была похожая задачка: при показе всплывающего окна сделать так, чтобы за ним не скроллился контент. Обычно для такого при открытии модалки при помощи JavaScript на body добавляют overflow: hidden. Но у такого подхода есть пара недостатков:
- Нужен JavaScript там, где он как будто не должен быть.
- Контент за модалкой начинает прыгать, потому что скроллбар убирается, а это влияет на ширину страницы.

Крис Койер делится простым рецептом, как на современном CSS эти недостатки убираются:
- Вместо JavaScript можно использовать body:has(dialog[open]). Если модалки сделаны при помощи dialog, то такого селектора достаточно.
- На html можно добавить scrollbar-gutter: stable;, чтобы при открытии модалки скроллбар прятался из-за overflow: hidden, но место под него оставалось. То есть контент прыгать не будет.

https://frontendmasters.com/blog/scroll-locked-dialogs/

TypeScript 5.5

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

1. Inferred Type Predicates. TypeScript становится всё умнее и учится понимать из контекста, с какими типами мы работаем. Например,

const definedEntities = entities
    .map(e => allEntities.get(e))
    .filter(e => e !== undefined);

definedEntities.forEach(e => e.doSomething());

Раньше такой код выдавал бы '' is possibly 'undefined'. Сейчас TS понимает, что выше по коду все undefined уже ушли. Можно будет убрать столько as из кода!

2. Проверка синтаксиса регулярных выражений. И на опечатки укажет, и подсветит, когда с именованными группами вы работаете не так, как надо. Экономия времени полезная получится.

3. Поддержка новых методов Set из EcmaScript. Там добавили всякие пересечения, исключения и прочие полезные операции не так давно. Теперь оно и в TS будет валидно обрабатываться.

4. Новый флаг --isolatedDeclarations, который будет приучать вас более явно задавать типы для экспортируемых сущностей. Особенно полезно, если вы генерируете .d.ts для ваших библиотек.

5. В конфиге теперь можно пользоваться переменной ${configDir}, чтобы ссылаться на папку, в которой конфиг находится. Если у вас разные конфиги в разных папках, проще будет эти самые папки перемещать по проекту.

6. Сам пакет TypeScript «схуднул» на 30%. CI/CD станут быстрее.

7. Больше нельзя написать type undefined = any;. Честно говоря, не знал, что раньше было можно, как-то не было необходимости такие подлянки в проекты вставлять. Но теперь совсем нельзя.

И ещё всякое разное. Скидывайте команде, чтобы был повод завести тикет на обновление TS в проекте.

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