🎲 Нативный рандом в CSS — зачем он вообще?

В CSS появляются random() и random-item() — новые функции из CSS Values and Units Module Level 5.

Альваро Монторо разбирает, как это работает:
• random() — возвращает случайное значение в заданном диапазоне (можно указать шаг).
• random-item() — выбирает случайное значение из списка.
Можно «синхронизировать» результат между свойствами и элементами через shared-параметры.

width: random(100px, 500px);
rotate: random(-5deg, 5deg);
color: random-item(red, blue, green);

Пока это скорее эксперимент — частичная поддержка есть только в Safari 26.2.

🤔 Зачем это нужно?
На первый взгляд — странная идея: зачем рандом в CSS, если есть JS?

Но кейсы есть:
• Декоративный разброс карточек или элементов.
• Лёгкая «органичность» интерфейса (микро-rotate, вариативные отступы).
• Генеративные эффекты без JS.
• Визуальные вариации на уровне CSS, без дополнительной логики.
• Разнообразие в skeleton/shimmer-эффектах.

По сути CSS начинает заходить на территорию вариативности и генеративного UI.
Пока рано для продакшена, но направление очень любопытное.

Читать

Подписывайтесь на мой Telegram канал

CodePen 2.0

Команда CodePen представила бета-версию редактора. Под капотом — полный переписанный движок и много новых возможностей, но при этом редактор остался таким же лёгким и быстрым, сохранив главную фишку CodePen — мгновенный предпросмотр. ⚡️

Что нового:

📁 Файловая система — теперь в пенах есть файлы и папки, можно строить более сложную структуру проекта, а не ограничиваться только HTML/CSS/JS.

🧩 Кастомные дефолты — можно создать свой шаблон, чтобы новые пены запускались сразу с нужным стеком и настройками.

🧱 Blocks — новая система сборки. Blocks — это модули, которые обрабатывают код: например Sass, Babel, PostCSS, Prettier и т.д. Их можно комбинировать между собой, а CodePen сам собирает конфиг и следит, чтобы всё работало вместе.

⚙️ Простая конфигурация — у каждого блока есть свой конфиг (например tsconfig или настройки Prettier), а управлять ими можно через визуальный редактор.

🤝 Realtime-коллаборация — можно приглашать других разработчиков и работать над пеном вместе, как в Google Docs.

⌘ Omnibar — командная палитра для быстрого поиска файлов, настроек и команд.

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

Похоже, CodePen постепенно превращается из простого playground’а в полноценное лёгкое dev-окружение для фронтенда.

А каким инструментом вы пользуетесь, когда нужно быстро открыть песочницу?

codepen.io/beta

Подписывайтесь на мой Telegram канал

Оптимизация SVG: меньше вес, меньше DOM, быстрее рендер

Джоан Леон разобрал, как правильно оптимизировать SVG на практике — от базовой чистки файла до оптимизации повторяющихся иконок. Статья хороша тем, что показывает не только инструменты, но и где именно теряется производительность.

Вот несколько полезных инсайтов 👇

⚙️ Начните с чистки SVG
Экспорт из Figma/Illustrator почти всегда содержит мусор: metadata, комментарии, лишние g, inline-стили и т.д.

Инструменты вроде SVGO удаляют это автоматически и часто уменьшают файл на 30–70%.

🧹 Упростите path
Дизайнерские тулзы генерируют слишком сложные path.
Иногда один и тот же shape можно описать гораздо проще — это уменьшает размер SVG и ускоряет парсинг.

📦 Используйте SVG symbols для повторяющихся иконок
Если одна и та же иконка вставлена на странице десятки раз, браузер создаёт отдельный DOM для каждой.
Лучше вынести её в <symbol> и переиспользовать через <use>:

<svg>
  <use href="#icon-check"></use>
</svg>

Это сильно сокращает DOM и экономит память.

🎨 Удаляйте inline-стили
Многие SVG приходят с кучей style="fill:#000" и подобного.
Чаще всего это лучше вынести в CSS — файл станет меньше и иконки будет проще переиспользовать.

🚫 Не злоупотребляйте SVG
Иногда обычный img или даже CSS-shape будет проще и быстрее. SVG хорош для иконок, иллюстраций и векторной графики, но не всегда лучший выбор.

