Когда я начал изучать Svelte, то одним из первых моих дел был поиск возможностей применения в этом фреймворке CSS-препроцессоров. Как-то повелось во фронтенде, что владение знаниями написания стилей в SASS, Less или Stylus является отличительной чертой первоклассного разработчика. Вроде и в вакансиях везде требуется и на собеседованиях спрашивают. Ответ на свой вопрос о совместимости Svelte и препроцессоров я нашел, но на этом сайте использовать ни один из них не стал. Потому что вспомнил свой pet-опыт.

Про самовары и готовые решения

Когда-то не так давно я подумал, что хочу создать свой CSS-фреймворк, чтобы как Bootstrap, но посовременнее и полегче и для себя любимого. Начал писать его на обычном CSS, потом понял что от однообразия в некоторых моментах, можно сойти с ума и начал искать решение по сокращению количества описываемых мной строк кода. SASS в синтаксисе SCSS пришелся весьма кстати. Я изучал самый популярный препроцессор и писал свой фреймворк, мне нравился этот процесс и магия, с помощью которой SCSS превращал едва понятную абракадабру в привычные всем нам правила и объявления. Свой фреймворк я почти закончил, его код лежит на Гитхабе, но использовать в деле я его не стал, справедливо решив, что в «Тулу со своим самоваром не ездят», как и в мир множества готовых решений со своим готовым решением. Зато эта практика стала отличным селф-курсом для изучения такой дико интересной штуки как SASS.

Чуть позже я занялся другим пет-проектом. Делал журнальную тему на Ghost, используя полуготовый стартер с Gulp на борту. SCSS шел ко всему этому бонусом. Я думал, что разойдусь или разбегусь и как начну клепать миксины, циклы, функции и остальное фишки препроцессора, но на деле вышло, что кроме вложенности я больше ничего для этого проекта не использовал.

Тогда я задумался вообще о необходимости использования препроцессоров. Те же вложенные правила можно вообще не использовать, потому что разница в коде с ней и без нее практически неощутима. Я также вспомнил, что выбрал SCSS потому что его синтаксис с отступами и фигурными скобками максимально похож на синтаксис чистого CSS. Вероятно именно по этой причине SCSS выбирает большинство разработчиков в качестве инструмента для написания стилей в своих проектах. То есть хочется писать код на знакомом языке, и при этом не усложнять его.

Про время и скорость

При правильном использовании, препроцессоры помогают делать код более гибким. Например в больших проектах писать чистым CSS может быть сложнее, чем с помощью того же SASS. Однако последний может создавать и немалые проблемы. Ваш CSS до компиляции и после может существенно отличаться как по размеру так и сущностно. По этой причине искать ошибки и делать мелкие исправления может быть сложнее. Особенно если вы взяли проект на доработку, исправления или подключились к команде на поздних стадиях разработки.

Самые торопливые разработчики знают, что препроцессоры вызывают небольшие задержки в процессе работы, поскольку компиляция кода в CSS требует какое-то время. Пара секунд, конечно, не критичны, но факт остается фактом.

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

Еще одну интересную проблему, указанную Веру, хотелось бы затронуть отдельно. Речь идет о привыкании разработчиков к препроцессорам. Даже если необходимость в них отсутствует, то многие разработчики продолжают их использовать по инерции. Книга “Секреты CSS…” писалась в середине 10-х годов и тогда некоторые функции в нативном CSS, указанные автором как “вдохновленные препроцессорами”, были только в черновике спецификации. Но сегодня переменные и, например, вычислительные функции уже во всю используются в производстве. Переменные CSS чрезвычайно удобны, но, тем не менее, и сейчас встречаются проекты, где переменные задаются в файлах препроцессора, а не в CSS.

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

app.css
ul {
    --accent-color: purple;
}

ol {
     --accent-color: rebeccapurple;
}

li {
    background: var(--accent-color);
}

Здесь мы сначала определяем одну переменную для упорядоченного и не упорядоченного списка в виде разных цветов. А затем подставляем значение этой переменной в качестве фонового цвета для элементов li этих списков. Причем нам не нужно уточнять какой именно вид списка мы имеем ввиду. Первые две строки уже все определили.

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

Это не мои слова, а слова все той же Леа Веру. Она, кстати, не последний человек в CSS, и является научным сотрудником в Лаборатории компьютерных наук и искусственного интеллекта Массачусетского технологического института (MIT), избранным участником Группы технической архитектуры Консорциума Всемирной паутины (W3C) и приглашенным экспертом в рабочей группе CSS W3C.

Принцип DRY - это аббревиатура от фразы «Don’t Repeat Yourself» («Не повторяйтесь»). Эта концепция была впервые сформулирована в книге Энди Ханта и Дэйва Томаса «Программист-прагматик: путь от подмастерья к мастеру». Из названия понятно, что данный принцип говорит о том, что нужно проанализировать свой код и избавить его от повторяющихся элементов. Это не только про CSS, а вообще про весь код, который может быть в проекте.

Про себя и других

Читая некоторые блоги разработчиков из самых разных отраслей, я не раз натыкался на их слова о том, что перед началом работы нужно настроить окружение проекта. Сами они делали это не единожды и у каждого есть свой персональный набор инструментов, в который в большинстве случаев входит и их любимый препроцессор. Нужен он проекту или не нужен, вообще не вопрос. У человека все настроено, не приставайте со своими пожеланиями. Та же Веру призывает не впадать в зависимость от препроцессоров, и не допускать ситуации, когда подключение препроцессора является “бездумным первым шагом, который по умолчанию делается в каждом новом проекте”.

Мне кажется, что с подобными инструментами, нужно быть осторожнее, ведь можно не заметить, как в чистом CSS появится классная опция, которая отменит какую-нибудь препроцессорную фичу. Перед началом работы нужно хорошенько подумать и решить действительно ли Вам нужен препроцессор в данном проекте, или можно обойтись без него.

Ряд своих проектов я периодически оптимизирую, если нахожу время. На данном сайте планирую в ближайшее время как раз поработать со стилями, облегчив пул глобальных правил, сделав их более локальными. Там где это возможно, конечно. Возможно стоить поэкспериментировать с экспортом стилей на страницы в отдельных css-файлах, а не прописывать их в теге <style>.