SIBERIA CAN CODE 🧊 

Новинки Chrome 148

В CSS продолжают упрощать реальные сценарии: container queries теперь могут срабатывать только по container-name, без обязательного container-type, а at-rule() в @supports позволяет проверять поддержку самих CSS-директив. Плюс появились text-decoration-skip-ink: all и revert-rule для более гибкого контроля стилей.

Из практичного — <video> и <audio> получили loading="lazy", что помогает экономить ресурсы на тяжёлых страницах. Также Chrome продолжает активно развивать платформенные возможности: Prompt API открывает доступ к локальным AI-моделям, добавили Web Serial API на Android и улучшения в Web Authentication.

Условная валидация форм на CSS

С помощью :nth-child(... of <selector>) можно строить условную валидацию форм прямо на CSS. Например, отслеживать количество валидно заполненных полей и активировать кнопку только после выполнения нужного условия — без дополнительного JavaScript.

Это хороший пример того, как современные селекторы постепенно позволяют переносить интерактивную UI-логику в стили. Пока есть ограничения по поддержке, но сам подход уже выглядит очень мощно для простых сценариев.

Remix выложил новый красивый лендинг, а есть ли смысл

Изначально проект строился на идее расширить привычный роутинг до полноценного full-stack фреймворка, объединив сервер, загрузку данных и UI в одном подходе. Но со временем Remix всё сильнее смещается в сторону веб-стандартов, платформенности и более универсальной архитектуры.

Сейчас это уже не просто React-фреймворк, а полноценный отдельный продукт, с помощью которого уже можно строить приложения вокруг серверной логики, роутинга и данных без излишней зависимости от экосистемных абстракций. По сути Remix постепенно превращается из расширения React-мира в самостоятельный фундаментальный инструмент.

Моки сложнее, чем кажутся

Мы продолжаем развивать apicraft и добавили в него интеграцию с fakerjs. Сама интеграция получилась довольно простой, но при этом очень эффективной. За это время мы с командой научились выстраивать автотесты, закрыли много инфраструктурных задач, сделали собственный мок-сервер и серьёзно его улучшили. Но даже при всём этом генерация самих мок-данных и их поддержка всё ещё оставались отдельной проблемой.

Во многих проектах есть знакомый сценарий: моки огромные, данных много, но реальное содержимое чаще всего не так важно. Именно под такие кейсы мы сделали новый плагин — теперь одной cli-командой можно на основе OpenAPI генерировать функции для всех схем, которые позволяют создавать моки буквально за секунды.

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

Оптимизация зачастую вопрос непервостепенный, в новом видео рассуждаем на эту тему и после учимся оптимизировать react хуки. Поверьте, в среднестатических приложениях вероятнее всего у вас никогда не будет проблем

Новая документация для reactuse beta

Новая дока не только имеет обновленный дизайн, но и новые вещи для ai совместимости (llm.txt, copy for promt, skills). Также в будущем будут переработаны все демо, на данный момент обновления получили некоторые хуки. Добавили для хуков список зависимостей для других хуков.

Какие работы остались? Все еще остался нейрослоп код, который нужно вычистить, переписать все 150+ демо и их сео, а также доработать красивый лендинг.

Реальность, а не доводы, ререндеры победили

Вы не поняли смысл dry принципа

Очень часто вижу одну и ту же картину: проект, который по своей природе должен быть простым, постепенно превращается в набор оверхед-решений. Всё из-за того, что в интернете много говорят про архитектуру, паттерны и «правильные подходы», но сама суть теряется. Люди начинают выносить всё подряд просто потому, что «так надо», «так делают» или «в react же говорят делить на компоненты». Хотя на практике такое вынесение нередко создаёт больше проблем, чем решает.

DRY — это не про то, чтобы абстрагировать каждую повторяющуюся строчку. Это про осознанность. Каждый раз стоит задаваться вопросом: зачем мы это выносим? Потому что каждый проект, каждая фича и даже каждая страница — это разные условия, где требования к архитектуре могут сильно отличаться.