Наткнулся на прикольную игру — 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 канал

CSS Containment — недооценённый буст производительности 🚀

Наткнулся на отличную статью от CSS Wizardry про contain — и кажется, многие до сих пор недооценивают эту штуку.

contain позволяет изолировать часть DOM и сказать браузеру: «всё, что происходит внутри — не влияет на остальную страницу».
В результате браузер может сильно оптимизировать перерасчёты layout, paint и style.

Автор разбирает основные значения:
contain: layout — изоляция layout
contain: paint — ничего не «вылезает» за границы
contain: size — элемент не влияет на размеры родителя
contain: content — сразу всё вместе (самый частый кейс)

Особенно полезно для:
— виджетов
— сложных компонентов
— виртуализированных списков
— любых изолированных UI-блоков

💡 По сути — это способ вручную подсказать браузеру границы влияния, чтобы он не пересчитывал лишнее.

Но есть нюансы:
— можно случайно сломать layout
— size ведёт себя не всегда очевидно
— не всё можно безопасно заизолировать

В статье много примеров и объяснений, где это реально даёт профит.

Читать

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

IPv8 — новый интернет?

В IETF появился драфт IPv8 draft — и на бумаге выглядит как мечта.

Если коротко: авторы предлагают просто добавить ещё блоков к IPv4 (почему раньше до этого не додумались — хороший вопрос).

Структура такая:

r.r.r.r.n.n.n.n
r.r.r.r — 32-bit ASN роутинг-префикс
n.n.n.n — 32-bit адрес хоста (по сути тот же IPv4)

То есть было:
192.168.0.1 → станет что-то вроде 10.20.30.40.192.168.0.1

Без шестнадцатеричной магии и ::, как в IPv6.

Идея в том, что IPv4 становится подмножеством IPv8, а значит, внедрение должно быть менее болезненным, чем с IPv6.

Но мы уже видели, как «должно быть» работает в реальности — IPv6 до сих пор внедряют спустя десятилетия 🙂

Плюс в драфте есть и другие изменения:
— криптография
— аутентификация
— более гибкая адресация

Я не очень силён в сетях, так что за деталями лучше сразу идти в первоисточник 👇

Читать драфт

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

Нативный masonry почти здесь

Появился Masonry Grid Lanes — веб-компонент с “native-first” подходом: сначала пытается использовать нативный masonry (через Grid Lanes API), а если браузер не поддерживает — аккуратно фоллбечится на JS.

Что по факту:
— Проверяет поддержку в браузере
— Есть натив → используем его
— Нет → включается JS-раскладка
— Снаружи — просто кастомный элемент
— Есть поддержка Pretex

<masonry-grid-lanes 
  min-column-width="280" 
  gap="16" 
  text-metrics="pretext"
>
  <div>...</div>
  <div>...</div>
</masonry-grid-lanes>

Хороший пример прогрессивного улучшения: пишем как будто платформа уже умеет, но не ломаемся там, где она ещё не догнала.

Подробнее

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

Прелоад изображений: не всё так очевидно 🖼

Наткнулся на хороший разбор про способы сказать браузеру «эта картинка важная».

Коротко по вариантам:

1. Обычный <img />
Браузер сам решает приоритет. Часто — достаточно хорошо.

2. Атрибут loading="lazy"
Откладывает загрузку.
Хорошо для всего, что ниже изначального viewport.
Плохо, если случайно повесить на hero → замедлите LCP.

3. Атрибут fetchpriority="high" (самый практичный вариант)
Даёт явный сигнал приоритета:

<img src="/hero.jpg" fetchpriority="high" alt="" />

👉 В большинстве случаев — лучшее решение для LCP-картинок
Без лишней магии и дублей.

4. Тэг <link rel="preload" as="image"> в <head />
Жёстко форсит раннюю загрузку:

<link rel="preload" as="image" href="/hero.jpg">

