Остается ли Sass актуальным? Кажется, что этот вопрос возникает каждые несколько месяцев. Совсем недавно Джереми Кит в своем докладе на CSS Day предположил, что Sass устарел.
Я думаю, он хотел сказать, что Sass помог развитию веба (что очень верно). Но называть его полифиллом - абсурд.
Так что давайте еще раз взглянем на Sass и некоторые вещи, для которых он все еще полезен в 2022 году.
Функция
Допустим, мы хотим вычислить размер, полученный из других длин. Это обычное требование для выравнивания одного элемента (например, логотипа заголовка) относительно другого (например, боковой панели). Мы можем написать что-то вроде:
Это удобно, если мы используем жидкие размеры (а-ля Utopia).
Но что, если мы уже знаем размеры заранее? Тогда, вероятно, мы можем выполнить расчет заранее.

Я за то, чтобы позволить браузеру делать свою работу, но для этого он должен фактически загрузить код. И мы вообще должны стремиться отправлять клиенту меньше кода, если это возможно.
Вот тут-то и приходит на помощь Sass. Если мы можем статически получить доступ к этим размерам (например, в пикселях или в rems), то Sass может сгенерировать конечный результат за нас.
Это был очень маленький пример, но мы можем легко экстраполировать его на всю нашу кодовую базу. Представьте, если бы у нас было пользовательское свойство для каждой мелочи в каждом уголке нашего сайта.
Прелесть Sass в том, что он "компилируется", а это значит, что мы можем писать самый выразительный, читабельный, даже многословный код, не беспокоясь об отправке лишних байт в браузер.
Эта статичность Sass раньше считалась "ограничением", но вот в чем дело: то, что CSS добавляет возможности, которые раньше были эксклюзивными для Sass, не означает, что мы должны полностью переходить на один вариант и перестать использовать другой. Когда мы осознаем их различия, мы сможем использовать их вместе, чтобы получить лучшее из обоих миров.
Допустим, у нас есть набор маркеров дизайна. Мы можем определить их все как переменные Sass на верхнем уровне, даже если не все из них еще используются, потому что они будут удалены во время компиляции.
Если мы создаем компонент, который по умолчанию должен выглядеть прилично, но при этом должен быть настраиваемым, то мы можем использовать переменные CSS.
Это позволит нам (или нашим пользователям) выполнять настройки без необходимости изменять какие-либо фактические свойства. Мы даже можем предложить хороший API для этих пользовательских свойств с помощью JavaScript (например, React props), что значительно упростит их использование.
Несмотря на то, что вложенность скоро появится в CSS, версия Sass уже здесь, и у нее больше возможностей, чем у вложенности в CSS.
Например, в Sass нам не нужен символ &, что делает его более интуитивным.
И мы можем вложить медиа-запросы внутрь селекторов.
И мы можем использовать вложенность для создания инкрементных имен классов.
Sass также имеет функции, в том числе несколько удобных встроенных. Особенно полезен модуль цвета.
Сегодня мы не можем сделать ничего подобного в CSS.
Очень распространенным примером является тематизация, где нам нужно использовать каскад для обработки каждой темы, используя как запрос предпочтений (для ОС), так и в качестве переопределения (для пользовательского переключателя тем). Представьте себе, что мы дублируем десятки переменных и забываем обновить одну из них в будущем.
Sass позволяет нам справиться с этим довольно элегантно.
Мы даже можем поместить эти тематические миксины в отдельные файлы и импортировать их гранулированно, чего мы пока не можем сделать с чистым CSS.
И, конечно, в Sass есть циклы, условия и интерполяция, которые позволяют нам генерировать "варианты" очень быстро.
Из-за такого низкого трения трудно сказать "нет" Sass, учитывая всю ценность, которую он предоставляет без особых затрат.
По моему опыту, PostCSS может быть достаточно для небольших проектов, но Sass действительно сияет в масштабе, где он почти служит как связующее звено.
И несмотря на некоторое совпадение, я считаю, что эти инструменты служат для разных нужд. Кроме того, они отлично работают вместе, позволяя нам использовать лучшие стороны обоих инструментов.
"Великий инструмент становится настолько успешным, что устаревает. Они как R&D для веб-платформы и становятся полифиллами, когда их внедряют в браузеры".
— @adactio #cssday
— @Una, June 9, 2022
Я думаю, он хотел сказать, что Sass помог развитию веба (что очень верно). Но называть его полифиллом - абсурд.
Так что давайте еще раз взглянем на Sass и некоторые вещи, для которых он все еще полезен в 2022 году.
Sass предназначен для статичиских вещей
Мы не можем "запустить" CSS вне браузера. Так и задумано, поскольку одна и та же строка CSS может означать совершенно разные вещи в разных контекстах. Но это также означает, что мы должны заставить браузер делать все эти вещи, даже если они могут быть сделаны статически.Функция
calc
в сочетании с пользовательскими свойствами часто используется в качестве примера функции, которая делает Sass устаревшим.Допустим, мы хотим вычислить размер, полученный из других длин. Это обычное требование для выравнивания одного элемента (например, логотипа заголовка) относительно другого (например, боковой панели). Мы можем написать что-то вроде:
width: calc(var(--icon-size) + var(--padding) * 2 + var(--border-width) * 2);
Это удобно, если мы используем жидкие размеры (а-ля Utopia).
calc
- идеальный инструмент, когда наши длины представлены в смеси различных единиц измерения.Но что, если мы уже знаем размеры заранее? Тогда, вероятно, мы можем выполнить расчет заранее.

