🔫 Как использовать 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

⛓ 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

🖥 Инструмент для разработчиков, которым нравится копаться под капотом

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

✖️ xCode Journal

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

💥 xCode Journal

⬆️ Container Queries — новый подход к адаптивной вёрстке

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

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

.card {
container-type: inline-size;
}

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

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

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

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

🚪 Frontender's notes

📝 Structuring large JS/TS проектов — как не утонуть в своём же коде

Проект начинается с идеальной структуры в src/, но через год появляются папки вроде utils, helpers, components-old, нарушая порядок. Архитектура страдает, так как файлы растут быстрее структуры. Как избежать хаоса и не утонуть в коде?

💡 Что работает на практике?

— Feature-sliced design (FSD)
В проекте можно использовать подход, при котором структура делится не по типу файлов, а по функциональности. Например, вместо создания папок для компонентов и утилит организуется структура вокруг функциональных блоков. В папке src создаются разделы: entities, features, pages и shared. Каждая «фича», например, авторизация или профили пользователей, изолирована и имеет свой пользовательский интерфейс, бизнес-логику и сервисы. Это облегчает масштабирование проекта и предотвращает поломку старых функций при добавлении новых.

— Domain-first подход
Теперь ты называешь папки не components, hooks, utils, а по именам бизнес-областей: auth/, profile/, dashboard/. Это упрощает понимание контекста и делает код более организованным.

— Index-файлы как интерфейсы
Каждый модуль экспортирует наружу только то, что нужно. Это помогает уменьшить сцепленность между модулями и делает импорты предсказуемыми.

// Ты исключаешь импорт ненужных частей и делаешь структуру кода более читаемой.
// features/login/index.ts
export { LoginForm } from './ui/LoginForm';
export { useLogin } from './model/useLogin';

— Слои зависимостей
Организуй проект так, чтобы зависимости двигались в одном направлении: от UI → Features → Entities → Shared. Никаких цикличных импортов или «вверх по слоям». Архитектура будет выглядеть как дерево зависимостей, а не как хаотичная паутина.

💼 Инструменты для упрощения

— TypeScript path aliases: Используй алиасы для упрощения импорта, например: @/shared, @/features/auth.

— ESLint rules: Настрой правила для контроля правильности импортов между слоями.

— Barrel files (index.ts): В каждом модуле используй index.ts для экспортирования публичных интерфейсов. Это поможет сократить количество файлов и сделать структуру более понятной.

— Nx / Turborepo: Эти инструменты идеально подходят для крупных монорепозиториев, где нужно поддерживать чистоту и порядок.

📌 Структура проекта — это не просто папки и файлы. Это ограничения, которые помогают команде думать одинаково. Если проект можно читать без ментального GPS, значит, структура удалась. Это ключ к успешной разработке и долгосрочной поддержке.

🚪 Frontender's notes

🦾 Нашли для вас опенсорсную альтернативу Postman — Yaak

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

Работает просто магически.

✖️ xCode Journal

⚡️ Web Animations API или CSS transitions: какой инструмент выбрать для анимаций?

Когда речь заходит об анимациях на фронтенде, мнения расходятся: одни говорят, что для большинства случаев достаточно CSS transitions, а другие утверждают, что только Web Animations API даёт полный контроль над процессом. Давайте разберёмся, что из этого действительно нужно в вашем арсенале.

ℹ️ Для большинства стандартных анимаций CSS transitions — это отличный выбор

/* CSS transitions идеальны для UI-элементов, таких как кнопки, модальные окна и спиннеры */
.button {
transition: transform 0.2s ease;
}

.button:hover {
transform: scale(1.05);
}

• Лёгкость в реализации
• Браузер сам оптимизирует процесс анимации
• Подходит для простых эффектов: hover, fade-in/out, микровзаимодействий
• Нельзя ставить анимацию на паузу, изменить скорость или реверсировать её
• Не подходит для сложных или кастомных анимаций

