Доводы в пользу использования Sass в 2022 году

Остается ли Sass актуальным? Кажется, что этот вопрос возникает каждые несколько месяцев. Совсем недавно Джереми Кит в своем докладе на CSS Day предположил, что 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 действительно сияет в масштабе, где он почти служит как связующее звено.

И несмотря на некоторое совпадение, я считаю, что эти инструменты служат для разных нужд. Кроме того, они отлично работают вместе, позволяя нам использовать лучшие стороны обоих инструментов.

Parcel CSS?​

Parcel CSS выглядит как действительно многообещающая альтернатива PostCSS. Я не провел с ним много времени, потому что он требует немного ручной настройки в моем рабочем процессе (PostCSS просто проще). Но я буду следить за ним. Я не думаю, что он полностью заменит мне Sass, но он может заменить PostCSS.

Заключение​

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