💡 Главная мысль статьи:
SVG часто считают «бесплатным» форматом, но при большом количестве иконок он может заметно раздувать DOM и влиять на производительность.

Читать

Подписывайтесь на мой Telegram канал

Visually hidden — всё о самом древнем «костыле» веба

Веб-разработчики годами копируют один и тот же сниппет .visually-hidden (или .sr-only), чтобы скрыть контент визуально, но оставить его доступным для скринридеров. Дэйв Бушелл разобрался, почему этот «магический» класс выглядит именно так и зачем там столько странных свойств.

Главная идея: display:none и visibility:hidden полностью удаляют элемент из accessibility tree. Скринридеры просто не узнают, что этот контент существует. А иногда нужно наоборот — скрыть текст от глаз, но оставить его для assistive-технологий.

Типичные кейсы:
– подписи к иконкам-кнопкам
– ссылки Skip to content
– дополнительный контекст для ссылок вроде "Read more"

Поэтому появился паттерн вроде такого:

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
}

Каждая строчка здесь появилась не случайно. Например: position:absolute — убирает элемент из потока; 1px вместо 0, потому что нулевые размеры могут ломать фокус в некоторых браузерах; overflow:hidden + clip-path — визуально «обрезают» содержимое.

В итоге .visually-hidden — это маленькая утилита, которая на самом деле является компромиссом из десятков лет браузерных багов, особенностей скринридеров и требований accessibility.

🤔 Будет ли нативное решение?
Идея отдельного нативного механизма для "visually hidden but accessible" обсуждается уже давно. Но пока браузеры не спешат внедрять специальное свойство или атрибут.
Во-первых, существующий паттерн уже стабильно работает.
Во-вторых, поведение таких элементов сильно зависит от скринридеров и других assistive-технологий, поэтому стандартизировать его не так просто.

Пока что .visually-hidden остаётся де-факто стандартом, даже спустя почти 20 лет.

Почитать разбор целиком

Подписывайтесь на мой Telegram канал

Vite 8

Команда Vite выпустила Vite 8 — и это один из самых крупных апдейтов инструмента за последние годы. Главная новость: Vite теперь работает на Rolldown, новом бандлере на Rust.

Раньше под капотом использовалась комбинация esbuild (dev) и Rollup (prod). Теперь всё объединено в один пайплайн, что упрощает архитектуру и убирает расхождения между dev и production сборкой.

Что нового в Vite 8:
⚡️ Rolldown по умолчанию — Rust-бандлер, который по скорости сопоставим с esbuild и может быть x10–30 быстрее Rollup на прод-сборке.
🧩 Единый тулчейн — Vite теперь часть связки Vite → Rolldown → Oxc (компилятор). Это позволяет глубже оптимизировать пайплайн и быстрее внедрять новые фичи JavaScript.
🛠 Встроенные DevTools — можно включить vite devtools прямо в dev-сервере для анализа проекта и дебага.
📦 tsconfig paths из коробки — алиасы TypeScript можно включить одной опцией (resolve.tsconfigPaths).

🧪 Новые возможности платформы:
— поддержка emitDecoratorMetadata без плагинов
— SSR-поддержка для .wasm?init
— проксирование console из браузера в терминал dev-сервера.

Отдельно обновился @vitejs/plugin-react v6 — теперь React Refresh работает через Oxc, а Babel больше не является зависимостью.

Интересно, что команда уже экспериментирует с Full Bundle Mode — режимом, где dev-сервер будет бандлить модули как в проде. В прототипах это даёт до x3 быстрее старт сервера и меньше сетевых запросов.

💭 Если коротко: Vite постепенно превращается из «удобного dev-сервера» в полноценный Rust-базированный тулчейн для фронтенда.

Читать анонс

Подписывайтесь на мой Telegram канал

Вы не знаете HTML-таблицы

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

Автор разбирает таблицы гораздо глубже обычных туториалов:

Терминология таблиц — как правильно мыслить в терминах row groups, header cells и структуры данных, а не просто <tr> и <td>
Table Object Model — малоиспользуемый DOM-API для работы с таблицами (rows, cells, section APIs)
Семантика заголовков — когда достаточно scope, а когда нужно связывать ячейки через headers
Правильная структура — зачем разделять таблицу на <thead>, <tbody> и <tfoot> и как это влияет на доступность
Практические паттерны — JS-хелперы и приёмы для сложных таблиц