👁 Web Animations API — полный контроль

// Это инструмент для более сложных анимаций: от секвенций и кастомных интеракций до scroll-анимаций
el.animate(
[{ transform: 'translateX(0)' }, { transform: 'translateX(100px)' }],
{ duration: 500, easing: 'ease-out', fill: 'forwards' }
);

// Лёгкость в синхронизации
// Можно комбинировать с библиотеками, такими как GSAP или React
// Можно ставить анимацию на паузу, ускорять, реверсировать
// Необходимость писать больше кода, чем для CSS

📌 А если хочется и простоты, и гибкости — можно комбинировать оба подхода. Используйте CSS для базовых эффектов и Web Animations API для более сложных сценариев.

🚪 Frontender's notes

🔫 Accessibility 2.0 — не просто тренд, а новая норма

Когда-то доступность в веб-разработке воспринималась как что-то дополнительное. Ты просто добавляешь alt-тег, прописываешь aria-label и считаешь, что все сделал. Сегодня все изменилось. Доступность стала неотъемлемой частью UX, SEO и даже бренда.

ℹ️ Что меняется?

— Доступность как часть производительности
Теперь доступность тестируется так же, как и производительность. Инструменты вроде Lighthouse, axe-core и SonarLint уже встроены в CI/CD. Ошибки a11y не остаются на потом, а реально блокируют билд, если что-то идет не так.

— AI помогает улучшать доступность
Плагины для VSCode подсказывают семантические ошибки, а такие модели, как GPT, могут автоматически генерировать alt-тексты или адаптировать контент для экранных читалок. Искусственный интеллект становится важным помощником в процессе разработки доступных интерфейсов.

— Voice-first и multimodal интерфейсы
Приложения начинают проектировать с учетом голосового управления, жестов и клавиатуры. Это больше не только для пользователей с особыми потребностями, а универсальный подход, который повышает удобство для всех.

✅ Инструменты 2025 года

• axe DevTools — проводите автоматические проверки доступности прямо в браузере.

• Polypane / Responsively App — визуализируйте интерфейсы с учетом различных состояний, включая цветовую слепоту и контрастность.

• Figma Contrast & A11y plugins — проектируйте интерфейсы с учетом доступности еще до начала разработки.

• aria-linter и eslint-plugin-jsx-a11y — обязательные инструменты для React/Next проектов.

📌 Важно, чтобы все могли пользоваться сайтом: и те, кто не может пользоваться мышью, и те, кто сидит на солнце. Если заранее позаботиться о доступности, можно избежать кучу косяков. Доступность 2.0 — это основа крутого фронтенда.

🚪 Frontender's notes

👀 Streams API, Fetch и AbortController — идеальная связка для работы с данными

Когда мы думаем о fetch, сразу представляем себе старый добрый запрос: fetch(url).then(r => r.json()). Но современные веб-технологии куда мощнее. Вместе с Streams API и AbortController мы получаем уникальное сочетание, которое упрощает работу с большими данными и позволяет нам создавать более гибкие и быстрые интерфейсы.

❗️ Streams API — когда данные приходят по частям

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

// Пример кода
const res = await fetch('/big.json');
const reader = res.body?.getReader();

let chunks = '';
while (true) {
const { done, value } = await reader.read();
if (done) break;
chunks += new TextDecoder().decode(value);
}

❗️ AbortController — контроль над асинхронными операциями

AbortController отменяет запросы и асинхронные операции, если они больше не нужны, например когда пользователь ушёл со страницы. Запрос отменяется через 2 секунды без ответа. Это можно использовать не только для fetch, но и для любых асинхронных операций, которые поддерживают signal.

// Пример кода
const controller = new AbortController();
const signal = controller.signal;

fetch('/api/data', { signal });
setTimeout(() => controller.abort(), 2000);

❗️ Вместе — это мощный инструмент для реактивных интерфейсов

