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

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

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

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

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 лучше использовать в ситуациях, когда требуется простая горизонтальная или вертикальная организация элементов, выравнивание элементов по центру, а также когда макет состоит из одной оси, а не из нескольких колонок и строк.

@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, что делает это решение ещё более мощным при работе с крупными кодовыми базами и современными методологиями.

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

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

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

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

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

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

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

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

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

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

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

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

❌ Плюсы и минусы:

Единый процесс разработки и деплоя
Процесс деплоя и разработки стандартизирован, что упрощает рабочий процесс для всей команды.

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

• Лёгкость в поддержке кодстайла и линтеров
Можно настроить единый кодстайл и линтеры для всего репозитория, что помогает поддерживать чистоту кода.

• Простота навигации и кросс-рефакторинга
Все пакеты и модули в одном месте — проще искать и изменять код, особенно когда нужно сделать кросс-рефакторинг.

• CI/CD может замедляться без грамотного кеширования
Когда проект становится слишком большим, процессы CI/CD могут стать медленными, если не настроить их правильно.

• Трудности с разграничением прав доступа и размеры
Разделение доступов для разных команд создает проблемы. С ростом числа пакетов и проектов репозиторий значительно увеличивается в размере.

• Требуются специальные инструменты
Чтобы управлять монорепозиторием эффективно, часто требуются инструменты вроде Nx, Turborepo или Bazel, иначе можно столкнуться с хаосом.

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

❌

Плюсы и минусы:

• Простота изоляция и независимые релизы и CI/CD

Каждая команда отвечает за свой репозиторий. Проекты легко изолировать, обновлять и деплоить независимо, что дает гибкость.

• Легче мигрировать и экспериментировать

Если нужно изменить одну часть системы, это проще сделать, не затрагивая другие проекты.

• Повторение конфигураций и версионный ад

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

• Сложности с централизованными обновлениями

Когда нужно обновить общие утилиты или библиотеки, это становится сложным и трудоёмким процессом.

// Проверяем поддержку
if ('showSaveFilePicker' in window) {
const handle = await window.showSaveFilePicker({
suggestedName: 'data.txt',
types: [
{
denoscription: 'Text file',
accept: { 'text/plain': ['.txt'] },
},
],
});

const writable = await handle.createWritable();
await writable.write('Hello, world!');
await writable.close();

console.log('Файл сохранён прямо на диск');
} else {
console.log('File System API не поддерживается в этом браузере');
}

• showSaveFilePicker() — открывает системный диалог для сохранения файла
• createWritable() — создаёт поток записи в файл
• write() — записывает данные в файл
• close() — закрывает поток и сохраняет файл на диск

ITCSS (Inverted Triangle CSS) — структурированный подход с разделением стилей на слои: общие наверху, специфичные внизу. Обеспечивает порядок, предсказуемость и гибкость, но может быть громоздким для небольших проектов.

• Settings — переменные, которые задают глобальные параметры
• Tools — функции и миксины, которые помогают управлять стилями
• Generic — базовые стили, например, normalize или reset
• Elements — стили для HTML-элементов
• Objects — макетные паттерны, такие как сетки или карточки
• Components — конкретные элементы интерфейса, например, кнопки или карточки
• Utilities — точечные стили для специфичных случаев, например, margin-top или z-index

CUBE CSS — современный подход Энди Белла, фокусирующийся на принципах организации, а не структуре папок. Основная идея: Keep CSS modular and predictable. Подходит для Tailwind, CSS Modules и CSS-in-JS.

• Composition — компоненты и layout-паттерны, например, flexbox или grid
• Utility — маленькие одноцелевые классы, например, .flex или .gap
• Block — самодостаточные компоненты, например, .card
• Exception — редкие и специфичные оверрайды для нестандартных случаев

BEM 2.0 остаётся популярным методом для описания структуры стилей, оставаясь гибким и совместимым с ITCSS или CUBE CSS. Основная идея — чистота и предсказуемость. Это отличный инструмент для модульности и масштабируемости. Теперь вместо громоздких классов типа .btn__icon__wrapper__span используется осознанное написание стилей.

• .block — основной компонент
• .block__element — элемент внутри блока
• .block--modifier — модификатор блока

В ITCSS стили делятся на несколько слоёв. Чем ниже слой, тем более специфичные стили и выше их приоритет. Такой подход помогает избежать конфликтов и делает код более предсказуемым. Структуру слоев я уже писал в посте выше. А вот пример структуры папок:

/src/styles/
├─ settings/
├─ tools/
├─ generic/
├─ elements/
├─ objects/
├─ components/
└─ utilities/

• Легче предсказать каскад, стили не «воюют» между собой
• Удобно для масштабных проектов с десятками разработчиков
• Отлично комбинируется с BEM для организации структуры классов

<button class="btn btn--primary">
<span class="btn__icon"></span>
<span class="btn__text">Save</span>
</button>

.btn { padding: .5rem 1rem; border-radius: 4px; }
.btn--primary { background: blue; color: white; }
.btn__icon { margin-right: .5rem; }

• Простой и понятный DOM, который легко навигировать
• Лёгкость в рефакторинге компонентов
• Минимизация конфликтов стилей благодаря чёткой структуре
• Используй BEM вместе с другими архитектурными подходами, такими как ITCSS или CUBE
• Избегай глубоких цепочек классов, например .card__header__noscript — это уже лишнее
• Применяй BEM с токенами и дизайн-системами для лучшей совместимости
• Держи имена классов короткими и логичными

<!-- Элемент <template> используется для хранения фрагмента разметки, который не отображается на странице, пока его не вставят вручную с помощью JavaScript. Это идеальный инструмент для создания повторяющихся блоков разметки -->

