🔘 Делай pet-проекты короткими и законченными.
Маленький тул или демо — лучше, чем вечный “стартап мечты”.
🔘 Ставь себе ограничение по времени.
Например, кодишь только 2 вечера в неделю.
🔘 Не чувствуй вины, если не делаешь ничего.
Отдых — тоже часть продуктивности.
Мой личный опыт:
Pet-проекты реально помогают не терять интерес к коду.
Но только когда они не конкурируют с отдыхом, а заменяют бессмысленный скролл YouTube чем-то, что тебя вдохновляет.

- Объём: до ~5MB
- Синхронный API (блокирует поток)
- Только строки

✅ Идеально для:

- Настроек интерфейса (тема, язык)
- Состояния, не критичного к потере

🙅‍♂️ Не подходит для:

- Частых записей
- Больших данных
- Асинхронных операций

🔘Частая ошибка: хранить JWT или токены авторизации.
Не делай так — XSS и ты в опасности. Лучше HttpOnly cookie.

- Асинхронная, ключ-значение база прямо в браузере
- Поддерживает сложные структуры (объекты, Blob, файлы)
- Работает оффлайн

✅ Идеально для:

- SPA с оффлайн-режимом
- Кеширования запросов
- Локальных кэшей для heavy UI (например, таблицы на тысячи строк)

🙅‍♂️ Минусы:

- API громоздкий (лучше использовать обёртки вроде Dexie.js)
- Не всегда очевидное управление версиями

Используется вместе с Service Worker.
Позволяет сохранять ответы от fetch и выдавать их оффлайн.

✅ Идеально для:

- PWA и offline-first приложений
- Кэширования статики (CSS, JS, картинки)
- Быстрых перезапусков SPA

🙅‍♂️ Не путай с LocalStorage — это не просто “сохранил строку”, а полноценный HTTP-кеш.

🔘Комбинируй: IndexedDB для данных, Cache для запросов, LocalStorage для мелочей.
🔘Удаляй устаревшие версии данных (особенно при обновлении схем).
🔘Не храни чувствительные данные — браузер ≠ сейф.
🔘Проверяй лимиты хранилища (navigator.storage.estimate() — underrated).
🔘Используй Background Sync, если нужно синхронизировать оффлайн-данные.

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

Mozilla когда-то начала этот путь с Project Quantum (оптимизация движка Firefox), и идея живёт:
браузер сам решает, как рендерить части DOM параллельно и какие CSS-правила реально нужны в viewport.

Главная цель:
ускорить перерисовку и минимизировать “CSS-инфляцию” — когда у проекта тысячи неиспользуемых классов и стилей.

ML-модели уже умеют анализировать структуру страницы и:

выявлять дублирующиеся CSS-паттерны;

предлагать оптимальную архитектуру классов (например, по BEM или atomic-подходу);

предсказывать layout shifts и предлагать фиксы для CLS;

автоматически “чистить” стили после деплоя (CSS pruning с учётом поведения реальных пользователей).

Через пару лет мы можем прийти к IDE, которая:

💛 отслеживает реальное использование на проде,

💛 сама обучается оптимизировать layout.

Типа “GitHub Copilot для CSS”, но с реальной экономией трафика и FPS.

CSS медленно превращается из “ручного ремесла” в систему адаптивной оптимизации.
И если сейчас мы думаем “как проще написать стили”,
то скоро будем думать “как обучить модель писать и обслуживать их за нас”.

Позволяет работать с файлами прямо на диске пользователя — читать, писать, сохранять без танцев с input[type=file].
Почти VS Code в браузере.
Отлично подходит для локальных редакторов, playground'ов, PWA-приложений.
Но важно: требует HTTPS и согласия пользователя (пожалуй это и хорошо).

const handle = await window.showSaveFilePicker();
const stream = await handle.createWritable();
await stream.write("Hello world!");
await stream.close();

Уже давно не просто document.execCommand('copy').
Можно копировать/вставлять не только текст, но и изображения, HTML, JSON.
Если делаете дашборд, таблицы, визуальные тулзы — must have.

await navigator.clipboard.writeText("Copied!");
const image = await navigator.clipboard.read();

Штука, которая превращает ваш сайт в «родное» приложение.
Позволяет вызвать системное окно шаринга (например, переслать ссылку в Telegram или Mail прямо из браузера).
Особенно удобно для мобильных PWA.

await navigator.share({
noscript: "Frontend Magic",
text: "Проверь этот пост!",
url: location.href
});

✅ Метод «Википедии»
Не можете найти общий язык с коллегами? Заведите раздел в корпоративной вики, где будете подробно описывать все «косяки» ваших товарищей. Скриншоты, временные метки и даже свидетели – всё в помощь! Через год у вас будет целая энциклопедия непроверенных данных, а новые сотрудники точно оценят вашу внимательность. Главное — не забывайте развивать «историю».