Я за то, чтобы позволить браузеру делать свою работу, но для этого он должен фактически загрузить код. И мы вообще должны стремиться отправлять клиенту меньше кода, если это возможно.
Вот тут-то и приходит на помощь Sass. Если мы можем статически получить доступ к этим размерам (например, в пикселях или в rems), то Sass может сгенерировать конечный результат за нас.
Код:
// outputs final value, e.g. width: 68px
width: $icon-size + $padding * 2 + $border-width * 2;
Это был очень маленький пример, но мы можем легко экстраполировать его на всю нашу кодовую базу. Представьте, если бы у нас было пользовательское свойство для каждой мелочи в каждом уголке нашего сайта.
Прелесть Sass в том, что он "компилируется", а это значит, что мы можем писать самый выразительный, читабельный, даже многословный код, не беспокоясь об отправке лишних байт в браузер.
Sass может работать совместно с современным CSS
Функции CSS часто более мощные, чем эквиваленты Sass. Несколько очевидный пример: CSS-переменные (пользовательские свойства) существуют во время выполнения и могут изменяться динамически, в то время как переменные Sass существуют только во время сборки.Эта статичность Sass раньше считалась "ограничением", но вот в чем дело: то, что CSS добавляет возможности, которые раньше были эксклюзивными для Sass, не означает, что мы должны полностью переходить на один вариант и перестать использовать другой. Когда мы осознаем их различия, мы сможем использовать их вместе, чтобы получить лучшее из обоих миров.
Допустим, у нас есть набор маркеров дизайна. Мы можем определить их все как переменные Sass на верхнем уровне, даже если не все из них еще используются, потому что они будут удалены во время компиляции.
Код:
$border-radius-1: 2px;
$border-radius-2: 4px;
// ...
$background-1: hsl(0 0% 0%);
$background-2: hsl(0 0% 10%);
// ...
Если мы создаем компонент, который по умолчанию должен выглядеть прилично, но при этом должен быть настраиваемым, то мы можем использовать переменные CSS.
Код:
border-radius: var(--button-border-radius, #{$border-radius-1});
background: var(--button-background, #{$background-2});
Это позволит нам (или нашим пользователям) выполнять настройки без необходимости изменять какие-либо фактические свойства. Мы даже можем предложить хороший API для этих пользовательских свойств с помощью JavaScript (например, React props), что значительно упростит их использование.
Код:
<Button borderRadius={3} background='rebeccapurple'>Hi</Button>
Sass добавляет множество "приятных" функций
В Sass есть вложенность и комментарии с двойной косой чертой. По моему мнению, только за это стоит заплатить.Несмотря на то, что вложенность скоро появится в CSS, версия Sass уже здесь, и у нее больше возможностей, чем у вложенности в CSS.
Например, в Sass нам не нужен символ &, что делает его более интуитивным.
Код:
button {
svg { // instead of & svg
// ...
}
}
И мы можем вложить медиа-запросы внутрь селекторов.
Код:
button {
&:is(:hover,:focus) {
@media (prefers-reduced-motion: no-preference) {
transition: transform 0.2s;
transform: translateY(4px);
}
}
}
И мы можем использовать вложенность для создания инкрементных имен классов.
Код:
.button {
&-active { // results in .button-active
// ...
}
}
Sass также имеет функции, в том числе несколько удобных встроенных. Особенно полезен модуль цвета.
Код:
$accent: hsl(250 50% 50%);
$accent-overlay: color.change($accent, $alpha: 0.1);
$accent-darkened: color.scale($accent, $lightness: -30%);
Сегодня мы не можем сделать ничего подобного в CSS.
Sass действительно хорош для повторного использования кода
Благодаря миксинам Sass может помочь нам генерировать множество повторяющихся CSS без необходимости вручную дублировать код.Очень распространенным примером является тематизация, где нам нужно использовать каскад для обработки каждой темы, используя как запрос предпочтений (для ОС), так и в качестве переопределения (для пользовательского переключателя тем). Представьте себе, что мы дублируем десятки переменных и забываем обновить одну из них в будущем.
Sass позволяет нам справиться с этим довольно элегантно.
Код:
:root {
@include light-theme;
@media (prefers-color-scheme: dark) {
@include dark-theme;
}
&[data-theme=light] {
@include light-theme;
}
&[data-theme=dark] {
@include dark-theme;
}
}
@mixin light-theme {
--background: hsl(0 0% 90%);
--text: hsl(0 0% 10%);
// ...
}
@mixin dark-theme {
--background: hsl(0 0% 10%);
--text: hsl(0 0% 90%);
// ...
}
Мы даже можем поместить эти тематические миксины в отдельные файлы и импортировать их гранулированно, чего мы пока не можем сделать с чистым CSS.
И, конечно, в Sass есть циклы, условия и интерполяция, которые позволяют нам генерировать "варианты" очень быстро.
Код:
@each $status in positive, negative, warning {
.component-#{$status}
background: var(--bg-#{$status});
color: var(--fg-#{$status});
@if ($status == negative) {
border: 2px solid;
}
}
}
Sass очень прост в использовании
Из-за того, что Sass был распространен исторически, он имеет удивительную поддержку в большом количестве сред. В большинстве систем сборки использование Sass - это просто установка пакета и, возможно, добавление строки конфигурации. Vite, который является одним из моих любимых инструментов сборки, даже не требует никаких настроек.Из-за такого низкого трения трудно сказать "нет" Sass, учитывая всю ценность, которую он предоставляет без особых затрат.
Что насчет PostCSS?
PostCSS отлично подходит для многих вещей, таких как автопрефиксация, удаление комментариев, минификация и даже написание завтрашнего CSS сегодня. Мы даже можем решить проблему вложенности с помощью PostCSS. Так зачем же использовать Sass?По моему опыту, PostCSS может быть достаточно для небольших проектов, но Sass действительно сияет в масштабе, где он почти служит как связующее звено.
И несмотря на некоторое совпадение, я считаю, что эти инструменты служат для разных нужд. Кроме того, они отлично работают вместе, позволяя нам использовать лучшие стороны обоих инструментов.