Главная мысль: таблицы — это не просто «сетка для данных», а полноценная семантическая модель, которую скринридеры и браузеры умеют интерпретировать гораздо глубже, чем мы обычно предполагаем.

Если вы когда-нибудь делали сложные таблицы (финансовые, аналитические, с многоуровневыми заголовками), статья отлично показывает, какой потенциал у HTML-таблиц на самом деле.

Читать

Подписывайтесь на мой Telegram канал

Серия видео про микрофронтенды

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

Если интересует тема — рекомендую посмотреть плейлист 👇

Микрофронтенды — это базовый минимум
Независимый хостинг, Cache-Control, mf-manifest.json
Строим первое приложение с нуля

Весь плейлист здесь (пополняется)

Подписывайтесь на мой Telegram канал

Bippy — React DevTools для взрослых 😈

Bippy — это тулкит, который притворяется React DevTools и через __REACT_DEVTOOLS_GLOBAL_HOOK__ перехватывает события рендера, позволяя работать с fiber напрямую.
Проще говоря — это способ «залезть внутрь React» без форка React и без хаков в коде приложения.

Что умеет:
🧠 доступ к fiber tree (props, state, context компонентов)
🎣 хуки на события рендера (onCommitFiberRoot и др.)
🌳 обход дерева fibers удобными утилитами (traverseFiber, traverseRenderedFibers)

🔥 Самое интересное
Ты можешь перехватывать каждый commit React и проходиться по fiber-дереву, получая полный снапшот приложения:
какие компоненты есть, какие у них props/state, что реально перерендерилось.
То есть это уровень ниже любых devtools — фактически свой runtime-инспектор React.

Когда это нужно
🛠 Если делаешь инструменты
Например, тот же react-scan построен поверх Bippy.
Если хочешь писать свои devtools, анализаторы рендеров или runtime-инспекции — это база.
🔬 Исследования и сложные кейсы
Когда нужно понять, как реально работает React под капотом, или достать данные, которые обычным способом недоступны.

⚠️ Но есть нюанс
Это прямой хак в React internals, которые могут меняться в любой момент. Авторы сами предупреждают, что это может ломать приложения и не подходит для продакшена.

Если ты не уверен, зачем тебе это — скорее всего, тебе это не нужно. 😄

Подробности

Подписывайтесь на мой Telegram канал

Тебе не нужен data-testid для тестирования

Dominik Dorfmeister в своей статье разбирает, почему атрибут data-testid — это признак плохого accessibility и проблем с интерфейсом.

Главная мысль: если для теста тебе нужен testid, значит элемент сложно найти так, как это делает пользователь. А пользователь (и скринридер) ориентируется не на data-testid, а на роли, текст и доступные имена.

👉 Вместо этого автор предлагает:

• искать элементы по роли (getByRole)
• использовать доступные имена (aria-label, текст)
• строить UI так, чтобы он был понятен не только глазу, но и ассистивным технологиям

data-testid — не зло само по себе. Но его частое использование — это симптом:
либо плохой семантики, либо неудобного UI.

💡 Хороший тест = почти как пользовательский сценарий
Если тест читается как «найди кнопку с текстом Submit» — ты на правильном пути.

Читать

Подписывайтесь на мой Telegram канал

Называйте свои эффекты

Небольшая, но очень полезная мысль из статьи: эффекты в React стоит называть как обычные функции.
Автор предлагает смотреть на useEffect не как на «магический хук», а как на именованное действие. То есть выносить логику и давать ей осмысленное имя:

useEffect(function openSocket() {
  // создаем web socket
}, [deps])

вместо:

useEffect(() => {
  // какая-то магия 🪄
}, [deps])

Почему это важно:
👀 код становится более читаемым
🧠 проще понять, что именно делает эффект
🔁 легче переиспользовать и тестировать
🐞 в стектрейсах видно имя функции, а не анонимный коллбек

По сути, это маленький шаг от «анонимных сайд-эффектов» к более декларативному коду.
Иногда такие мелкие практики дают больше, чем очередной новый хук.

Читать

Подписывайтесь на мой Telegram канал

🧠 В браузеры добавили AI.css

