// Проверяем поддержку
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);

• :is() — компактный и эффективный селектор
Селектор :is() позволяет сократить количество строк кода, уменьшить дублирование и сделать код более читаемым, при этом он поддерживается повсеместно.

• :where() — стратегический селектор с нулевой специфичностью
Настоящий помощник в глобальных стилях для дизайн-систем. У него нулевая специфичность, так что он не мешает более точным стилям. Это значит, что можно легко управлять оформлением компонентов и не бояться случайных изменений.

• @layer — контроль над каскадом и приоритетами
Крутая штука, которая даёт полный контроль над стилями и их приоритетами. С ним легче поддерживать код и меньше нужно использовать !important. Всё благодаря тому, что можно явно задавать слои каскада, что делает порядок подключения файлов более понятным и структурированным.

• Как это работает вместе?
Комбинация @layer для настройки уровней важности стилей, :where() для безопасного повышения специфичности и :is() для упрощения селекторов помогает сделать код более управляемым и масштабируемым. Так вы избегаете неожиданных конфликтов и перегрузок специфичности и легко добавляете новые стили даже в больших проектах.

/* :is() — компактный и эффективный селектор */
:is(button, a, input).primary:hover {
color: white;
}

/* :where() — стратегический селектор с нулевой специфичностью */
:where(.card .noscript) {
margin-block: 8px;
}

/* @layer — контроль над каскадом и приоритетами */
@layer reset, base, components, utilities;

@layer reset {
*, *::before, *::after { margin: 0; padding: 0; }
}

@layer components {
.button { padding: 8px 12px; }
}

@layer utilities {
.mt-2 { margin-top: 8px; }
}

inline определяет направление текста (например, слева направо или справа налево), а block — направление блоков, обычно сверху вниз, в зависимости от потока документа. Для горизонтальных отступов используются margin-inline-start и margin-inline-end, для вертикальных — padding-block-start и padding-block-end. Для позиционирования и границ применяются border-inline и inset-block.

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

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

• Унифицированные компоненты в дизайн-системах
Когда компонент должен быть независим от языка, логические свойства дают предсказуемое поведение в разных контекстах.

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

/* Старый способ */
.card {
padding-top: 12px;
padding-left: 16px;
}

/* С логическими свойствами */
.card {
padding-block-start: 12px;
padding-inline-start: 16px;
}

/* margin-inline — отступы по горизонтали
margin-block — отступы по вертикали
padding-inline — внутренние отступы горизонтальные
padding-block — внутренние вертикальные
inset-inline — позиционирование по горизонтали (left/right)
inset-block — позиционирование по вертикали (top/bottom) */

⬅️ loading="lazy" — откладываем загрузку

Атрибут loading="lazy" заставляет браузер откладывать загрузку изображений за пределами экрана, что экономит трафик пользователей, уменьшает время до интерактивности (TTI) и снижает нагрузку на слабые устройства. Его следует применять для всех изображений ниже первого экрана, а также для карточек, списков и галерей. Однако, не стоит использовать этот атрибут для важных для интерфейса изображений на первом экране, таких как логотипы и hero-изображения, чтобы избежать задержек в загрузке сайта.

⚡️ decoding="async" — асинхронная декодировка

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

🔫 fetchpriority="high | low" — управление приоритетом загрузки

Атрибут loading определяет приоритет загрузки изображения: high для первоочередной загрузки, low для загрузки позже. Это уменьшает конкуренцию между ресурсами, ускоряет LCP и снижает визуальные задержки при рендеринге страницы, обеспечивая более быструю и плавную загрузку.

<!-- Откладываем загрузку -->
<img src="hero.png" loading="lazy" />

<!-- Асинхронная декодировка -->
<img src="photo.jpg" decoding="async" />

<!-- Управление приоритетом загрузки -->
<img src="hero.jpg" fetchpriority="high" />
<img src="avatar.jpg" loading="lazy" fetchpriority="low" />

<!-- Всё вместе -->
<img src="hero.jpg" decoding="async" fetchpriority="high" />
<img src="thumb.jpg" loading="lazy" decoding="async" fetchpriority="low" />

ℹ️ Что такое render cost?

Render cost — это сумма всех затрат, которые браузер несёт при выполнении операций с пользовательским интерфейсом, включая создание и изменение DOM-узлов, обновление стилей, пересчёт layout, перерисовка элементов и выполнение JS, которое запускает все эти операции. В крупных проектах неправильные UI-операции могут стать причиной лагов и фризов интерфейса.

❌ Самые дорогие операции

Перерасчёт геометрии элементов, запуск рендеринга с кистью и смешивание слоёв — все эти процессы могут быть затратными для производительности приложения. Пересчёт геометрии элементов происходит при чтении свойств offsetWidth, getBoundingClientRect(), изменении размеров, положения или шрифтов, а также при применении сложных CSS-правил. Запуск рендеринга с кистью особенно дорог при использовании эффектов, фильтров или градиентов.

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

✅Как оценить render cost в реальных проектах

• React DevTools Profiler: Позволяет понять, какие компоненты перерисовываются слишком часто, где тратится больше всего времени и какие пропсы вызывают каскадные обновления.

• Chrome Performance panel: Главный инструмент для анализа. Позволяет увидеть трейсинг JS, layout events, paint events и точные триггеры reflow.

• Performance Insights: Подсвечивает проблемные места и даёт рекомендации по улучшению производительности.

• Lighthouse: Отлично показывает точки деградации на высоком уровне и предлагает пути для их устранения.

🤚 Что считается «дорогим» в UI?

