Remix 3 Beta — курс на zero-deps 🧩

Команда Remix показала бета-версию Remix 3. Фреймворк уходит от монолита: вместо React и больших зависимостей — набор маленьких пакетов. Хочешь работать с cookies — ставь пакет. Нужны headers — отдельный пакет. Middleware, proxy, auth — тоже всё отдельно. Как это всё дружит между собой — решать уже вам.

Remix продолжает продвигать идею server-driven state: формы, loaders/actions и Web APIs вместо клиентских стейт-менеджеров.

Правда, пока всё выглядит довольно сыро: документации мало, а собирать приложение местами приходится буквально по демкам и примерам из репозитория.

Подход стал заметно сложнее, но даёт больше контроля и предсказуемости — меньше магии, больше понимания того, что реально происходит под капотом.

Как думаете, есть ли будущее у такого Remix-пути?

Читать анонс

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

Управление бесконечными CSS-анимациями на лету 🕹

Если вы пробовали динамически менять скорость бесконечной CSS-анимации (например, ускорять вращение при ховере, просто меняя animation-duration), то знаете главную боль: элемент неприятно «прыгает» на случайную позицию. Чтобы сделать всё гладко, обычно приходится прикручивать JavaScript.

В блоге Frontend Masters вышла отличная статья о том, как изящно решить эту проблему на чистом CSS.

Главный инструмент здесь — свойство animation-composition: add.
Вместо того чтобы менять параметры текущей анимации, мы вешаем на элемент сразу две одинаковые. Первая работает постоянно, а вторая висит на паузе (paused). При наведении мы снимаем вторую с паузы, и благодаря composition: add их значения складываются.

Дальше в дело вступает математика на CSS-переменных и calc(). Задав нужный фактор скорости, можно:
— кратно ускорять или замедлять анимацию;
— полностью её останавливать;
— разворачивать движение в обратную сторону (с помощью отрицательных значений).

В итоге: Никакого «дёрганого» UI и пересчетов в JS — всё работает силами движка браузера. Подход идеально подойдет для интерактивных лоадеров, сложных фоновых эффектов или бесконечных бегущих строк (каруселей), которые реагируют на действия пользователя.

Читать статью

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

Безопасные мобильные раскладки: укрощаем чёлки и вырезы 📱

Современные смартфоны — это зоопарк вырезов, камер и системных плавающих кнопок, которые так и норовят перекрыть интерфейс. Чтобы элементы не «заплывали» под чёлку, важно правильно работать с безопасными зонами.

В блоге Polypane вышел отличный разбор по работе с safe-area-inset.

Главное из статьи:
• viewport-fit=cover — база. Без этого параметра в <meta viewport> браузер просто добавит пустые поля по бокам, игнорируя всю площадь экрана.
• env(safe-area-inset-*) — те самые переменные для управления отступами сверху, снизу и по бокам.
• CSS — напоминание о том, как изящно комбинировать системные отступы с вашим дизайном через calc(1rem + env(safe-area-inset-bottom)).
• Новинка: safe-area-max-inset-* — переменные, которые решают проблему «прыгающего» интерфейса. В отличие от стандартных инсетов, они не меняются динамически, когда адресная строка скрывается при скролле.

Если вы всё ещё делаете фиксированные отступы «на глаз» — это отличный повод перейти на системные переменные и забыть о проблемах с разными моделями iPhone и Android.

Читать статью

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

Улучшаем кэширование в браузере с помощью No-Vary-Search 🚀

Каждый фронтендер знает боль: вы идеально настроили 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? 🛡

Все мы когда-то рендерили пользовательский контент через 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) прямо поверх вашей разметки.

Это не просто хитрый backdrop-filter: blur() в CSS, а полноценная симуляция жидкости. Библиотека считывает HTML-структуру страницы, переносит её в Canvas и использует WebGPU/WebGL для рендеринга физически корректных преломлений, бликов и капель в реальном времени.

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

Исходники на GitHub
Позалипать в демки

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

Как вам такой UI-тренд? Нашли бы применение такой тяжелой графике в реальных проектах (например, на промо-страницах) или CSS-размытия пока более чем достаточно? 👇

Стартовал опрос State of CSS 2026 🎨

Это реальная возможность напрямую повлиять на развитие веба. Вендоры браузеров внимательно изучают эти результаты, когда планируют приоритеты по внедрению новых фич и стандартов. Чем больше разработчиков проголосует, тем релевантнее будет вектор развития спецификаций.

Полезный побочный эффект: Пока заполняешь анкету, гарантированно наткнешься на новые для себя свойства и селекторы, о которых даже не слышал. Отличный способ нахвататься нового и закинуть себе в закладки «почитать на досуге».

Пройти опрос

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

Декларативный точечный апдейт страниц: прощай, тяжелый JS для стриминга? ⚡️

На майском 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() 📐

Все мы любим 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 по этому показателю.

Если верить их бенчмаркам, они знатно прокачали скорость, но самое интересное — под капотом.

Из главного: во-первых, прощай дурацкий префикс 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 канал

Нативная стилизация зазоров (Gap Decorations) в CSS

Добавление разделительных линий между колонками или строками в 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.
— Флексы, гриды или абсолют? Сравнение «лоб в лоб» для разных сценариев. Спойлер: place-content: center или margin: auto во флексах решают 90% задач, но везде есть свои подводные камни.
— Новое свойство text-box (бывшее text-box-trim): идеальный способ избавиться от нативных невидимых отступов вокруг текста, которые вечно ломают идеальное вертикальное центрирование «по пикселям».
— Якорное позиционирование и anchor-center: нативный способ центрировать всплывашки, тултипы и менюшки относительно элемента-донора без единой строчки на JavaScript.
— Безопасное и небезопасное центрирование: разница между align-content: center и align-content: safe center. Обязательно к изучению, чтобы контент внутри мелких контейнеров на мобилках переносился или скроллился, а не тупо обрезался за краями экрана.

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

Читать

Подписывайтесь на мой 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 канал