HTML, CSS и JavaScript

Семантический HTML — это выбор элементов по смыслу, а не по внешнему виду: <nav> для навигации, <button> для действий, <h2> для заголовка раздела, <table> для табличных данных. Браузер и вспомогательные технологии используют этот смысл. Скринридер может перечислить заголовки и landmark-области, чтобы пользователь прыгал по странице; настоящая кнопка получает фокус с клавиатуры и правильно озвучивается без дополнительного кода; поисковики понимают структуру и основной контент. Ещё это сокращает код, потому что поведение вы получаете бесплатно, а не воссоздаёте его через JavaScript и ARIA. Стилизация отделена, поэтому семантический элемент может выглядеть как угодно.

Flexbox — для одного измерения: ряд или колонка элементов, размер которых в основном определяется их содержимым, — навигационные панели, тулбары, группы кнопок или переносящиеся списки тегов. Grid — для двух измерений: когда нужно сначала задать строки и колонки, а потом разместить в них элементы, — раскладки страниц, галереи товаров и дашборды. Grid также даёт адаптивные колонки без media queries через repeat(auto-fill, minmax(...)). На практике я использую оба на каждой странице: Grid для общей структуры и списков карточек, Flexbox для выравнивания внутри каждого компонента. Оба поддерживают gap, который я предпочитаю margin'ам между элементами.

Когда вы кликаете по элементу, событие сначала спускается от document к целевому элементу (фаза перехвата), а затем всплывает обратно через каждого предка. Поэтому слушатели на родителях «слышат» клики по потомкам. Делегирование событий этим пользуется: вместо того чтобы вешать слушатель на каждую строку длинного списка, вы вешаете один слушатель на список и проверяете event.target, обычно через closest(), чтобы найти нужного потомка. Это экономит память и автоматически работает для элементов, добавленных позже. Остановить распространение можно через stopPropagation(), но делайте это осторожно, потому что это ломает другой код, который полагается на всплытие, — например, аналитику или обработчики клика вне элемента.

По умолчанию (content-box) width и height задают только область содержимого, а padding и border добавляются сверху. Блок шириной 300 пикселей с padding 20 пикселей и рамкой в 1 пиксель на самом деле имеет ширину 342 пикселя, что запутанно ломает раскладку. С border-box ширина включает padding и border, поэтому блок ровно 300 пикселей, а содержимое сжимается, чтобы поместиться. Это совпадает с тем, как думают дизайнеры, и делает раскладки на процентах предсказуемыми. Почти каждый современный CSS-reset применяет border-box ко всем элементам и псевдоэлементам, и я делаю так же в каждом проекте.

Потому что с точки зрения fetch запрос удался: он дошёл до сервера и получил валидный HTTP-ответ. fetch отклоняет промис, только когда запрос вообще не удалось выполнить — например, нет сети, не сработал DNS, запрос заблокировал CORS или его отменили. HTTP-статусы ошибок — это обычные ответы, которые нужно проверять самостоятельно через response.ok (true для 200–299) или response.status. Я оборачиваю fetch в небольшой хелпер, который проверяет ok, разбирает JSON, бросает типизированную ошибку со статусом и телом и поддерживает AbortSignal и таймаут, чтобы остальной код никогда не забывал эти проверки.

Я делю её на слои с разным сроком жизни. Основа — дизайн-токены: цвета, отступы, типографика, радиусы и анимация, хранящиеся как данные и экспортируемые как CSS custom properties, так что ими может пользоваться любой фреймворк или даже чистый HTML, а темы — это просто другие значения. Поверх идут соглашения CSS: каскадные слои, имена классов с низкой специфичностью и задокументированные брейкпоинты. Компоненты идут последними и сильнее всего завязаны на фреймворк; они строятся на нативных элементах ради доступности. Компромисс здесь между гибкостью и единообразием: строгие компоненты держат продукты одинаковыми, но раздражают команды с особыми потребностями, поэтому я разрешаю композицию и задокументированные «лазейки» вместо бесконечных props. Версионирование тоже важно: токены меняются редко и безопасно, а API компонентов требует semver и заметок о миграции, поэтому по возможности я выпускаю их отдельно.

INP измеряет задержку от взаимодействия до следующего кадра, поэтому причина всегда в занятом главном потоке: до запуска обработчика (input delay), в самом обработчике (processing) или в рендеринге после него (presentation delay). Я начинаю с полевых данных — real-user monitoring или библиотека web-vitals с атрибуцией, — чтобы найти медленные взаимодействия и элементы, потому что лабораторные тесты редко их воспроизводят. Затем воспроизвожу с замедлением CPU в панели Performance. Исправления зависят от фазы: удалите или отложите сторонние скрипты, создающие long task'и; разбейте длинные обработчики и делайте yield между частями; сначала обновляйте UI, а дорогую работу выполняйте потом; избегайте layout thrashing; уменьшайте размер DOM и используйте content-visibility для длинных секций за пределами экрана. В React-приложениях так же помогают transitions и более узкие области перерендера.

Оно того стоит везде, где отказ дорог, а JavaScript может не сработать: checkout, регистрация, формы поиска и обратной связи, а также контент, который должен индексироваться. JavaScript ломается чаще, чем думают команды: на медленных сетях запросы отваливаются по таймауту, расширения ломают скрипты, старым устройствам не хватает памяти, а одна ошибка в рантайме может остановить весь бандл. Форма, которая отправляется как обычный HTML и улучшается клиентской валидацией и мгновенной обратной связью, продолжает работать во всех этих случаях. Современные фреймворки делают это дешевле, чем раньше, потому что server actions и нативная отправка форм работают без гидрации. Компромисс в том, что высокоинтерактивные инструменты — редакторы, карты, дашборды — мало выигрывают от запасного варианта без JavaScript, поэтому я применяю progressive enhancement к критичным сценариям, а не как общее правило.