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

💥 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

🤦‍♂️ «Вайб-кодинг» стал словом года по версии словаря Collins

В топе важнейших слов также оказались «микропенсия» и «кланкер» — последнее не про веселосипеды, так пренебрежительно называют роботов и эти ваши нейросети.

Деградируем, или нет?

✖️ xCode Journal

🔼 Cascade Layers — новый взгляд на старую проблему каскада в CSS

Помните, как каскад в CSS был кошмаром? Теперь с Cascade Layers (@layer) управление приоритетами стилей стало проще. @layer позволяет определять порядок применения слоев стилей, устраняя хаос и необходимость использования !important.

❗️ С помощью @layer мы можем разделить стили на различные уровни — от сброса стилей до переопределений для компонентов

@layer reset, base, components, overrides;

@layer reset {
* { margin: 0; padding: 0; }
}

@layer components {
button { background: var(--accent); }
}

@layer overrides {
.danger button { background: red; }
}

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

• Чёткий контроль приоритетов без использования !important. Теперь стили можно упорядочить и применять в правильном порядке, без необходимости прибегать к грязным хакам.

• Простое масштабирование больших проектов. Когда проект растёт, важно, чтобы управление стилями было предсказуемым. С @layer это становится возможным.

• Отлично работает с CSS Modules и Design Tokens, что делает это решение ещё более мощным при работе с крупными кодовыми базами и современными методологиями.

📌 С Cascade Layers каскад больше не враг. Это инструмент для архитектуры, который помогает контролировать стили на уровне слоёв и упрощает поддержку кода в крупных проектах.

🚪 Frontender's notes

💡 File System API 2.0 — будущее оффлайн-приложений

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

❗️ Что изменилось с появлением версии 2.0?

• Более безопасная модель доступа: В версии 2.0 добавлена поддержка доступа к файлам через приватные файловые системы с origin-сигнатурой, что значительно улучшает безопасность.

• Поддержка директорий: В новой версии можно работать не только с отдельными файлами, но и с целыми каталогами, что открывает новые горизонты для разработчиков.

• Асинхронные операции: Все операции с файлами теперь выполняются асинхронно, с использованием промисов, что избавляет от блокировок и делает работу с файлами ещё более эффективной.

• Совместимость с Service Workers: Эта совместимость делает File System API идеальным инструментом для создания оффлайн-приложений.

❌ Где полезно и некоторые ограничения

— Текстовые или кодовые редакторы в браузере: Создавайте полноценные редакторы прямо в веб-приложении, с возможностью работы с файлами.

— PWA-приложения: Web-приложения, поддерживающие оффлайн-режим, могут теперь использовать локальный кэш и сохранять данные на устройстве.

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

— Корпоративные дашборды: Экспорт и импорт данных теперь можно делать прямо с локального устройства.

— API всё ещё не поддерживается во всех браузерах.

— Для работы с файлами требуется user consent. То есть пользователи должны явно согласиться на доступ к их файлам.

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

📌 File System API 2.0 станет нативной файловой системой для веб-приложений, обеспечивая их работу на уровне VS Code, Figma или Notion без установки. Это откроет новые возможности для разработчиков и улучшит работу с данными в вебе.

🚪 Frontender's notes