✅ Техника «Zoom-бомбинга»
Следующий уровень: не бояться вмешиваться в чужие встречи. Особенно когда это ретроспективы других команд. Ну, а если коллега с начальником один на один? Скажите, что у вас «появился важный вопрос», и добавьтесь в Zoom-сессию. Так вы точно «услышите» не только своё мнение.

✅ Стратегия «Героического непонимания»
Получил задачу, которую сразу не понял? Не спеши спрашивать. Поищи ошибки в коде, перепиши часть проекта и создай несколько гипотез. И только когда дедлайн уже на носу, напиши в чат: «Кто-нибудь понимает, о чём речь?» Ты же герой, и время для вопросов настало лишь накануне релиза.

✅ Метод «Git-археологии»
Каждая ошибка коллеги должна стать поводом для расследования. И неважно, что это было два года назад. «А вот в коммите от марта ты сделал то же самое!» Найди старые косяки и просто забудь про свой собственный вклад в проект.

✅ Стратегия «Собеседование саботажа»
Приехали на собеседование? Отлично! Теперь нужно создать атмосферу для будущих разработчиков. Садитесь в телефоне, задавайте вопросы, не относящиеся к теме, и жалуйтесь на отсутствие талантов. Главное — дайте понять, что молодёжь не та.

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

✅ Кросс-браузерность и адаптивность: Интерфейс может выглядеть идеально в Chrome, но ломаться в Safari или на мобильном. С тестами таких проблем можно избежать, проверяя поведение компонентов на разных устройствах и браузерах.

✅ UI/UX баги: Строго говоря, это не «классовые» баги, а проблемы, которые влияют на восприятие приложения. Несоответствие дизайну, неправильные анимации — всё это может уйти незамеченным в процессе обычного тестирования, но сказаться на восприятии вашего продукта.

👀 Cypress: Простой и мощный инструмент для энд-ту-энд тестирования. Он позволяет тестировать, как ваш интерфейс ведет себя в реальных сценариях: клики, заполнение форм, навигация, и многое другое. Cypress особенно удобен для динамичных SPA-приложений, где важно протестировать все возможные переходы и взаимодействия.

👀 Если вам нужно больше гибкости, попробуйте Playwright. Он поддерживает тестирование нескольких браузеров и идеально подходит для тестирования UI на разных платформах, таких как Chrome, Firefox и WebKit. А ещё, в отличие от Cypress, Playwright поддерживает тестирование мобильных устройств из коробки.

👀 React Testing Library: Если вы работаете с React, этот инструмент поможет вам тестировать компоненты с учётом пользовательских взаимодействий. Он фокусируется на тестах, которые проверяют не только логику, но и правильное поведение в контексте UI. Например, как компоненты реагируют на пользовательский ввод или как они отображаются при разных состояниях.

👀 В случае, если вам нужно тестировать поведение интерфейса в браузере, Puppeteer — это тот инструмент, который поможет вам автоматизировать тесты в реальных браузерах. Это идеальный выбор для UI-тестов, где важен контроль над браузерными событиями и точность.

// Представьте, что вам нужно отследить, кто и когда обращается к объекту. Вместо того чтобы забивать код десятками console.log, можно просто использовать Proxy для перехвата. Теперь любое обращение к объекту будет логироваться. Это очень удобно, если вы работаете с большими стейтами, как в Vue или MobX.

const user = { name: "Alex", age: 25 };

const loggedUser = new Proxy(user, {
get(target, prop) {
console.log(`GET ${prop}`);
return Reflect.get(target, prop);
},
set(target, prop, value) {
console.log(`SET ${prop} = ${value}`);
return Reflect.set(target, prop, value);
}
});

loggedUser.name; // GET name
loggedUser.age = 26; // SET age = 26

// Proxy может отловить некорректные значения и не дать им попасть в бизнес-логику. С таким подходом можно сделать простые data-models без классов и лишнего кода. Валидация и контроль за данными — проще не бывает.

const product = new Proxy({}, {
set(target, prop, value) {
if (prop === 'price' && value < 0) {
throw new Error("Цена не может быть отрицательной");
}
return Reflect.set(target, prop, value);
}
});

// Reflect — набор методов для безопасной работы с объектами. Они выполняют стандартные операции, но предотвращают неожиданные ошибки и обеспечивают предсказуемое поведение.

Reflect.get(obj, 'key'); // вместо obj.key
Reflect.set(obj, 'key', 'value'); // возвращает true/false, не выбрасывает ошибки

// Комбо с Proxy выглядит так:
const safe = new Proxy(obj, {
get: (t, p) => Reflect.get(t, p),
set: (t, p, v) => Reflect.set(t, p, v)
});

<!-- В классическом CSS мы описываем сущности. Utility-first CSS — это немного другой подход. Вместо того чтобы описывать компоненты, мы описываем свойства. Каждый класс — это атомарная единица стиля, которая выполняет одно действие. Когда нужно собрать сложный элемент, мы комбинируем несколько таких атомов, чтобы получить нужный результат -->

<button class="bg-black text-white rounded-lg px-4 py-2">Click</button>

• Открыл HTML и сразу видишь, как выглядит элемент. Нет нужды прыгать по CSS-файлам, чтобы понять, как что-то стилизовано.

