Frontender's notes

⬆️ Container Queries — новый подход к адаптивной вёрстке Адаптивный дизайн изначально базировался на @media с условием: если ширина экрана меньше 768px, уменьшаем шрифт. Но проблема в том, что компоненты могут адаптироваться по-разному в зависимости от контекста (сайдбар, карточка, модальное окно), даже при неизменном размере экрана. Media queries реагируют только на размер viewport, а не на размеры родителя. Container Queries позволяют учитывать размеры родительского контейнера, что даёт CSS возможность адаптировать компоненты в зависимости от контекста. ℹ️ Пример кода:

.card { container-type: inline-size; } @container (max-width: 400px) { .card-title { font-size: 1rem; } }

✅ Как это работает?

• Мы объявляем контейнер с помощью свойства container-type. • Пишем условие с @container, чтобы адаптировать элементы внутри контейнера. • Компонент автоматически адаптируется под размеры своего родителя, а не под весь экран. • Теперь компоненты не зависят от глобальных media queries и могут быть использованы в любом месте без дополнительных хаков или специфичных классов. • Можно описывать адаптив прямо в компонентах, как это делают дизайнеры в Figma. Теперь ваш CSS гораздо точнее отражает реальные потребности. • Сокращается использование JS для адаптивных изменений и избавляет от необходимости работать с множеством media queries, что делает код чище.

📌 Современные браузеры теперь поддерживают Container Queries без всяких дополнительных префиксов. Это как React для CSS: теперь адаптивный дизайн можно делать локально и контекстно, как будто у каждого элемента свой мини-сайт. 🚪 Frontender's notes

🤣 Весомый аргумент 💥 xCode Journal

🖥 Инструмент для разработчиков, которым нравится копаться под капотом Вводи в адресную строку Chrome: chrome://chrome-urls и открываем список всех внутренних страниц браузера: от отладочных тулзов до экспериментальных фич. Внутри: - chrome://flags → скрытые настройки - chrome://gpu → информация о работе GPU - chrome://net-export → отладка сети ✖️ xCode Journal

⛓ Intersection Observer API: как улучшить производительность и UX в 2025 году Технологии не стоят на месте, и в 2025 году Intersection Observer API продолжает развиваться и становится важным инструментом для веб-разработчиков. Этот API не только помогает улучшить производительность, но и заметно повышает качество взаимодействия с пользователем. Давайте разберемся, почему вам стоит обратить на него внимание, и как он может упростить вашу жизнь. ➡️ Что такое Intersection Observer?

Intersection Observer API отслеживает видимость элементов, оптимизируя загрузку контента. Он не требует постоянного мониторинга прокрутки или размера окна. Вместо этого, API реагирует только на изменения видимости, активируя логику, например, загрузку изображений или анимаций, когда пользователь достигает нужного места. Это сокращает ненужные рендеры и повышает производительность. Меньше вычислений, меньше данных — это особенно важно на устройствах с низкими характеристиками.

ℹ️ Пример кода:

