С какими подходами по стилям в frontend вы работали
Что проверяют
Понимаете ли вы, что все подходы к стилям решают одну задачу, изоляцию и предсказуемость каскада, и умеете ли назвать цену каждого. Заодно смотрят, следите ли вы за тем, как серверный рендеринг изменил расклад.
Как отвечать
Разложите подходы по тому, как они изолируют стили.
- Соглашение об именах: БЭМ поверх обычного CSS или SCSS. Изоляции нет, есть дисциплина, зато работает где угодно и ничего не стоит во время выполнения.
- Препроцессор: SCSS с переменными, вложенностью и миксинами. Сегодня половину этого умеет сам CSS: пользовательские свойства, вложенность, слои каскада, контейнерные запросы.
- Модули CSS: имена классов уникализирует сборщик, изоляция настоящая, ничего не считается в браузере. Дешёвый и предсказуемый вариант по умолчанию.
- Стили в JS: styled-components и Emotion дают стили, зависящие от пропсов, но платят рантаймом, лишним весом бандла и плохо уживаются с серверными компонентами.
- Нулевой рантайм: vanilla-extract, Linaria и подобные, тот же удобный синтаксис, но всё вычисляется на сборке.
- Утилитарный подход: Tailwind, стили пишутся классами прямо в разметке, споры об именах пропадают, взамен разметка становится шумной.
Отдельно скажите про темы и токены: цвета и отступы держатся в пользовательских свойствах, и переключение темы тогда не требует пересборки.
Где спотыкаются
Перечисляют подходы как моду, без цены. На вопрос «почему здесь модули, а не стили в JS» отвечают привычкой, хотя разница измеримая: вес рантайма, момент вычисления стилей и поведение при серверном рендеринге.
Второе: борются со специфичностью через !important и глубокую вложенность селекторов. Через полгода это превращается в гонку приоритетов, которую не выигрывает никто, а лечится изоляцией на уровне сборки или слоями каскада.
Третье: тащат рантаймовые стили в JS в приложение с серверным рендерингом и получают мигание неоформленного содержимого и клиентскую границу там, где она не была нужна.