Какие подходы к написанию стилей используются в проектах?
Что проверяют
Хотят понять, выбирали ли вы подход к стилям осознанно или писали так, как было заведено в проекте. Следом почти всегда спрашивают, что вы взяли бы в новый проект на React с серверным рендерингом и почему.
Как отвечать
Назовите основные семейства и у каждого сильную и слабую сторону:
- глобальный CSS и БЭМ: классы вида
button__icon,button--primaryрешают конфликты имён договорённостью. Работает без сборки, но держится только на дисциплине команды; - препроцессоры (Sass, Less): переменные, миксины, вложенность. В Sass сейчас пишут через
@useи@forward,@importобъявлен устаревшим; - CSS Modules: сборщик превращает класс в уникальное имя, стили изолированы на уровне файла, рантайма нет. Разумный выбор по умолчанию для компонентного проекта;
- CSS-in-JS в рантайме (styled-components, Emotion): стили удобно менять от пропсов, но они вычисляются в браузере, растёт бандл, плохо сочетается с React Server Components. styled-components с 2025 года в режиме поддержки;
- CSS-in-JS без рантайма (vanilla-extract, Linaria, Panda CSS): типизированные стили в TypeScript, на выходе обычный CSS-файл;
- utility-first (Tailwind CSS): классы прямо в разметке, токены дизайна в одном месте, в четвёртой версии настройка переехала в CSS через
@theme. Быстро, но разметка становится многословной.
Добавьте, что нативный CSS сильно вырос: custom properties для тем, вложенность, @layer для управления каскадом, @container для адаптивности по размеру компонента. Закончите своим проектом: какой подход там был, как делали тёмную тему и что бы поменяли.
Где спотыкаются
Перечисляют Flexbox, Grid и медиазапросы как «подходы к написанию стилей». Это средства вёрстки, а вопрос про организацию и изоляцию стилей.
Хвалят runtime CSS-in-JS и не знают его цены: лишний JavaScript, работа на каждом рендере, проблемы с серверными компонентами.
Не могут объяснить, как в выбранном подходе устроены темы и переопределение стилей чужого компонента, хотя именно это спрашивают следом.