Новый стандарт, который «дописывает» стили за тебя 👀

Типа такого:

.card {
  layout: auto;
  spacing: comfortable;
}

И браузер сам решает: grid это, flex или вообще что-то третье.

Работа с текстом:

.article {
  typography: readable;
}

Под капотом он настраивает line-height, max-width, размеры шрифта — как будто ты реально подумал об этом заранее.

Адаптив:

.container {
  adapt: fluid;
}

Без медиа-запросов, просто «сделай нормально на всех экранах».

Цвета:

.button {
  color-scheme: accessible primary;
}

И тебе сразу контраст, hover-состояния и нормальная читаемость.

Самое опасное:

.form {
  ux: good;
}

После этого форма внезапно становится удобной, валидирует поля как надо и не бесит пользователей.

Скоро добавят "performance: fast", чтобы сайт сразу грузился быстро, даже если ты не старался 😏

🚨 Axios взломали

В npm-пакет Axios попал вредоносный код — классическая supply chain атака.

📦 Заражённые версии:
— 1.14.1
— 0.30.4

⏱️ Они прожили всего ~2–3 часа, но этого хватило, чтобы попасть в CI/CD и прод.
Если ты сделал npm install в 00:21 – 03:15 по UTC, то твое окружение считается скомпрометированным.

🧩 Внутри был не сам код axios, а «левая» зависимость plain-crypto-js, которая через postinstall ставила троян.

🛠 Что делать:

— проверить lockfile на axios@1.14.1 или 0.30.4
— если были → считать окружение скомпрометированным (локалка/CI)
— удалить node_modules + lockfile и пересобрать проект
— срочно ротировать ВСЕ секреты (npm, GitHub, AWS, env и т.д.)
— проверить CI/CD (если там был install в это время)
— зафиксировать версии на безопасные (1.14.0 / 0.30.3)
— использовать строго зафиксированные версии зависимостей (без плавающих диапазонов)

💡 И да — про зависимости

Мы часто тащим библиотеки просто по привычке, хотя:
— HTTP → уже есть fetch
— базовые вещи пишутся за пару минут
— веб-стандарты давно закрывают кучу кейсов

Каждая зависимость — это:
— ⚠️ потенциальная точка атаки
— 📦 чужой код в твоём проде
— 🔗 риск supply chain атак, как эта

Иногда дешевле написать своё, чем потом разгребать последствия.

Подробнее

Подписывайтесь на мой Telegram канал

Pretext — layout текста без браузера 🤯

Cheng Lou сделал deps-free библиотеку для мультистрочного измерения текста и его layout’а без участия браузера.

Что это даёт?

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

Работает с любыми языками, шрифтами и даже эмодзи 👍
И главное — все расчёты происходят в JS, без DOM, а значит без любимых браузером reflow при каждом измерении.

💡 Что можно сделать

— Идеальные chat bubbles под конкретный текст, без лишнего воздуха.
Пример.

— Обтекание текста вокруг динамических объектов. Пример. (отдельно стоит отметить перфоманс — ~19ms на текст из 500 слов)

— Рендер текста в Canvas, SVG и даже на сервере.

Выглядит нишево, но на самом деле это про контроль:
ты сам управляешь layout’ом текста, а не браузер за тебя.

Репозиторий
Демки

Подписывайтесь на мой Telegram канал

Наткнулся на прикольную игру — CSS or BS

Суть простая: тебе показывают «CSS-свойство», а ты должен угадать — это реально существует или это полная дичь.

И вот тут начинаешь понимать, что в CSS за последние годы появилось СТОЛЬКО всего, что уже реально сложно отличить правду от выдумки 😄

Короче, отличный способ проверить, насколько ты вообще в теме современного CSS.

Скидывайте свои результаты в комменты 👇

Играть

Подписывайтесь на мой Telegram канал

Субботнее чтиво ☕️
Как одна инженерная команда протащила фичу в веб-стандарт

Squarespace и веб-стандарты: история о том, как ребята добавили loading="lazy" для <video> и <audio> в HTML.

В статье Squarespace инженер Скотт Джел рассказывает весь путь:
— от идеи и первых обсуждений
— до работы с WHATWG
— написания Web Platform Tests
— и коллаборации с командами Mozilla, Apple и Chromium