Объединив эти возможности, мы получаем мощный паттерн для работы с данными в реальном времени: стриминг данных в UI, отображение частичных результатов без загрузочных экранов и экономию памяти. Это улучшает производительность и пользовательский опыт.

// Пример кода
const controller = new AbortController();
const res = await fetch('/api/stream', { signal: controller.signal });
const reader = res.body.getReader();

for await (const chunk of streamToAsyncIterator(reader)) {
renderChunk(chunk);
}

📌 Fetch, Streams API и AbortController — это не просто новые фичи. Эти инструменты открывают новые горизонты для создания плавных и эффективных интерфейсов. Многие фреймворки, такие как Next.js, Remix и Astro, уже используют эту технологию в своей основе. Значит, если вы хотите быть на волне, нужно освоить эти инструменты.

🚪 Frontender's notes

🔫 Как сократить код, не теряя читаемости?

«Меньше кода» — хорошо, но важно понимать, что это не означает сокращение строк любой ценой. Главная цель здесь — ясность и простота, а не сделать код короче. Давайте разберёмся, как можно уменьшить количество кода, не жертвуя его качеством.

• Не бойтесь удалять лишнее
Каждая функция и условие — это потенциальная точка отказа. Если код не добавляет ценности и не решает задачу, то его лучше удалить. Поддержка меньшего объёма кода позволяет сосредоточиться на более важных аспектах и упрощает развитие проекта. Меньше кода — значит меньше проблем в будущем.

• Повторение — не всегда плохо
Когда в коде появляются 2-3 одинаковые строки, не спешите их абстрагировать. Часто абстракции ради экономии пары строк только делают код сложнее для восприятия. Правило простое: «Не абстрагируй раньше времени, абстрагируй умно». Если повторение не вызывает затруднений, оставьте его.

• Используй возможности JavaScript
Есть ситуации, когда можно заменить несколько строк на одну — и при этом не потерять читаемости. Не бойтесь использовать тернарные операторы, если они действительно упрощают понимание логики. Главное — одна мысль в одну строку.

// Вместо:
if (isAdmin) return 'admin'
else return 'user'

// Можно:
return isAdmin ? 'admin' : 'user'

• Компоненты должны быть короткими
Если React-компонент начинает занимать больше 50 строк, подумайте, не пора ли его разделить. Логику можно вынести в хук, а часть верстки — в отдельный подкомпонент. Каждый компонент должен выполнять одну задачу, чтобы код оставался читаемым и легко поддерживаемым.

• Подход как у редактора
Каждый раз, когда добавляете новую строку в код, спросите себя: «Можно ли сделать это проще?» Пытайтесь всегда искать оптимальное решение. Иногда уменьшение кода на пару строк может значительно повысить его читаемость.

📌 Меньше кода — это не минимализм, а ясность и лаконичность. Когда через месяц работы вы открываете свой код и не хотите переписать его, значит, вы достигли цели. Секрет не в том, чтобы сделать код короче, а в том, чтобы он был простым и понятным.

🚪 Frontender's notes

👩‍🎨 TypeScript Decorators: Мощный инструмент для улучшения кода

В TypeScript 5+ добавили декораторы — это такие штуки, которые делают код понятнее и проще поддерживать. Они похожи на middleware, но работают с классами, методами, полями или параметрами, не ломая логику программы.

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

function Log(target: any, key: string, denoscriptor: PropertyDenoscriptor) {
const original = denoscriptor.value;
denoscriptor.value = function (...args: any[]) {
console.log(`Call: ${key}(${args.join(', ')})`);
return original.apply(this, args);
};
}

class UserService {
@Log
getUser(id: number) {
return { id, name: 'Alice' };
}
}

new UserService().getUser(42);
// → Call: getUser(42)

⚙ Где применяют декораторы на фронтенде?

