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

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

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

Микрофронтенды — это базовый минимум
Независимый хостинг, 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 канал

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