📅 В итоге — фича стала частью стандарта 23 марта 2026.

Почему это интересно:
— хороший пример, как реально появляются веб-стандарты (а не «где-то там решили»)
— много про процесс: обсуждения, компромиссы, тесты
— и немного про perf, который мы в итоге получаем «бесплатно»

💡 Ну и да — lazy loading теперь не только для <img> и <iframe>

Если хочется лёгкого, но полезного чтения про внутреннюю кухню веба — очень рекомендую 👇

Читать

Подписывайтесь на мой Telegram канал

Cloudflare представили «убийцу» WordPress ⚡️

Команда Cloudflare снова напрягла своих AI-агентов — и за ~2 месяца собрала новый проект, нацеленный сместить WordPress с пьедестала самой популярной CMS. Встречайте — EmDash.

Что внутри:

— TypeScript
— Serverless-архитектура
— Изолированные плагины на хуках → меньше рисков безопасности (в отличие от WordPress, где плагины — частый источник уязвимостей)
— Фронт на Astro — один из лучших вариантов для content-driven сайтов

Проект полностью open-source и уже доступен на GitHub.

WordPress во многом стал таким популярным именно из-за своей безумной гибкости — из него можно собрать что угодно (вспоминаем WooCommerce).

Вопрос: сможет ли EmDash с новым подходом дать такую же гибкость?

С одной стороны — строгая архитектура и изоляция.
С другой — TypeScript, open-source и явный упор на AI-агентов, которым дали весь тулчейн для расширения системы.

Посмотрим, что из этого вырастет 👀

Читать анонс
GitHub

Подписывайтесь на мой Telegram канал

Великое расширение CSS 🚀

Павел Лаптев разобрал, как новые возможности CSS постепенно заменяют JavaScript-библиотеки.

В статье — прямые сравнения: что раньше делали через JS, теперь можно реализовать нативно. Причём без костылей и с нормальной читаемостью кода.

📦 Итог на практике:
– минус ~300 KB бандла
– лучше Core Web Vitals
– меньше зависимостей и боли с ними

Главная мысль: CSS уже давно не «про стили», а про полноценную логику интерфейса.

Если вам не критична поддержка старых браузеров — отличный повод пересмотреть стек и повыкидывать лишние библиотеки 💡

Читать

Подписывайтесь на мой Telegram канал

Легкая библиотека для создания веб-компонентов ⚡️

Ариэль Салминен представляет Elena — open-source библиотеку для создания веб-компонентов, которые сначала работают на чистом HTML и CSS, а затем гидратация с JavaScript'ом.

Elena пытается решить типичные боли веб-компонентов: сдвиги layout’а, флешинга, проблемы с доступностью и сложности с SSR.
При этом вес — всего ~2.6 кб.

Основные фичи:
🧩 Progressive enhancement из коробки — сначала HTML/CSS, потом JS
⚡️ Минимальный runtime (~2.6 кб)
💤 Ленивая гидратация (можно контролировать, когда компонент «оживает»)
🖥 SSR-friendly — корректно работает с серверным рендерингом
🎯 Фокус на доступности (a11y)
🧱 Чистые Web Components без обвязки фреймворками

Веб-компоненты становятся всё привлекательнее: порог входа снижается, старые проблемы постепенно решаются.

А у вас был опыт построения приложений полностью на веб-компонентах? Как ощущения после React/Vue — норм или боль?

Читать пост
Сайт

Подписывайтесь на мой Telegram канал

…продолжаем про веб-компоненты

Как MDN Web Docs переехал с React на Lit

В прошлом году наш любимый портал MDN полностью переписал фронтенд на веб-компоненты.
В статье Leo McArdle подробно рассказывает о проделанной работе.

Что в итоге получили:
⚡️ Среда разработки стартует за ~2 секунды вместо ~2 минут
📦 Меньше зависимостей — отказ от тяжелого React-стека
🧩 Переход на нативные веб-компоненты через Lit
🚀 Упростили сборку и дев-сервер (меньше магии, быстрее дебаг)
🧼 Чище архитектура — компоненты ближе к платформе
🔁 Проще переиспользование компонентов между проектами
📉 Снижение сложности поддержки и обновлений
🌍 Улучшения в производительности и загрузке страниц

Читать

Подписывайтесь на мой Telegram канал