— Логирование и аналитика. Декоратор @Log записывает вызовы метода getUser, логируя параметры и результат. Это позволяет мониторить вызовы без изменения их логики. Декораторы, такие как @Log, @Track и @MeasureTime, используются для сбора статистики.

— Валидация и проверка аргументов. С помощью декораторов типа @Validate можно автоматически проверять входные данные. Проверка будет происходить автоматически при вызове метода, без дополнительных шагов.

— DI / инъекция зависимостей. Многие фреймворки, такие как Angular и NestJS, активно используют декораторы для инъекции зависимостей (@Injectable, @Component).

— Access control / Guard’ы. Декораторы также могут применяться для контроля доступа, например, @RequireAuth для проверки авторизации перед доступом к страницам или API.

TypeScript преобразует декораторы в вызовы функций, получающих метаданные элементов. Современный синтаксис декораторов основан на ECMAScript proposal и позволяет использовать несколько декораторов для одного элемента, выполняющихся сверху вниз.

📌 Декораторы убирают дублирование и делают API понятнее. С их помощью можно использовать одно и то же поведение в разных местах, не засоряя бизнес-код техническими деталями. В итоге код становится чище, а архитектура гибче.

🚪 Frontender's notes

📄 Storage Foundation API: Удобное хранилище данных для PWAs

Для работы с данными в браузере традиционно используются localStorage и IndexedDB. Однако появился новый инструмент — Storage Foundation API. Это низкоуровневый API для взаимодействия с хранилищем как с файловой системой или базой данных без дополнительных библиотек.

❗️ Пример использования:

const file = await storageFoundation.open('data.bin');
await file.write(new Uint8Array([1, 2, 3, 4]));
const bytes = await file.read(0, 4);

✅ Что это даёт?

• Здесь мы открываем файл data.bin, записываем в него данные и читаем их обратно. Это простое и понятное API для работы с бинарными файлами в браузере.

• Storage Foundation API предоставляет мгновенный доступ к данным в пределах sandbox-браузера, поддерживает хранение больших объёмов информации и обеспечивает работу в оффлайн-режиме для PWA.

• Полезно в PWA-приложениях для оффлайн-режима, клиентских базах данных для мини-SQLite, машинном обучении в браузере для хранения моделей и обработки данных, а также в медиа-приложениях для обработки аудио и видео без отправки данных на сервер.

• Storage Foundation API пока экспериментален и доступен только в Chromium-браузерах. Обсуждается его включение в стандарт Web Platform, что ускорит принятие и поддержку в других браузерах.

📌 Если вы работаете над офлайн-веб-приложениями с кучей данных то вероятно вам может быть интересна эта фича. Этот API дает веб-приложениям свои собственные инструменты для хранения данных.

🚪 Frontender's notes

⚙ DevTools Performance Panel: Необходимый инструмент для повседневного дебага

Если ты используешь Performance только при «тормозах» сайта, ты теряешь его потенциал. Performance Panel в Chrome DevTools — это такая штука, которая помогает понять, как работает ваш сайт или приложение, найти, где оно тормозит, и вообще прокачать свои навыки в отладке.

🔎 Что можно увидеть?

— Main thread timeline: отслеживай, что именно делает JS и как браузер обрабатывает рендеринг — какие скрипты выполняются, когда происходит layout и paint.
— FPS и CPU usage: сразу видно, где падает производительность, и как нагрузка распределяется по процессору.
— Recalculate Style / Layout / Repaint: цепочка событий, которая показывает, когда браузер реально пересчитывает стили и перерисовывает DOM.
— Flame chart: один из самых эффективных способов понять, какие функции или компоненты (например, в React) занимают много времени на рендеринг.

💡 Как использовать Performance каждый день

• Не ограничивайся визуальными оценками. Просто открой Performance, нажми Record и наблюдай, сколько кадров в секунду выдает твой интерфейс. Это даст тебе цифры, на основе которых будет проще выявлять проблемы с производительностью.