В пользовательском интерфейсе (UI) «дорогим» считается всё, что требует значительных ресурсов для выполнения и может замедлять работу приложения. К таким элементам относятся частые полные перерисовки списков вместо частичных обновлений, громоздкие компоненты, где один стейт перерисовывает всю страницу, сложные CSS-стили, например, глубокие селекторы, а также DOM с тысячами узлов на одном экране и последовательное чтение и изменение layout (forcing reflow).

⚡️ Как снижать render cost

Чтобы снизить render cost, важно оптимизировать компоненты: делите их на мелкие для уменьшения области перерисовки. Используйте fine-grained реактивность с помощью сигналов, селекторов или memoized stores, чтобы обновлялось только необходимое. Избегайте живых reflow, группируя измерения и изменения DOM.

Применяйте виртуализацию для рендеринга только видимых элементов в DOM. Используйте transform вместо top/left в CSS, избегайте тяжёлых эффектов и следите за структурой CSS. Для тяжёлой логики можно использовать Web Workers, перенося вычисления в основной поток и сохраняя отзывчивость UI.

✅ Что такое .map файлы?

Файлы .map — это JSON-структуры, которые содержат полную информацию о вашем коде. В них хранятся ссылки на оригинальные файлы, сам исходный код, соответствие между минифицированными и оригинальными строками кода, а также список символов и имён.

Это не просто файлы для дебага, это своего рода словарь вашего кода, который позволяет анализировать и профилировать его работу.

✅ Почему .map файлы полезны для профилирования?

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

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

✅ Что можно увидеть в .map файле?

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

В некоторых случаях .map файлы показывают подтягивание ненужных polyfills или «раздутые» функции, которые не были удалены после трешейкинга. Всё это можно обнаружить, если внимательно изучить .map файл.

✅ Как читать .map файлы?

Для анализа .map файлов можно использовать специальные инструменты, такие как maps-codec, source-map-explorer или даже встроенные инструменты в браузере через DevTools. Эти инструменты помогут вам понять, что именно добавляет вес вашему бандлу и как это влияет на производительность.

Если вы хотите пройти путь профилирования вручную, можно использовать source-map-explorer, который визуализирует содержимое .map файла и помогает быстро найти проблемные места.

✅ Когда вы работаете с .map файлами, стоит следовать нескольким простым рекомендациям

• Во-первых, всегда анализируйте source map на продакшн-сборке, так как staging-сборки могут иметь разные флаги, влияющие на результат.
• Во-вторых, используйте опцию hidden-source-map, чтобы скрыть карты от публичного доступа, но использовать их в CI.
• Также не забывайте отслеживать динамические импорты, ведь .map файл может показать, что именно попадало в ваши чанки.
• И, конечно, сравнивайте .map файлы между сборками, чтобы понять, что именно увеличивает размер бандла.

❌ Браузер: всё о пользовательском интерфейсе

В браузере event loop сосредоточен на работе с пользовательским интерфейсом (UI). Его основная задача — обеспечить плавность рендеринга, быстроту реакции на события, выполнение JavaScript и обработку Web APIs.

В процессе работы с UI браузер использует несколько типов очередей задач. Это microtasks, такие как обработка Promise и queueMicrotask, и macrotasks, в которые попадают setTimeout, setInterval и MessageChannel. Также есть отдельная фаза для рендеринга. Браузер обязан поддерживать плавность UI, поэтому между макротасками он обязательно вставляет фазу рендеринга, что позволяет минимизировать задержки при обновлении интерфейса.

❌ Node.js: event loop от libuv

В Node.js event loop работает на основе библиотеки libuv, которая используется для асинхронных операций, таких как работа с файловой системой, сетью и другими I/O операциями. В отличие от браузера, в Node.js есть несколько фаз, которые позволяют эффективно управлять этими операциями.

Node.js использует шесть фаз, включая Timers (setTimeout, setInterval), Poll (обработка I/O операций), Check (setImmediate) и другие. Основное отличие заключается в том, что Node.js управляет низкоуровневыми операциями с системой, такими как файлы и сеть, в то время как браузер сосредоточен на рендеринге и UI. Это позволяет Node.js быть более гибким в обслуживании серверных запросов и файловых операций.

❌ Где начинается путаница

Существует несколько распространенных недопониманий между setTimeout и setImmediate. В браузере нет метода setImmediate, в то время как в Node.js он выполняется в фазе Check, а setTimeout — в фазе Timers. Это может привести к путанице, особенно при переносе кода между Node.js и браузером.

Также стоит отметить различие в работе microtasks. В браузере микротаски выполняются сразу после каждого макротаска, а в Node.js они выполняются после каждой фазы event loop, что позволяет их более эффективно управлять и избегать блокировки цикла.

❌ Ещё одним важным отличием является рендеринг

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

Например, repaint может произойти между macrotask, microtask и снова macrotask, что важно учитывать при оптимизации производительности в браузере.

❌ Что важно помнить разработчику

• В Node.js основное внимание уделяется I/O операциям, таким как работа с файлами, сетью и процессами. Эти задачи добавляют свои очереди и обрабатываются в разных фазах event loop.
• В браузере event loop синхронизирован с частотой кадров, что критически важно для обеспечения плавности UI.
• Microtasks в Node.js ведут себя агрессивнее, особенно process.nextTick, который может заблокировать переход между фазами event loop, если заспамить его слишком большим количеством задач.
• setImmediate и setTimeout — это не одно и то же. Порядок их выполнения в Node.js зависит от контекста и фазы event loop, в которой они находятся.