const observer = new IntersectionObserver((entries, observer) => { entries.forEach(entry => { if (entry.isIntersecting) { // Загружаем изображение, когда оно попадает в область видимости entry.target.src = entry.target.dataset.src; observer.unobserve(entry.target); } }); }); const images = document.querySelectorAll('img.lazy'); images.forEach(img => observer.observe(img));

✅ Объяснение кода

— Предположим, вы хотите отложить загрузку изображений до тех пор, пока они не окажутся в области видимости. — Здесь мы создаём новый IntersectionObserver. — Для каждого изображения с классом .lazy, как только оно появляется в зоне видимости, происходит загрузка изображения. — Весь этот процесс запускается только в нужный момент, что минимизирует ненужные операции.

📌 В общем штука реально неплохая и может вам пригодиться в ваших проектах. 🚪 Frontender's notes

🔥Курс «Vue.js разработчик» — ускоренный рост до продакшн-уровня Если вы тянете фронтенд на «базовом React/JS», а фичи тормозят из-за лишней сложности, пора перейти на Vue и выпускать быстрее. Окно набора ограничено. Что получите? - Продвинутый Vue, Vue Router, Vuex: от компонентной архитектуры до масштабируемых SPA. - TypeScript: чистый, лаконичный код без «магии». - Тестирование: интеграционное и юнит-тесты (Jest, Cypress). - Интеграции: GraphQL, Firebase, Electron. - Инструменты: Webpack, Babel, паттерны проектирования для сложных интерфейсов. Почему Vue нужно изучать сейчас? - Быстрый старт и понятная реактивность «из коробки» - без сложных концепций. - Легко внедряется в существующие проекты и даёт меньший бандл. - Как Angular, но проще: готовые пакеты для роутинга, состояния и тестов. ⏳Не теряйте время: места в потоке ограничены. Зафиксируйте за собой место и начните обучение: https://vk.cc/cQQ102 Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🔫 Как использовать requestIdleCallback для улучшения производительности Когда говорим о производительности веб-приложений, вспоминаем уменьшение веса страниц и оптимизацию кода. Однако есть requestIdleCallback — это API для запуска задач в моменты, когда браузер не занят важными операциями, например, рендерингом или обработкой событий. Это идеальный способ для фоновых задач, таких как загрузка или обработка данных, без влияния на пользовательский интерфейс и основные операции. ⏲ Когда использовать?

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

ℹ️ Пример кода:

/* Предположим, вы хотите загрузить данные с API в фоновом режиме. Вместо того чтобы инициировать запрос сразу и блокировать основной поток, можно использовать requestIdleCallback: */ function fetchDataInIdleTime() { requestIdleCallback(() => { fetch('/some-api') .then(response => response.json()) .then(data => { console.log('Data loaded in idle time:', data); }) .catch(error => console.error('Error loading data:', error)); }); } fetchDataInIdleTime();

✅ Как это работает

— Мы создаём функцию fetchDataInIdleTime(), которая запускает requestIdleCallback. — Внутри колбэка выполняем асинхронный запрос к серверу. — Запрос будет выполнен в момент, когда браузер освободится от важных задач, таких как рендеринг или обработка событий. — Таким образом, мы делаем загрузку данных менее приоритетной и не нагружаем браузер, пока он не свободен.

📌 Этот метод позволяет выполнять фоновые задачи без задержек для пользователя, экономя ресурсы и улучшая общую производительность. Довольно удобно и эффективно! 🚪 Frontender's notes

✅ Псевдо-классы :user-valid и :user-invalid: как исправить проблему с изначальными стилями При создании форм часто встречаются обязательные поля. Они могут быть заполнены верно или нет. Для стилизации этих состояний обычно используют псевдо-классы :valid и :invalid. Эти классы применяются сразу после загрузки страницы, даже если пользователь ещё не успел взаимодействовать с полем. Это может раздражать из-за некорректного отображения. Рассмотрим, как можно исправить и улучшить ситуацию. 🔎 Вот пример того, как эти псевдо-классы работают по умолчанию:

<<!-- Первое поле с логином зелёное (корректно заполнено). Второе поле с паролем красное (пусто и недействительно) --> <body> <form class="form"> <div class="form__group"> <label for="name">Введите логин</label> <input id="name" type="text" value="melnik909" required> </div> <div class="form__group"> <label for="password">Введите пароль</label> <input id="password" type="password" required> </div> <button>Войти</button> </form> </body> <style> input:invalid { box-shadow: 0 0 10px red; } input:valid { box-shadow: 0 0 10px green; } </style>

➕ Псевдо-классы :user-valid и :user-invalid Для предотвращения преждевременного применения стилей добавлены псевдо-классы :user-valid и :user-invalid, которые активируются при взаимодействии пользователя с полем. Стили применяются только после ввода данных. Давайте заменим старые псевдо-классы на новые:

input:user-invalid { box-shadow: 0 0 10px red; } input:user-valid { box-shadow: 0 0 10px green; }

📌 Теперь форма будет выглядеть нормально сразу, и стили начнут применяться, только когда пользователь начнёт что-то вводить. Это делает интерфейс более удобным и понятным. 🚪 Frontender's notes

Я долго избегал Web3. Казалось — хайп, сложные слова, не моё. Но потом понял: это не “новая профессия”, а просто другая ветка развития для фронта. JS тот же, логика та же — просто добавились новые API. А рынок — 🔥: зарплаты выше, проектов больше, скуки меньше. Фронтенд-опыт тут заходит идеально: асинхронность, стейт, работа с API — всё знакомо, только теперь с блокчейном. Учусь в Guide DAO — сообщество по Web3 и AI, где:

🔘 Пожизненный доступ к курсам, 🔘 Направления — Web3, Solidity, DeFi, AI-агенты, 🔘 Спикеры из 1inch, Parity, MixBytes, 🔘 Постоянные стримы и лайвкодинг, 🔘 Можно делать собственные проекты и искать работу.

Если хочешь разобраться — вот бот: @GuideDAO_hallo_bot Присоединяйтесь к комьюнити со скидкой по промокоду - FRONT_NOTES P.S. В Web3 нет магии. Это просто новые API, а с апихами работать мы уже умеем.

📖 Почему стоит использовать transform и opacity для анимаций Когда мы работаем с анимациями в CSS, важно учитывать, какие свойства задействованы. Некоторые из них могут значительно снизить производительность страницы, тогда как другие обеспечат плавность и быстрое отображение. ⬅️ Что происходит при анимации обычных свойств

Анимация свойств, таких как width, height, margin, padding, top и left, требует от браузера выполнения нескольких ресурсоёмких шагов: Reflow (пересчёт размеров и расположения элементов), Repaint (перерисовка частей страницы) и отображение на экране. Эти процессы могут значительно замедлить работу страницы, особенно при большом количестве элементов, что негативно сказывается на её производительности.

✅ Как сделать анимации более быстрыми и плавными

Для повышения производительности веб-анимаций рекомендуется использовать свойства, обрабатываемые графическим процессором (GPU), вместо центрального процессора (CPU). Это позволяет избежать лишних вычислений и ускоряет отображение, особенно при анимации таких свойств, как transform (например, translate, scale, rotate) и opacity (прозрачность). В этих случаях браузеру не нужно пересчитывать размеры элементов или перерисовывать всю страницу, так как изменения происходят на уровне графики, что значительно улучшает производительность.

❌ Пример плохой и хорошей анимации анимации

/* Когда вы анимируете left, браузер выполняет перерасчёт и перерисовку страницы. Этот способ медленный, так как каждый сдвиг элемента требует выполнения операций reflow и repaint. */ .element { transition: left 0.5s ease; } /* При использовании transform, браузер просто сдвигает элемент на графическом уровне, избегая дополнительных перерасчётов. Здесь браузер применяет изменения только на уровне GPU, что делает анимацию плавной и быстрой. */ .element { transition: transform 0.5s ease; }

📌 Если хочешь, чтобы анимации на твоей странице были плавными и шустрыми, используй свойства transform и opacity. Они не заставляют браузер пересчитывать размеры и перерисовывать элементы, так что сайт будет работать быстрее. 🚪 Frontender's notes

Связность и сцепленность. Почему код живёт или умирает. Недавно наткнулся на пост Темы Сенюкова из Кинопоиска про Cohesion и Coupling. Кажется, это одни из тех базовых понятий, которые ты вроде знаешь, но понимаешь только после кучи сделанных ошибок. С опытом начинаешь видеть закономерность: код умирает не потому, что «технология устарела» или «всё переписали на React 19». Он умирает, потому что у него нарушен баланс — внутри всё плохо связано, а снаружи всё переплетено. Когда связность (cohesion) низкая — модуль делает всё подряд: загружает данные, форматирует дату, логирует аналитику и варит кофе юзеру. Заходишь туда через полгода — и не понимаешь, что и где. Когда сцепленность (coupling) высокая — любое изменение где-то «там» ломает всё «здесь». Изменили API? Привет, бесконечный refactor. Поменяли store? Упало полстраницы. В какой-то момент я перестал смотреть на код просто как на функции и компоненты. Теперь я думаю о нём как о «разговорах» между кусками приложения. Хороший код — это когда эти разговоры короткие и по делу. Плохой — когда все орут непонятно что. Вот пара мыслей, которые реально помогают: 🟢 Делайте компоненты, которые умеют ровно одно. Остальное пусть решают «соседи». 🟢 Прокидывайте зависимости явно — пусть всё, что нужно компоненту, приходит снаружи. 🟢 Разделяйте слои. Данные, логика, UI — три мира, не обязанные знать детали друг друга. 🟢 И самое главное — не бойтесь «резать» код. Маленькие куски легче понимать, менять и тестировать. ✅ Это те вещи, которые определяют, живёт ли ваш проект дольше полугода