Но:
— легко сделать двойную загрузку
— можно забить сеть и сломать приоритеты
— требует аккуратности (типы, imagesrcset, sizes)

👉 Использовать точечно

Для responsive-картинок следует использовать атрибуты rel="preload", imagesrcset и imagesizes.

<link 
  rel="preload" 
  as="image" 
  imagesrcset="hero-800.jpg 800w, hero-1600.jpg 1600w"
  imagesizes="100vw"
/>

👉 Иначе браузер может скачать не тот размер

5. Скрытый <img /> или display: none

<div style="display:none">
  <img src="/hero.jpg" alt="">
</div>

👉 Браузер всё равно начнёт загрузку.
Но это скорее костыль — приоритет будет неочевидный, и читаемость страдает.

6. background-image в CSS

.hero {
  background-image: url('/hero.jpg');
}

👉 Вот тут нюанс:
браузер узнаёт о такой картинке только после парсинга CSS,
поэтому она часто грузится позже, чем <img />.

7. Хаки с background + preload / скрытые элементы
Типа прелоадить background через <link /> или подсовывать невидимый <img />.

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

8. JS через new Image()

const img = new Image()
img.src = '/hero.jpg'

👉 Старый способ, который хуже дружит с приоритетами браузера.

———

Главный вывод из статьи:

— способов «заставить» браузер грузить картинку раньше — много
— но большинство из них — костыли или edge-case решения

👉 Практика:

— для hero → fetchpriority="high"
— для background → иногда оправдан preload
— всё остальное — только если понимаешь последствия

TL;DR:
Не нужно изобретать схемы с hidden div и хаками — в 90% случаев есть более простой и нативный способ.

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

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

Zed 1.0 — быстрый редактор на Rust 🚀

Ребята из Zed Industries выкатили Zed 1.0 — первый стабильный релиз своего редактора кода.

Вообще, интересный тренд: всё больше вещей утекает из JS/TS в Rust. Сначала туда переехали линтеры, форматтеры и прочие тулзы (и дали нам ощутимый буст по скорости), а теперь и полноценные редакторы. Zed — как раз из этой новой волны.

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

Что завезли к 1.0:

⚡️ Мгновенная работа с большими проектами — всё благодаря Rust и продуманной архитектуре
👥 Коллаборация в реальном времени — можно прямо в редакторе работать вместе с другими
🤖 AI — встроенный ассистент для кода (подсказки, генерация и т.д.)
🧩 Расширяемость — плагины и кастомизация под себя
🖥 Нативный UI без веб-вью, что тоже влияет на производительность
🔌 Интеграции с LSP и привычным дев-стеком
🌐 Кроссплатформенность (Windows, macOS, Linux)

Выглядит как серьёзная заявка на конкуренцию с Visual Studio Code и другими редакторами.

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

Вы уже смотрели в сторону Zed или даже успели пересесть? 👀

Читать анонс

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

Streaming в React: что реально происходит

Интересный разбор того, как в React устроен стриминг UI под капотом — и почему он может рендерить интерфейс «не по порядку».

Автор показывает, что современный SSR в React — это уже не просто «собрали HTML → отдали». С появлением Suspense и streaming сервер начинает отправлять куски разметки по мере готовности. Причём порядок может отличаться от исходного дерева компонентов.

Ключевая идея:
— React разбивает дерево на чанки
— каждый Suspense boundary становится точкой, которую можно «дождаться или пропустить»
— готовые части улетают клиенту сразу, не блокируя всё остальное

В итоге:
— быстрый TTFB
— пользователь раньше видит хоть что-то полезное
— тяжёлые куски догружаются позже

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

Хорошо объясняется, почему это не ломает DOM и как вообще возможно рендерить out-of-order, не превращая страницу в кашу.

Если работаешь с SSR / RSC — прям мастрид, чтобы понять, что реально происходит, а не «оно как-то стримится само».

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

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

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 канал