Улучшаем кэширование в браузере с помощью No-Vary-Search 🚀
Каждый фронтендер знает боль: вы идеально настроили
Решать это на стороне CDN или через Service Worker можно, но долго и костыльно. Наконец-то в веб-стандартах появилось нативное решение проблемы — заголовок ответа
💡 Что это такое?
Это HTTP-заголовок ответа, который явно говорит браузеру (и другим кэшам): «Эй, вот эти параметры в URL никак не влияют на контент страницы. Игнорируй их при поиске в кэше».
Если пользователь зашёл на
🛠 Как это пишется? (Примеры)
Заголовок использует синтаксис Structured Fields и даёт гибкий контроль:
1️⃣ Игнорировать только конкретные параметры (самый частый кейс):
Контент по ссылкам с этими метками склеится в один кэш-слот, но если изменится условный
2️⃣ Игнорировать вообще все параметры:
3️⃣ Игнорировать всё, КРОМЕ важных параметров:
Удобно, если параметров много, но на рендеринг влияют только ID товара и пагинация.
4️⃣ Игнорировать порядок параметров:
Если бэкенду всё равно, в каком порядке идут query-параметры (
🚦 Статус в стандартах и поддержка
На текущий момент (середина 2026 года) спецификация IETF находится в статусе черновика (Draft), а сам заголовок считается экспериментальным.
Chromium-браузеры (Chrome, Edge, Opera): Уже имеют отличную поддержку. Они используют
Safari и Firefox: Пока отстают, но фича активно обсуждается в контексте Interop.
⚠️ Небольшой подвох при дебаге: Если вы внедрите этот заголовок на проде, старый добрый трюк для сброса кэша вида
Внедрять можно уже сейчас как progressive enhancement — Chromium-пользователи получат мгновенный буст к скорости, а остальные просто пойдут по старому пути.
А как вы сейчас боретесь с фрагментацией кэша из-за трекеров? Вырезаете метки через Service Worker, настраиваете правила на Cloudflare/Nginx или пока просто смирились? 👇
Читать статью
Подписывайтесь на мой Telegram канал
Каждый фронтендер знает боль: вы идеально настроили
Cache-Control, но прилетает маркетолог, добавляет к ссылке кучу UTM-меток или fbclid, и браузер считает этот URL совершенно новым ресурсом. Кэш сгорает, страница грузится дольше, а на сервере множатся одинаковые записи.Решать это на стороне CDN или через Service Worker можно, но долго и костыльно. Наконец-то в веб-стандартах появилось нативное решение проблемы — заголовок ответа
No-Vary-Search.💡 Что это такое?
Это HTTP-заголовок ответа, который явно говорит браузеру (и другим кэшам): «Эй, вот эти параметры в URL никак не влияют на контент страницы. Игнорируй их при поиске в кэше».
Если пользователь зашёл на
site.com/page?utm_source=tg, браузер сохранит её. Когда в следующий раз пользователь перейдёт по ссылке site.com/page?utm_source=email, браузер не пойдёт в сеть, а моментально отдаст страницу из локального кэша, потому что контент идентичен.🛠 Как это пишется? (Примеры)
Заголовок использует синтаксис Structured Fields и даёт гибкий контроль:
1️⃣ Игнорировать только конкретные параметры (самый частый кейс):
No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign" "fbclid")Контент по ссылкам с этими метками склеится в один кэш-слот, но если изменится условный
?product_id=123, кэш разделится.2️⃣ Игнорировать вообще все параметры:
No-Vary-Search: params
3️⃣ Игнорировать всё, КРОМЕ важных параметров:
No-Vary-Search: params, except=("id" "page")Удобно, если параметров много, но на рендеринг влияют только ID товара и пагинация.
4️⃣ Игнорировать порядок параметров:
No-Vary-Search: key-order
Если бэкенду всё равно, в каком порядке идут query-параметры (
?a=1&b=2 или ?b=2&a=1), этот флаг спасёт от лишних cache miss.🚦 Статус в стандартах и поддержка
На текущий момент (середина 2026 года) спецификация IETF находится в статусе черновика (Draft), а сам заголовок считается экспериментальным.
Chromium-браузеры (Chrome, Edge, Opera): Уже имеют отличную поддержку. Они используют
No-Vary-Search не только для стандартного дискового кэша, но и для Speculation Rules API (парсят заголовок, чтобы переиспользовать уже предзагруженные (prefetiched/prerendered) страницы, даже если параметры не совпали).Safari и Firefox: Пока отстают, но фича активно обсуждается в контексте Interop.
⚠️ Небольшой подвох при дебаге: Если вы внедрите этот заголовок на проде, старый добрый трюк для сброса кэша вида
site.com/script.js?v=random_string перестанет работать, если этот параметр попадет под правило игнорирования. Будьте аккуратны.Внедрять можно уже сейчас как progressive enhancement — Chromium-пользователи получат мгновенный буст к скорости, а остальные просто пойдут по старому пути.
А как вы сейчас боретесь с фрагментацией кэша из-за трекеров? Вырезаете метки через Service Worker, настраиваете правила на Cloudflare/Nginx или пока просто смирились? 👇
Читать статью
Подписывайтесь на мой Telegram канал
Встроенный в браузер HTML Sanitizer API: прощай, DOMPurify? 🛡
Все мы когда-то рендерили пользовательский контент через
В блоге Ахмада Алфи вышел отличный разбор нового HTML Sanitizer API, который наконец-то переносит задачу санитизации на уровень самого браузера.
Главное из статьи:
— Два семейства методов: Безопасные (
— Safe by default:
— Unsafe-методы как escape hatch:
— Идеальные юзкейсы: Optimistic UI (безопасно рендерим коммент на клиенте сразу, пока ждем ответ сервера), очистка грязного HTML при вставке (например, из Word) и превью Markdown.
— Бэкенд всё еще важен: Клиентский Sanitizer API — это про UX и моментальную защиту в браузере. Базовую очистку данных на бэкенде никто не отменял.
Что по поддержке?
В феврале 2026 года Firefox 148 первым выкатил стабильную реализацию. Chrome пока прячет фичу за флагом, а Safari только высказал позитивное отношение без активной разработки. Пока API не станет Baseline, используем подход с feature detection и оставляем DOMPurify как фоллбэк.
Читать статью
Подписывайтесь на мой Telegram канал
Как думаете, когда сможем полностью выпилить DOMPurify из продакшена? Или хвост старых браузеров не отпустит нас еще лет пять? 👇
Все мы когда-то рендерили пользовательский контент через
innerHTML и боролись с XSS-уязвимостями. Де-факто стандартом для очистки HTML всегда был DOMPurify. Инструмент отличный, но он тащит в бандл ~23 КБ кода и вынужден дублировать работу браузера по парсингу, постоянно догоняя новые фичи веб-платформы.В блоге Ахмада Алфи вышел отличный разбор нового HTML Sanitizer API, который наконец-то переносит задачу санитизации на уровень самого браузера.
Главное из статьи:
— Два семейства методов: Безопасные (
setHTML, parseHTML) и небезопасные (setHTMLUnsafe, parseHTMLUnsafe).— Safe by default:
setHTML() работает максимально жестко. Он вырежет любые опасные теги и on* атрибуты, даже если вы попытаетесь явно разрешить их через конфиг-объект. — Unsafe-методы как escape hatch:
setHTMLUnsafe() пригодится, если вам нужно прокинуть Declarative Shadow DOM, или вы полностью отдаете себе отчет, зачем осознанно разрешаете инлайн-скрипты.— Идеальные юзкейсы: Optimistic UI (безопасно рендерим коммент на клиенте сразу, пока ждем ответ сервера), очистка грязного HTML при вставке (например, из Word) и превью Markdown.
— Бэкенд всё еще важен: Клиентский Sanitizer API — это про UX и моментальную защиту в браузере. Базовую очистку данных на бэкенде никто не отменял.
Что по поддержке?
В феврале 2026 года Firefox 148 первым выкатил стабильную реализацию. Chrome пока прячет фичу за флагом, а Safari только высказал позитивное отношение без активной разработки. Пока API не станет Baseline, используем подход с feature detection и оставляем DOMPurify как фоллбэк.
Читать статью
Подписывайтесь на мой Telegram канал
Как думаете, когда сможем полностью выпилить DOMPurify из продакшена? Или хвост старых браузеров не отпустит нас еще лет пять? 👇
Жидкое стекло в вебе: Canvas, WebGPU и никакого CSS-blur 💧
Вышла крайне любопытная библиотека liquid-dom, которая позволяет создавать честный эффект жидкого стекла (Liquid Glass) прямо поверх вашей разметки.
Это не просто хитрый
Технология пока экспериментальная, API может меняться, а для полноценного продакшена время ещё не пришло. Но как демонстрация того, на что способны современные графические API в браузере — это восторг.
Исходники на GitHub
Позалипать в демки
Подписывайтесь на мой Telegram канал
Как вам такой UI-тренд? Нашли бы применение такой тяжелой графике в реальных проектах (например, на промо-страницах) или CSS-размытия пока более чем достаточно? 👇
Вышла крайне любопытная библиотека liquid-dom, которая позволяет создавать честный эффект жидкого стекла (Liquid Glass) прямо поверх вашей разметки.
Это не просто хитрый
backdrop-filter: blur() в CSS, а полноценная симуляция жидкости. Библиотека считывает HTML-структуру страницы, переносит её в Canvas и использует WebGPU/WebGL для рендеринга физически корректных преломлений, бликов и капель в реальном времени.Технология пока экспериментальная, API может меняться, а для полноценного продакшена время ещё не пришло. Но как демонстрация того, на что способны современные графические API в браузере — это восторг.
Исходники на GitHub
Позалипать в демки
Подписывайтесь на мой Telegram канал
Как вам такой UI-тренд? Нашли бы применение такой тяжелой графике в реальных проектах (например, на промо-страницах) или CSS-размытия пока более чем достаточно? 👇
Стартовал опрос State of CSS 2026 🎨
Это реальная возможность напрямую повлиять на развитие веба. Вендоры браузеров внимательно изучают эти результаты, когда планируют приоритеты по внедрению новых фич и стандартов. Чем больше разработчиков проголосует, тем релевантнее будет вектор развития спецификаций.
Полезный побочный эффект: Пока заполняешь анкету, гарантированно наткнешься на новые для себя свойства и селекторы, о которых даже не слышал. Отличный способ нахвататься нового и закинуть себе в закладки «почитать на досуге».
Пройти опрос
Подписывайтесь на мой Telegram канал
Это реальная возможность напрямую повлиять на развитие веба. Вендоры браузеров внимательно изучают эти результаты, когда планируют приоритеты по внедрению новых фич и стандартов. Чем больше разработчиков проголосует, тем релевантнее будет вектор развития спецификаций.
Полезный побочный эффект: Пока заполняешь анкету, гарантированно наткнешься на новые для себя свойства и селекторы, о которых даже не слышал. Отличный способ нахвататься нового и закинуть себе в закладки «почитать на досуге».
Пройти опрос
Подписывайтесь на мой Telegram канал
Декларативный точечный апдейт страниц: прощай, тяжелый JS для стриминга? ⚡️
На майском Google I/O 2026 команда Chrome презентовала крутую штуку, которая прямо сейчас закладывается в стандарты HTML — Declarative Partial Updates. Фича уже доступна для тестов в Chrome 148.
Суть проблемы: классический HTML-стриминг всегда был строго линейным. Браузер парсит документ сверху вниз по мере загрузки байтов. Если у вас на странице есть «тяжелый» блок (например, блок рекомендаций, требующий долгого запроса к БД), серверу приходилось либо придерживать весь стрим, либо разработчики городили костыли на JS, догружая куски через AJAX/Fetch и руками вставляя их в DOM.
Новое API решает это на уровне самого браузера с помощью Out-of-order HTML streaming (нелинейного стриминга).
Как это работает?
В то место, где контент появится позже, вставляется специальная процессинговая инструкция-маркер:
Браузер спокойно рендерит всю остальную страницу, отдавая пользователю быстрый First Paint. Когда сервер наконец-то посчитал тяжелые данные, он докидывает в этот же поток обычный тег
Браузер на лету подхватывает этот шаблон и декларативно, вообще без участия JavaScript, «впиливает» его контент ровно на место маркера
Что еще завезли в этот пак?
Помимо стриминга из коробки, обновили и JS-методы для вставки HTML. Вместо старого и небезопасного
Зачем это нужно?
1. Архитектура Islands (Острова): Привет Astro и аналогам. Теперь статические «острова» и динамические блоки можно собирать и обновлять силами самого HTML-парсера.
2. Отказ от лишнего JS: Больше не нужно тащить клиентские скрипты только ради того, чтобы поймать чанк с сервера и сделать
3. Перформанс: Меньше нагрузка на процессор, так как парсинг и вставка происходят на самом низком уровне движка браузера.
Пока инициатива обкатывается в Chromium, на npm уже вовсю пилят официальные полифиллы (
Как вам идея внедрения
Читать пост
Подписывайтесь на мой Telegram канал
На майском Google I/O 2026 команда Chrome презентовала крутую штуку, которая прямо сейчас закладывается в стандарты HTML — Declarative Partial Updates. Фича уже доступна для тестов в Chrome 148.
Суть проблемы: классический HTML-стриминг всегда был строго линейным. Браузер парсит документ сверху вниз по мере загрузки байтов. Если у вас на странице есть «тяжелый» блок (например, блок рекомендаций, требующий долгого запроса к БД), серверу приходилось либо придерживать весь стрим, либо разработчики городили костыли на JS, догружая куски через AJAX/Fetch и руками вставляя их в DOM.
Новое API решает это на уровне самого браузера с помощью Out-of-order HTML streaming (нелинейного стриминга).
Как это работает?
В то место, где контент появится позже, вставляется специальная процессинговая инструкция-маркер:
<div>
<? marker name="deferred-box" ?>
</div>
Браузер спокойно рендерит всю остальную страницу, отдавая пользователю быстрый First Paint. Когда сервер наконец-то посчитал тяжелые данные, он докидывает в этот же поток обычный тег
<template> с указанием таргета:<template for="deferred-box">
<div class="heavy-widget">Тут лежат данные из БД!</div>
</template>
Браузер на лету подхватывает этот шаблон и декларативно, вообще без участия JavaScript, «впиливает» его контент ровно на место маркера
deferred-box.Что еще завезли в этот пак?
Помимо стриминга из коробки, обновили и JS-методы для вставки HTML. Вместо старого и небезопасного
innerHTML появился расширенный набор статических и стриминговых API: setHTML(), setHTMLUnsafe(), а также совершенно новые методы вроде streamHTMLUnsafe() и appendHTML(). Они позволяют реализовать SPA-подобные точечные обновления страниц (в стиле HTMX), скармливая браузеру куски HTML-потоков прямо через встроенные веб-трансляции (Streams API).Зачем это нужно?
1. Архитектура Islands (Острова): Привет Astro и аналогам. Теперь статические «острова» и динамические блоки можно собирать и обновлять силами самого HTML-парсера.
2. Отказ от лишнего JS: Больше не нужно тащить клиентские скрипты только ради того, чтобы поймать чанк с сервера и сделать
appendChild.3. Перформанс: Меньше нагрузка на процессор, так как парсинг и вставка происходят на самом низком уровне движка браузера.
Пока инициатива обкатывается в Chromium, на npm уже вовсю пилят официальные полифиллы (
template-for-polyfill). Кажется, через пару лет концепция Server-Driven UI выйдет на абсолютно новый уровень.Как вам идея внедрения
<?таких_конструкций?> обратно в современный HTML? Не пахнет ли старым добрым PHP/BigPipe, но теперь на стероидах прямо в браузере? 👇Читать пост
Подписывайтесь на мой Telegram канал
Дискретный Fluid Sizing в CSS с функцией round() 📐
Все мы любим
Ахмад Шадид выпустил классный разбор того, как решить эту боль с помощью относительно свежей CSS-функции
Идея в том, чтобы обернуть
Выглядит это примерно так:
Что это дает на практике:
— Визуальное единообразие: Размеры текста и блоков округляются до понятных дизайн-системе шагов (например, строго кратны
— Идеальная синхронизация: Соседние элементы, зависящие от ширины экрана, будут перепрыгивать на новые брейкпоинты одновременно, исключая визуальный перекос «в процессе» резинового ресайза.
— Меньше работы для субпиксельного рендеринга: Никаких микро-размытий из-за дробных пикселей.
Если вы топите за идеальный UI и строгие сетки — этот трюк определенно стоит забрать в арсенал.
Читать
Подписывайтесь на мой Telegram канал
Все мы любим
clamp() за возможность делать плавный отзывчивый дизайн (fluid sizing) для шрифтов и отступов. Но у него есть минус: на промежуточных экранах браузер выдает хаотичные дробные значения вроде 23.419px. Это часто ломает строгую дизайн-систему, где все размеры должны быть кратны, например, 8 пикселям.Ахмад Шадид выпустил классный разбор того, как решить эту боль с помощью относительно свежей CSS-функции
round().Идея в том, чтобы обернуть
clamp() в round() и задать интервал дискретности. В итоге размеры меняются не линейно-размыто, а четкими шагами (ступенями).Выглядит это примерно так:
font-size: round(nearest, clamp(1rem, 5vw, 3rem), 4px);
Что это дает на практике:
— Визуальное единообразие: Размеры текста и блоков округляются до понятных дизайн-системе шагов (например, строго кратны
4px или 8px).— Идеальная синхронизация: Соседние элементы, зависящие от ширины экрана, будут перепрыгивать на новые брейкпоинты одновременно, исключая визуальный перекос «в процессе» резинового ресайза.
— Меньше работы для субпиксельного рендеринга: Никаких микро-размытий из-за дробных пикселей.
Если вы топите за идеальный UI и строгие сетки — этот трюк определенно стоит забрать в арсенал.
Читать
Подписывайтесь на мой Telegram канал
Deno обгоняет Bun в гонке за drop-in Node.js 🦕
Помните Deno? Это очередной «убийца Node.js», но со своим странным взглядом на мир. Так вот, недавно вышла версия 2.8, которая резко бустанула Node API compatibility и обошла Bun по этому показателю.
Если верить их бенчмаркам, они знатно прокачали скорость, но самое интересное — под капотом.
Из главного: во-первых, прощай дурацкий префикс
Во-вторых, наконец-то допилили криптографию
В-третьих, завезли команду
Также добавили ленивую загрузку ESM-модулей, поддержку
Короче, если хотите закопаться во все детали — велком в их официальный блог.
Похоже, ребята поняли, что воевать со всей экосистемой npm в лоб — суицид, и решили просто молча впитать её в себя.
Расскажите про ваше отношение к Deno. Пользовались? Нравится? Или до сих пор не понимаете, зачем он нужен, когда есть старая добрая Нода? 👇
Подписывайтесь на мой Telegram канал
Помните Deno? Это очередной «убийца Node.js», но со своим странным взглядом на мир. Так вот, недавно вышла версия 2.8, которая резко бустанула Node API compatibility и обошла Bun по этому показателю.
Если верить их бенчмаркам, они знатно прокачали скорость, но самое интересное — под капотом.
Из главного: во-первых, прощай дурацкий префикс
npm:, команды deno add и deno install теперь по умолчанию ищут всё в npm. Во-вторых, наконец-то допилили криптографию
node:crypto, из-за которой раньше ломалась половина библиотек. В-третьих, завезли команду
deno why для расковыривания дерева зависимостей и встроенный deno audit fix, который сам автоматически патчит уязвимые пакеты.Также добавили ленивую загрузку ESM-модулей, поддержку
.npmrc конфигов, сабкоманды deno clean и deno remove, ускорение TLS-соединений, deno transpile для очистки типов и пачку новых Node.js API.Короче, если хотите закопаться во все детали — велком в их официальный блог.
Похоже, ребята поняли, что воевать со всей экосистемой npm в лоб — суицид, и решили просто молча впитать её в себя.
Расскажите про ваше отношение к Deno. Пользовались? Нравится? Или до сих пор не понимаете, зачем он нужен, когда есть старая добрая Нода? 👇
Подписывайтесь на мой Telegram канал
Убийца Apple Silicon от Nvidia? Встречаем RTX Spark
Не совсем стандартный пост для моего канала, но пройти мимо этого анонса я просто не могу.
Nvidia официально представила RTX Spark — новое семейство ARM-чипов (SoC), созданных специально для «не-Apple» ноутбуков и мини-ПК. По сути, перед нами готовый рецепт «убийцы Mac»: энергоэффективность архитектуры ARM плюс фирменная супермощная графика от «зелёных». Если вы, как и я, не переносите экосистему Apple, но дико завидуете автономности и производительности их процессоров, то скоро этот расклад может полностью измениться.
Что по спекам: 20 ядер CPU, 6144 ядра при вычислительной мощности в 1 PFLOPS, 128 ГБ LPDDR5X.
Самое крутое — это автономность под нагрузкой. Nvidia заявляет, что на ультрабуке толщиной всего 14 мм, работающем от батареи, можно будет спокойно рендерить 3D-сцены объёмом до 90 ГБ, монтировать 12K-видео или на максималках гонять в Indiana Jones and the Great Circle в 1440p при 100 fps.
Звучит как полноценный гвоздь в крышку гроба классического x86 на лэптопах. Да и попыткам Qualcomm со своим Snapdragon X закрепиться в нише мощных рабочих станций теперь явно придётся несладко.
Первым коммерческим устройством на новом чипе станет Microsoft Surface Laptop Ultra, который должен выйти уже этой осенью. Теперь дело осталось за малым — чтобы Microsoft наконец-то до блеска отполировали Windows под ARM, иначе всё это железо так и останется потенциальным монстром на бумаге.
Для нас, как для разработчиков, это отличный знак. Больше ядер и мощный GPU на энергоэффективном чипе — это быстрая сборка тяжелых проектов, локальные нейронки для автокомплита без задержек и плавная работа интерфейсов без дикого воя кулеров.
Как думаете, взлетит? Сможет ли связка Windows + Nvidia ARM сокрушить монополию Apple в сегменте топ-ноутбуков для работы, или Microsoft снова всё закопает кривой эмуляцией софта? 👇
Читать анонс RTX Spark
Читать анонс Microsoft Surface Ultra
Подписывайтесь на мой Telegram канал
Не совсем стандартный пост для моего канала, но пройти мимо этого анонса я просто не могу.
Nvidia официально представила RTX Spark — новое семейство ARM-чипов (SoC), созданных специально для «не-Apple» ноутбуков и мини-ПК. По сути, перед нами готовый рецепт «убийцы Mac»: энергоэффективность архитектуры ARM плюс фирменная супермощная графика от «зелёных». Если вы, как и я, не переносите экосистему Apple, но дико завидуете автономности и производительности их процессоров, то скоро этот расклад может полностью измениться.
Что по спекам: 20 ядер CPU, 6144 ядра при вычислительной мощности в 1 PFLOPS, 128 ГБ LPDDR5X.
Самое крутое — это автономность под нагрузкой. Nvidia заявляет, что на ультрабуке толщиной всего 14 мм, работающем от батареи, можно будет спокойно рендерить 3D-сцены объёмом до 90 ГБ, монтировать 12K-видео или на максималках гонять в Indiana Jones and the Great Circle в 1440p при 100 fps.
Звучит как полноценный гвоздь в крышку гроба классического x86 на лэптопах. Да и попыткам Qualcomm со своим Snapdragon X закрепиться в нише мощных рабочих станций теперь явно придётся несладко.
Первым коммерческим устройством на новом чипе станет Microsoft Surface Laptop Ultra, который должен выйти уже этой осенью. Теперь дело осталось за малым — чтобы Microsoft наконец-то до блеска отполировали Windows под ARM, иначе всё это железо так и останется потенциальным монстром на бумаге.
Для нас, как для разработчиков, это отличный знак. Больше ядер и мощный GPU на энергоэффективном чипе — это быстрая сборка тяжелых проектов, локальные нейронки для автокомплита без задержек и плавная работа интерфейсов без дикого воя кулеров.
Как думаете, взлетит? Сможет ли связка Windows + Nvidia ARM сокрушить монополию Apple в сегменте топ-ноутбуков для работы, или Microsoft снова всё закопает кривой эмуляцией софта? 👇
Читать анонс RTX Spark
Читать анонс Microsoft Surface Ultra
Подписывайтесь на мой Telegram канал
Мы недостаточно молимся: CSS-фреймворк на эмодзи ☠️
Мало кто задумывается, но спецификация CSS позволяет использовать Emoji в качестве названий классов. С точки зрения спецификации и Unicode — это просто валидные текстовые символы. Раз это технически возможно, то появление чего-то подобного было лишь вопросом времени.
Встречайте BEMoji — полноценный CSS-фреймворк, построенный на эмодзи и методологии БЭМ (Блок-Элемент-Модификатор).
Чтобы вы понимали масштаб трагедии, вот как по задумке автора выглядит разметка стандартного компонента карточки:
И ладно бы это была просто минутная шутка. Автор подошел к делу со всей серьезностью: внутри есть дизайн-токены, утилитарные классы для отступов/цветов и даже полноценный тулинг (BEMoji CLI) для генерации стилей.
Читабельность кода, конечно, вышла из чата, а кодовая база превращается в древнеегипетские иероглифы. Но как концепт — это чистый восторг и разрыв шаблонов.
Посмотреть на это чудо
Подписывайтесь на мой Telegram канал
Мало кто задумывается, но спецификация CSS позволяет использовать Emoji в качестве названий классов. С точки зрения спецификации и Unicode — это просто валидные текстовые символы. Раз это технически возможно, то появление чего-то подобного было лишь вопросом времени.
Встречайте BEMoji — полноценный CSS-фреймворк, построенный на эмодзи и методологии БЭМ (Блок-Элемент-Модификатор).
Чтобы вы понимали масштаб трагедии, вот как по задумке автора выглядит разметка стандартного компонента карточки:
<article class="🃏">
<div class="🃏__🖼 🃏__🖼--🌟">
<img src="hero.jpg" alt="...">
</div>
<div class="🃏__📝">
<h2 class="🃏__🔠">Card Title</h2>
<p class="🃏__💬">Card description text</p>
</div>
<footer class="🃏__🦶">
<button class="🔘 🔘--🌟">Primary</button>
<button class="🔘 🔘--👻">Disabled</button>
</footer>
</article>
И ладно бы это была просто минутная шутка. Автор подошел к делу со всей серьезностью: внутри есть дизайн-токены, утилитарные классы для отступов/цветов и даже полноценный тулинг (BEMoji CLI) для генерации стилей.
Читабельность кода, конечно, вышла из чата, а кодовая база превращается в древнеегипетские иероглифы. Но как концепт — это чистый восторг и разрыв шаблонов.
Посмотреть на это чудо
Подписывайтесь на мой Telegram канал
Please open Telegram to view this post
VIEW IN TELEGRAM
Нативная стилизация зазоров (Gap Decorations) в CSS
Добавление разделительных линий между колонками или строками в Grid и Flexbox всегда было болью. Приходилось плодить грязный DOM (лишние
Спецификация Gap Decorations решает эту проблему нативно. Теперь браузер сам рассчитывает пустые пространства и рисует линии прямо внутри
Что для этого завезли:
—
—
—
—
🔥 Линейки являются полноценными CSS-свойствами, так что их можно спокойно анимировать через
Что по поддержке?
Спека активно продвигается CSSWG и уже обкатывается в Chromium (Chrome/Edge). До Baseline нужно подождать остальные вендоры.
Ссылка на разбор
Подписывайтесь на мой Telegram канал
Добавление разделительных линий между колонками или строками в Grid и Flexbox всегда было болью. Приходилось плодить грязный DOM (лишние
div), мучиться с псевдоэлементами ::before/::after или городить хаки с градиентами в background.Спецификация Gap Decorations решает эту проблему нативно. Теперь браузер сам рассчитывает пустые пространства и рисует линии прямо внутри
gap.Что для этого завезли:
—
column-rule и row-rule — задают толщину, стиль и цвет линий в зазорах лейаута.—
rule-break — настраивает поведение линий на пересечениях.—
rule-inset — сдвигает края линий внутрь зазора (больше никаких height: 80% через абсолютное позиционирование псевдоэлементов).—
rule-visibility-items — скрывает разделитель, если соседний элемент пуст или скрыт.🔥 Линейки являются полноценными CSS-свойствами, так что их можно спокойно анимировать через
transition или @keyframes.Что по поддержке?
Спека активно продвигается CSSWG и уже обкатывается в Chromium (Chrome/Edge). До Baseline нужно подождать остальные вендоры.
Ссылка на разбор
Подписывайтесь на мой Telegram канал
CSS-центрирование в 2026 году 🎯
Центрирование элементов в CSS — это уже классическая шутка в мире фронтенда. Кажется, сколько бы новых свойств ни завозили, каждый год обязательно выходит ультимативный гайд, собирающий все подходы в одном месте.
В блоге CSS-Tricks вышел свежий и очень детальный разбор от Темани Афифа. Автор раскладывает по полочкам современную теорию выравнивания и наглядно показывает, что и в каких ситуациях использовать.
Главное из статьи:
— Базовая теория: концепция двух уровней выравнивания (контейнер vs элементы) и двух осей. Помогает раз и навсегда понять ментальную модель CSS.
— Флексы, гриды или абсолют? Сравнение «лоб в лоб» для разных сценариев. Спойлер:
— Новое свойство
— Якорное позиционирование и
— Безопасное и небезопасное центрирование: разница между
Если хотите освежить базу и посмотреть, как современные спецификации превращают старые костыли в изящный код, статья обязательна к прочтению.
Читать
Подписывайтесь на мой Telegram канал
Центрирование элементов в CSS — это уже классическая шутка в мире фронтенда. Кажется, сколько бы новых свойств ни завозили, каждый год обязательно выходит ультимативный гайд, собирающий все подходы в одном месте.
В блоге CSS-Tricks вышел свежий и очень детальный разбор от Темани Афифа. Автор раскладывает по полочкам современную теорию выравнивания и наглядно показывает, что и в каких ситуациях использовать.
Главное из статьи:
— Базовая теория: концепция двух уровней выравнивания (контейнер vs элементы) и двух осей. Помогает раз и навсегда понять ментальную модель CSS.
— Флексы, гриды или абсолют? Сравнение «лоб в лоб» для разных сценариев. Спойлер:
place-content: center или margin: auto во флексах решают 90% задач, но везде есть свои подводные камни.— Новое свойство
text-box (бывшее text-box-trim): идеальный способ избавиться от нативных невидимых отступов вокруг текста, которые вечно ломают идеальное вертикальное центрирование «по пикселям».— Якорное позиционирование и
anchor-center: нативный способ центрировать всплывашки, тултипы и менюшки относительно элемента-донора без единой строчки на JavaScript.— Безопасное и небезопасное центрирование: разница между
align-content: center и align-content: safe center. Обязательно к изучению, чтобы контент внутри мелких контейнеров на мобилках переносился или скроллился, а не тупо обрезался за краями экрана.Если хотите освежить базу и посмотреть, как современные спецификации превращают старые костыли в изящный код, статья обязательна к прочтению.
Читать
Подписывайтесь на мой Telegram канал
VoidZero уходит под крыло Cloudflare. Что это значит для экосистемы? 🥺
Буквально вчера прогремела новость: стартап VoidZero (который Эван Ю основал в 2023 году для создания единого сверхбыстрого тулчейна для JS) официально переходит под крыло Cloudflare. Вместе с Эваном туда уходит и вся его команда.
Для тех, кто пропустил, к середине 2026 года ребята успели сделать титанический объём работы: довели до ума Vite 8 со встроенным по умолчанию Rust-бандлером Rolldown, выкатили невероятно быстрые линтер Oxlint и форматер Oxfmt (на базе движка Oxc), а также анонсировали Vite+. Но упёрлись в классическую стену опенсорса.
В чём реальная причина сделки?
Эван честно признаётся: они так и не смогли решить проблему монетизации.
— Изначально они пытались монетизировать Vite+, используя смешанную лицензию, но быстро поняли, что это ломает саму суть свободного софта.
— После этого Vite+ перевели на MIT, и команда начала пилить Void — нативную платформу для деплоя Vite-приложений.
— Но разработка облачной платформы и тулчейна для локальной разработки — это абсолютно разные сферы. Команде банально не хватало рук, а пилить облако в одиночку, пока венчурные деньги имеют свойство заканчиваться, — огромный риск.
Что изменится для нас?
На бумаге — только в лучшую сторону:
1) Все инструменты остаются бесплатными и под MIT-лицензией. Vite, Vitest, Rolldown, Oxc и Vite+ никуда не деваются. Эван Ю и команда продолжат рулить их разработкой, но теперь с бесконечными ресурсами и инфраструктурой Cloudflare.
2) Проект Void переезжает в экосистему Cloudflare. Связка Vite Environment API и воркеров Cloudflare станет ещё бесшовнее.
3) Новый вектор — AI-агенты. Эван упомянул, что сейчас огромная часть запусков их инструментов приходится на AI-код-генераторы. В рамках Cloudflare они планируют оптимизировать тулчейн так, чтобы нейронкам было проще и быстрее собирать и деплоить приложения.
По сути, мы видим логичный финал для амбициозного инфраструктурного стартапа. Монетизировать open-source тулчейн в JS-мире чертовски сложно, зато Cloudflare получает главный инструмент современности (у одного только Vite сейчас более 100 млн скачиваний в неделю) и намертво привязывает его к своей облачной платформе.
Как вам новость? Верите, что Cloudflare сохранит дух независимого опенсорса, или начнётся постепенное закручивание гаек в сторону вендор-лока? 👇
Читать пост
Подписывайтесь на мой Telegram канал
Буквально вчера прогремела новость: стартап VoidZero (который Эван Ю основал в 2023 году для создания единого сверхбыстрого тулчейна для JS) официально переходит под крыло Cloudflare. Вместе с Эваном туда уходит и вся его команда.
Для тех, кто пропустил, к середине 2026 года ребята успели сделать титанический объём работы: довели до ума Vite 8 со встроенным по умолчанию Rust-бандлером Rolldown, выкатили невероятно быстрые линтер Oxlint и форматер Oxfmt (на базе движка Oxc), а также анонсировали Vite+. Но упёрлись в классическую стену опенсорса.
В чём реальная причина сделки?
Эван честно признаётся: они так и не смогли решить проблему монетизации.
— Изначально они пытались монетизировать Vite+, используя смешанную лицензию, но быстро поняли, что это ломает саму суть свободного софта.
— После этого Vite+ перевели на MIT, и команда начала пилить Void — нативную платформу для деплоя Vite-приложений.
— Но разработка облачной платформы и тулчейна для локальной разработки — это абсолютно разные сферы. Команде банально не хватало рук, а пилить облако в одиночку, пока венчурные деньги имеют свойство заканчиваться, — огромный риск.
Что изменится для нас?
На бумаге — только в лучшую сторону:
1) Все инструменты остаются бесплатными и под MIT-лицензией. Vite, Vitest, Rolldown, Oxc и Vite+ никуда не деваются. Эван Ю и команда продолжат рулить их разработкой, но теперь с бесконечными ресурсами и инфраструктурой Cloudflare.
2) Проект Void переезжает в экосистему Cloudflare. Связка Vite Environment API и воркеров Cloudflare станет ещё бесшовнее.
3) Новый вектор — AI-агенты. Эван упомянул, что сейчас огромная часть запусков их инструментов приходится на AI-код-генераторы. В рамках Cloudflare они планируют оптимизировать тулчейн так, чтобы нейронкам было проще и быстрее собирать и деплоить приложения.
По сути, мы видим логичный финал для амбициозного инфраструктурного стартапа. Монетизировать open-source тулчейн в JS-мире чертовски сложно, зато Cloudflare получает главный инструмент современности (у одного только Vite сейчас более 100 млн скачиваний в неделю) и намертво привязывает его к своей облачной платформе.
Как вам новость? Верите, что Cloudflare сохранит дух независимого опенсорса, или начнётся постепенное закручивание гаек в сторону вендор-лока? 👇
Читать пост
Подписывайтесь на мой Telegram канал
Please open Telegram to view this post
VIEW IN TELEGRAM
Универсальная спецификация технического качества сайтов 🌐
Йост де Валк (создатель Yoast SEO) опубликовал инициативу Website Specification — открытый чек-лист технических возможностей и стандартов, которыми должен обладать любой качественный современный ресурс.
По сути, это попытка собрать разрозненные лучшие практики в единый понятный манифест.
Документ разбит на ключевые категории:
— Основы и семантика: валидный HTML5, корректное использование семантических тегов и кодировки.
— SEO и структурированные данные: разметка Schema.org, Open Graph, robots.txt и XML-карты.
— Доступность (a11y): соответствие стандартам WCAG, обязательные атрибуты alt для картинок, поддержка управления с клавиатуры.
— Безопасность: HTTPS, правильные заголовки Content Security Policy (CSP), защита от кликджекинга и XSS.
— Производительность: оптимизация под Core Web Vitals (LCP, INP, CLS), правильное кэширование и современный сжатый формат изображений.
— Интернационализация (i18n): корректные теги lang и атрибуты hreflang для мультиязычных ресурсов.
— Готовность к AI-агентам (LLM-ready): пожалуй, самый трендовый пункт. Спецификация рекомендует отдавать контент для нейросетевых ботов и агрегаторов в чистом виде через Markdown-эндпоинты, JSON-LD и RSS, а не заставлять их парсить тяжелый JS-винегрет.
Проект открытый, дополняется сообществом и отлично подходит в качестве готового ТЗ для аудита любого проекта.
Изучить документ
Подписывайтесь на мой Telegram канал
Йост де Валк (создатель Yoast SEO) опубликовал инициативу Website Specification — открытый чек-лист технических возможностей и стандартов, которыми должен обладать любой качественный современный ресурс.
По сути, это попытка собрать разрозненные лучшие практики в единый понятный манифест.
Документ разбит на ключевые категории:
— Основы и семантика: валидный HTML5, корректное использование семантических тегов и кодировки.
— SEO и структурированные данные: разметка Schema.org, Open Graph, robots.txt и XML-карты.
— Доступность (a11y): соответствие стандартам WCAG, обязательные атрибуты alt для картинок, поддержка управления с клавиатуры.
— Безопасность: HTTPS, правильные заголовки Content Security Policy (CSP), защита от кликджекинга и XSS.
— Производительность: оптимизация под Core Web Vitals (LCP, INP, CLS), правильное кэширование и современный сжатый формат изображений.
— Интернационализация (i18n): корректные теги lang и атрибуты hreflang для мультиязычных ресурсов.
— Готовность к AI-агентам (LLM-ready): пожалуй, самый трендовый пункт. Спецификация рекомендует отдавать контент для нейросетевых ботов и агрегаторов в чистом виде через Markdown-эндпоинты, JSON-LD и RSS, а не заставлять их парсить тяжелый JS-винегрет.
Проект открытый, дополняется сообществом и отлично подходит в качестве готового ТЗ для аудита любого проекта.
Изучить документ
Подписывайтесь на мой Telegram канал