Что из препроцессоров вы используете?

Question

[colorkid]

Всем привет.
Такой вопрос, всегда использовал препроцессоры 'постольку поскольку':
1 - Переменные;
2 - Синтаксис вложенности аля &__element;
3 - Цветовые функции иногда, когда дизайна нет, а на ховер затемняшку сделать нужно;
4 - 'Когда никогда', делал миксины но для супер общих правил, но это реально очень редко.

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

НО вот пришел на проект, гда фронт написан хардкорным c++'сником который заюзал sass на 100%, т.е. повсюду миксины, количество колонок в контейнере определяется через аргумент функции и т.д.

Это все конечно круто смотрится, но блин не всегда читается а во вторых если я в 10 местах использую миксин, и если в нем что-то нужно поменять, то он меняется только во всех местах, и я должен держать в голове что изменения в одном месте повлияют на изменения в 10 местах, по мне так это жесть, прибежит дизайнер скажет вот тут переделать нужно, отступ добавить, я добавлю, а то что эти правила используются еще где-то легко можно забыть, а там уже все будет выглядеть ужасно.

На сколько вы используете препроцессоры? Стараетесь ли использовать весь их функционал? И какой из них по вашему реально полезен?

Comments

[Lord_Dantes]

Изобретатель дикпиков, видимо автор имел ввиду си плюс плюсника которые полез в css)

[Rustam Bainazarov]

SASS с синтаксисом SCSS.

[Сергей delphinpro]

На сколько вы используете препроцессоры?

Примерно настолько, что приведет вас в ужас, судя по всему =)))

усложнения поиска селекторов по проекту.

Объясните мне, жалкому разработчику всего лишь с десятилетним стажем, КАК может препроцессор усложнить поиск селектора? Ну как?????
Если я придерживаюсь правила "один блок — один файл", использую сорсмапы, я всегда вижу в инспекторе браузера в каком файле и в какой строке написан стиль. Если я жму дабл-шифт в IDE, и начинаю вводить имя блока, то немедленно попадаю в нужный файл.

Может все-таки поиск усложняет не использование препроцессора, а ваше неумение правильно организовать свой код?

Answer 1

[Lord_Dantes]

Использую SASS
Нравится 2-й пункт из твоего списка и 1-й. 3-й пункт не совсем понял, 4-й не юзал так как не было такой прям надобности.

Ответы:
Я использую препроцессоры когда проект видно что большой или сайт многостраничный, а для лендосов они не нужны особо.
Ну это странный вопрос, вот ты например используешь компьютер - ты используешь все его мощности? Не понял последнего вопроса)

Answer 2

[Flying]

Использую по возможности всё что есть в Sass и хотелось бы видеть в нём больше. Активно использую и переменные и миксины и функции и placeholder'ы и list'ы и map'ы и т.п. Многие практические задачи намного легче решаются через препроцессор, те же CSS variables ни разу не замена.

Конечно для того чтобы код не превратился в кровавое месиво - необходимо соблюдать правила, но это справедливо и для любого другого языка программирования. Да и без использования препроцессоров я видел огромное количество write only css который невозможно нормально поддерживать.

Вопрос поддерживаемости - он не лежит в плоскости используемого инструмента, а является следствием наличия или отсутствия архитектуры в проекте. Если макеты дизайнера сделаны в стиле "я так вижу", без внутренней логики, если всё это сверстал верстальщик по принципу "что вижу - то и сверстал" - то никакое наличие или отсутствие препроцессора на поддерживаемость кода не повлияет.

С другой стороны наличие определённой архитектуры и следование ей в проекте даёт возможность относительно безболезненного рефакторинга стилей и оставляет код стилей поддерживаемым и расширяемым. Препроцессоры здесь только на пользу.

Answer 3

[Алексей Николаев]

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

Ну и зря. У меня на галере капитан заставляет гребцов возвращаться в 90е, т.е. когда де-юре scss, а по факту пишем по старинке, все каскады друг за другом, в одну строчку, без вложенности. Вот где мат стоит. Из аргументов как раз ваше "ну, искать селектор тяжело, если ошибка на продакшене". И не вразумить, он жи "синьор-помидор". Кекмда.

Сам использую scss, не мыслю жизни без препроцессоров. У css-переменных есть только одно преимущество: декларативность, когда меняешь переменную и все меняется сразу же. По факту, очень удобно только менять темы на лету, что напоминает мне детские игры (хотя выглядит круто). Прозрачность переменной не сделаешь. В другой тип переменную не переведешь. Куча каких-то ограничений.

Единственный путь использовать css-переменные в сложном проекте, где они используются не только для однократного присвоения значения, но и для построения сеток, для перевода px в em \ rem, для динамического формирования спрайтов и цветовых схем; нужно идти по пути усложнения. Путь этот геморроен, но достоин любителей live on the edge. Нужно сделать так, чтобы для каждой scss-переменной существовал css-собрат, и добиться их синхронизации. В итоге получаем на деве исходники с мощью scss, на проде - мощь css.

Comments

[dom1n1k]

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

Достаточно сравнить самый элементарный пример:

/* scss */
.button {
    ...
    body.theme--dark &--primary {
        background-color: $color-primary;
    }
}

/* css custom properties */
:root {
    --color-primary: blue;
}

.button {
    ...
    &--primary {
        background-color: var(--color-primary);
    }
}

Хотя соглашусь с тем, что css-переменные совершенно не отменяют препроцессорных переменных. В каких-то случаях удобнее одно, в других вдругое.