<template id="card">
<div class="card">
<h3 class="noscript"></h3>
<p class="text"></p>
</div>
</template>

<noscript>
const tpl = document.querySelector('#card');
const clone = tpl.content.cloneNode(true);
clone.querySelector('.noscript').textContent = 'Hello';
document.body.appendChild(clone);
</noscript>

<!-- <slot> используется внутри кастомных элементов для вставки внешнего HTML-контента, что позволяет создавать полноценные UI-компоненты без внешних фреймворков, сохраняя семантичность и доступность контента, а также облегчая кастомизацию компонентов -->

<my-button>
<span>Click me</span>
</my-button>

<noscript>
class MyButton extends HTMLElement {
connectedCallback() {
this.innerHTML = `
<button class="btn">
<slot></slot>
</button>
`;
}
}
customElements.define('my-button', MyButton);
</noscript>

Теперь в Cursor есть суперудобная функция «Find Issues», которая позволяет находить и исправлять баги буквально одной кнопкой. Агент проводит ревью вашего кода и моментально показывает все найденные проблемы в боковой панели. Не надо больше искать по строкам и угадать, где что-то пошло не так. Бонус: в течение этой недели вы можете потестировать эту фичу бесплатно!

Греет сердце старый добрый grep, но с улучшениями 🍌
Не знаю, как вы, а я обожаю старый добрый grep, который позволяет быстро найти нужный фрагмент в коде. Так вот, теперь в Cursor это ещё и векторный поиск. А если вы всё-таки за традиции, то grep вынесли отдельно. Работает почти мгновенно и ищет по всей кодовой базе, включая точные совпадения и регулярки. Для тех, кто привык к скорости и точности — просто мастхэв.

Режим планирования тоже не остался без внимания. Теперь, когда вы утверждаете план действий, агент будет задавать уточняющие вопросы. Простой и удобный интерактивный режим позволяет отвечать прямо на месте.

❌ Производительность: цена рендера

React в 2015 году предложил виртуальный DOM, но к 2025 году его оптимальность снизилась. Новые фреймворки, такие как Solid, Svelte и Qwik, используют альтернативные подходы: рендеринг без виртуального DOM, компиляция в чистый JavaScript и резюмирование кода. Это снижает нагрузку на браузер, уменьшает перерисовки и ускоряет загрузку.

❌ Сложность React-приложений растёт

React сам по себе лёгкий и гибкий, но вокруг него сформировалась сложная экосистема: router, state manager, серверные компоненты, bundler, серверные фреймворки и кеширование. Теперь React ассоциируется не только с компонентами, но и с архитектурным стеком, что затрудняет вход для новичков. Раньше достаточно было освоить JSX и компоненты, теперь это полноценная архитектура с повышенным порогом входа.

❌ Все устали от постоянных изменений

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

❌ Альтернативы стали слишком хороши

Раньше на фронтенде доминировал React, но сейчас появились конкуренты. Svelte предлагает простой синтаксис, Solid — максимальную реактивность, Vue 3 — гибкость и отличную документацию, а Qwik — быстрое время до интерактивности (TTI). Эти фреймворки обеспечивают те же возможности, но с меньшим кодом и высокой производительностью.

❌ Новый тренд — меньше JavaScript

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

❌ Люди хотят инструмент из коробки

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

❌ Но React всё ещё жив

React остается промышленным стандартом с огромной экосистемой и миллионами пользователей. Компании вложили много в его кодовую базу, а нововведения, такие как RSC и Server Actions, обещают значительные изменения в ближайшие годы.

✅ Event Loop — дирижёр всего

JavaScript работает в одном потоке, и event loop управляет очерёдностью выполнения задач, следя за тремя основными очередями: Call Stack для синхронного кода, Microtask queue для microtasks и Macrotask queue для таймеров, сетевых событий и UI событий. При этом microtasks всегда выполняются перед macrotasks.

✅ Microtasks — скрытые убийцы FPS

Microtasks — это задачи, выполняемые после основного кода, которые могут блокировать рендеринг при их избытке. Примеры microtasks включают Promise.then, queueMicrotask и async/await continuation.

✅ Reflow/Repaint — тормоза интерфейса

Reflow (пересчёт layout) и repaint (перерисовка элементов) — это процессы, которые могут вызывать тормоза интерфейса.

Reflow происходит при пересчёте размеров и позиций элементов, что является затратной операцией. Триггеры reflow: изменение width, height, padding, margin, чтение layout-метрик (например, offsetWidth, getBoundingClientRect) и изменения в DOM.

Repaint менее затратен, но всё равно может тормозить, так как браузер перерисовывает элементы без пересчёта их размеров.

// Пример Event Loop: Микротаски всегда выполняются сразу после синхронного кода.
console.log('A');

setTimeout(() => console.log('B'));
Promise.resolve().then(() => console.log('C'));

console.log('D');

// Пример ошибки Microtasks: если выполнить слишком много микротасок подряд, рендеринг интерфейса не произойдёт, и UI фризанёт
// Разбей задачи на батчи и используй requestIdleCallback или setTimeout(..., 0), чтобы дать браузеру время на рендеринг

for (let i = 0; i < 10000; i++) {
Promise.resolve().then(() => doStuff(i));
}

// Пример ошибки Reflow/Repaint: каждое чтение layout после записи — это forced reflow, и браузер вынужден пересчитывать всё немедленно.
element.style.width = '100px';
console.log(element.offsetWidth);
element.style.height = '200px';
console.log(element.offsetHeight);