• Включи опции Screenshots и Memory. Это сразу покажет визуальные лаги и поможет отследить утечки памяти.

• Если ты часто видишь события Recalculate Style и Layout — это может быть сигналом, что где-то в CSS происходит ненужное перерасчитывание, например, при использовании offsetWidth внутри цикла.

• Используй вкладку React Profiler в сочетании с Performance Panel. Ты будешь видеть, какие компоненты перерисовываются лишний раз, что поможет оптимизировать рендеринг.

➕ Комбо для продвинутых

• Performance Insights (beta) — Chrome сам подскажет тебе, какие части кода замедляют работу приложения.
• Web Vitals overlay — на лету покажет LCP, CLS и FID во время профилирования, чтобы увидеть влияние на производительность.
• Performance.mark() и measure() — возможность добавлять свои точки измерения в код

📌 Performance Panel — это не просто графики и странные цифры. Это мощный инструмент, который ты должен использовать ежедневно для оптимизации своего кода. Записывай, анализируй и ищи лишние рендеры или медленные layout’ы, и ты уже гораздо лучше будешь понимать слабые места своего проекта.

🚪 Frontender's notes

📣 Почему простота в коде — это не всегда легкая задача

Когда я только начинал, мне казалось, что чем меньше кода, тем проще. Простой код — это просто минимум строк, не так ли? Но с опытом я понял, что простой код — это понятный код. И вот тут начинается самое интересное. Понять, что делает код, намного сложнее, чем просто написать его.

➡️ Отбрасывание лишнего — ключ к простоте
Научиться делать код простым — значит уметь отбрасывать всё лишнее. Это не про то, чтобы уменьшить количество строк до минимума. Нужно не писать «на будущее».

➡️ Понимание задачи — вот что важно
Очень важно понять суть задачи. Чтобы не строить архитектуру для фичи, которая никогда не выйдет в прод.

➡️ Объяснить сложное простыми словами
Важно уметь объяснять сложные вещи не только в коде, но и в PR и документации.

📌 Писать сложно может каждый. Писать просто — значит, ты действительно понял задачу и её решение. Это про ясность и понимание.

🚪 Frontender's notes

🤣 Когда тестировщик нашел баг перед релизом

💥 xCode Journal

🔎 Когда CSS Grid вытягивает сложные макеты, а Flex не справляется

Все любят Flex — это универсальный инструмент, который решает большинство задач. Но когда дело доходит до сложных макетов, где нужно больше, чем просто выравнивание в одну ось, CSS Grid становится настоящим спасением.

✅ Двумерное выравнивание

Flex работает с одной осью (строка или колонка), но не всегда выравнивает элементы по вертикали и горизонтали. Для этого используется Grid. Пример: карточки товаров с разной высотой описания. Flex создает «рваные» ряды, а Grid выравнивает их идеально по сетке, независимо от высоты контента.

.products {
display: grid;
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
gap: 16px;
}

✅ Когда важна структура, а не порядок в HTML

Grid позволяет менять расположение элементов без изменения разметки. В отличие от Flex, который зависит от порядка элементов в HTML, Grid работает по правилам сетки. Используйте grid-area для назначения областей и их изменения местами, включая адаптивные макеты, без JS.

grid-template-areas:
"header header"
"sidebar main"
"footer footer";

✅ Точное позиционирование

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

.item {
grid-column: 2 / 4;
grid-row: 1 / 3;
}

✅ Адаптивность без медиазапросов

Grid автоматически подстраивается под доступное пространство без сложных медиазапросов. Это удобно для адаптации элементов по ширине экрана.

grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));

👀 Когда использовать Flex вместо Grid

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

📌 Flex — это как универсальный нож для простых дел, а Grid — это как мощный инструмент для сложных и многослойных макетов. Когда ваш дизайн становится сложнее и требует точности, самое время переходить на Grid.

🚪 Frontender's notes