• Изолированность без сложных каскадов. Нет таких длинных цепочек, как .card .button.active:hover. Всё работает локально и предсказуемо.

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

• Если нужно изменить отступы, это быстрее, чем искать, где в CSS заданы padding. Например, меняем класс px-4 на px-6 и сразу видим результат.

Этот подход можно применить и без фреймворка.

— Заведи слой утилит в обычном CSS:

.flex { display: flex; }
.gap-2 { gap: 0.5rem; }
.text-sm { font-size: 14px; }

— Используй CSS custom properties для хранения токенов, как --color-primary, --space-sm.
— Используй PostCSS или UnoCSS, чтобы собирать утилиты динамически.

Если команда не договорится об atomic naming и начнёт использовать названия вроде text-12px flex1 mt-8px, это может привести к путанице и усложнить понимание кода. Особенно это критично в проектах без дизайн-системы, где утилиты могут превратиться в хаос. В таких ситуациях лучше использовать гибридный подход, комбинируя утилитарный стиль с обычными компонентами, чтобы обеспечить масштабируемость и переиспользование блоков.

Вы наверняка знаете, что :not() используется для исключения элементов с определенным классом или позицией в списке. Например, стиль применяется ко всем элементам .link, кроме последних в списке. Однако :not() позволяет комбинировать несколько условий. Код применяет стиль ко всем img без атрибута class и не являющихся первыми детьми в родительском элементе. Это возможно благодаря тому, что :not() принимает несколько селекторов, разделённых запятыми.

/* Базовое применение */
.link:not(:last-child) {
margin-left: 1rem;
}

/* Применение для всех img, кроме тех, у которых есть атрибут class */
img:not([class], :first-child) {
margin-block-start: var(--ds-typography-img-margin-block-start, var(--_ds-typography-main-margin));
}

Что если вы хотите применить стиль только к тем элементам, которые не содержат в себе определённого соседа? Это легко сделать, используя комбинацию :not() и :has(). В примере стиль background-color: lightblue применяется ко всем параграфам <p>, за которыми не следует элемент <h2>. Это позволяет точно контролировать, какие элементы подвергать стилизации, не добавляя лишних классов или элементов разметки.

<body>
<h1>Париж</h1>
<p>Столица и крупнейший город Франции...</p>
<h2>История</h2>
<p>Париж вырос на месте поселения...</p>
<p>Поселение располагалось на безопасном острове...</p>
</body>

/* Применяем стиль только к параграфам, за которыми не следует элемент h2 */
p:not(:has(+ h2)) {
background-color: lightblue;
}

Псевдо-класс :not() — это просто огонь-фича для тех, кто любит делать код проще и понятнее. Он позволяет исключать элементы по разным условиям, что значительно упрощает создание сложных селекторов. В отличие от старых методов, :not() даёт вам больше свободы и точности.

С его помощью можно создавать более чистые и понятные разметки, которые легко подстраиваются под изменения в структуре документа. Это как улучшенная версия селекторов :first-child или :last-child, только с гораздо большими возможностями.

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

✅ Кросс-браузерность и адаптивность: Интерфейс может выглядеть идеально в Chrome, но ломаться в Safari или на мобильном. С тестами таких проблем можно избежать, проверяя поведение компонентов на разных устройствах и браузерах.

✅ UI/UX баги: Строго говоря, это не «классовые» баги, а проблемы, которые влияют на восприятие приложения. Несоответствие дизайну, неправильные анимации — всё это может уйти незамеченным в процессе обычного тестирования, но сказаться на восприятии вашего продукта.

👀 Cypress: Простой и мощный инструмент для энд-ту-энд тестирования. Он позволяет тестировать, как ваш интерфейс ведет себя в реальных сценариях: клики, заполнение форм, навигация, и многое другое. Cypress особенно удобен для динамичных SPA-приложений, где важно протестировать все возможные переходы и взаимодействия.

👀 Если вам нужно больше гибкости, попробуйте Playwright. Он поддерживает тестирование нескольких браузеров и идеально подходит для тестирования UI на разных платформах, таких как Chrome, Firefox и WebKit. А ещё, в отличие от Cypress, Playwright поддерживает тестирование мобильных устройств из коробки.

👀 React Testing Library: Если вы работаете с React, этот инструмент поможет вам тестировать компоненты с учётом пользовательских взаимодействий. Он фокусируется на тестах, которые проверяют не только логику, но и правильное поведение в контексте UI. Например, как компоненты реагируют на пользовательский ввод или как они отображаются при разных состояниях.

👀 В случае, если вам нужно тестировать поведение интерфейса в браузере, Puppeteer — это тот инструмент, который поможет вам автоматизировать тесты в реальных браузерах. Это идеальный выбор для UI-тестов, где важен контроль над браузерными событиями и точность.

Анимация свойств, таких как 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;
}

<<!-- Первое поле с логином зелёное (корректно заполнено). Второе поле с паролем красное (пусто и недействительно) -->
<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>

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

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