Почему мы все еще используем SASS в 2025 году / Хабр

Привет, Хабр! На связи Герман, TL Frontend-разработчик в Webest, и сегодня хочу поделиться тем, почему мы продолжаем использовать препроцессор SASS/SCSS в наших проектах, несмотря на растущую популярность Tailwind и CSS-in-JS решений.

К слову, мы не «олдскульные фанаты» SASS, и Tailwind тоже используем, но в зависимости от типа проекта. Комбинированный подход дает гибкость, особенно в масштабируемых фронтенд-системах.

Что такое SASS/SCSS

SASS — это препроцессор CSS, который позволяет использовать переменные, функции, условия, циклы и другие конструкции, отсутствующие в стандартном CSS.

SASS имеет два синтаксиса:

SASS — оригинальный синтаксис с отступами вместо фигурных скобок.
SAAS
SCSS — более современный и популярный вариант, максимально похожий на CSS (добавляет расширения без изменения привычной структуры).
SCSS

Мы в своей практике используем исключительно SCSS — он проще для вхождения и легко интегрируется с современными фреймворками и сборщиками.

Зачем используем в 2025

SASS появился в 2007 году и сразу стал прорывом: позволял использовать переменные, вложенность и миксины еще до того, как что-то похожее появилось в стандарте CSS. В 2010-е он стал де-факто стандартом в крупных проектах.

Позже появились альтернативы: LESS, Stylus, еще позже — CSS-in-JS и Tailwind. Многие стали отказываться от SASS, когда в нативном CSS появились переменные, @custom-media, clamp(), вложенность и другие возможности. Поэтому сейчас SASS воспринимается не как «обязательный инструмент», а как осознанный выбор для архитектуры и масштабируемости.

Мы используем комбинированный подход, в зависимости от проекта. Где-то используем SASS в «классическом виде»: написал стили – скомпилировал – готово. Где-то он используется в связке с CSS Modules, в частности в крупных проектах на Vue/Nuxt.

Например, в разработке интернет-магазина для проекта X с тысячами карточек товаров Tailwind оказался удобен на старте, но при масштабировании код стал тяжело поддерживать. Вернувшись к SCSS-модулям, мы сократили дублирование кода и сделали поддержку проще.

Несмотря на то, что в CSS появляется все больше нативных возможностей (например, CSS variables, container queries, nesting и т.д.), SASS все еще дает разработчикам:

Быструю разработку с DRY-принципами.
Чистую архитектуру за счет деления на модули.
Возможность писать более выразительный и масштабируемый код.

Преимущества для масштабирования

Начнем с возможностей, которых пока нет в CSS.

Миксины

Миксин – это конструкция которая может содержать определенный набор свойств, @extend, вызовов функций и циклов. Все, что будет объявлено внутри миксина можно переиспользовать, указав название миксина с ключевым словом @include.

Простой пример, миксин для добавления анимации css-свойствам:

// Создаем сам миксин который будет добавлять анимацию для css-свойств
@mixin transition(
  $property: all,
  $duration: .3,
  $function: ease,
  $delay: null
) {
  transition-duration: $duration;
  transition-property: $property;
  transition-timing-function: $function;

  @if $delay {
    transition-delay: $delay;
  }
}

// Применяем миксин к селектору
.some-selector {
    @include transition((color, background-color));
}

С таким кодом нет необходимости создавать для каждого блока transition-свойство, просто используем миксин, передаем нужные свойства для анимации и готово!

*Пример как выглядит gif-изображение с применением миксина и без*

Миксины здорово экономят время. Мы сами в этом убедились, когда в e-commerce проекте нужно было единообразно управлять анимацией карточек. Вместо копипаста transition-свойств по всему коду вынесли в миксин и смогли централизованно обновлять поведение.

Условия (@if, @else)

SASS позволяет использовать условные конструкции. Например, в примере о миксинах был следующий блок с задержкой анимации.

@if $delay {
    transition-delay: $delay;
  }

В нем мы можем указать нужное свойство или несколько свойств. Например, миксин который добавляет внешние и внутренние отступы элементу, если переменная $needOffset содержит истинное значение:

@if ($needOffset) {
	margin-block: 10px;
	margin-inline: 20px;
	padding: 8px;
}

В данном случае если четвертым аргументом передаем не null-значение, то для анимации появится задержка. Конечно, значение должно быть валидным, например, 0.3s, 500ms.

Дебаггинг для поиска проблемной вёрстки

Иногда на проекте появляется проблема: «вёрстка поехала» или неожиданно появился горизонтальный скролл, хотя все элементы находится в контейнере. Проверили разметку, все элементы на месте, а верстка все равно едет. В таких случаях помогает быстрый отладочный прием — включить режим дебага через SCSS-переменную:

$debug: true;

@if ($debug) {
   * {
        outline: 1px solid red;
    }
}

Важно, что здесь используется свойство outline, а не border — оно не влияет на размеры элементов (помним о box-sizing) и не смещает layout. Такой приём позволяет очень быстро находить проблемные участки верстки и экономит время на дебаг.

Переменные

SASS-переменные – одна из базовых возможностей препроцессора. Но с приходом CSS-переменных мы почти полностью перешли на них. Именно от переменных SASS в пользу CSS Variables, так как последние работают в runtime, с таким работать удобнее и могут быть случаи когда с переменными приходится работать через JS.

Однако, если значение не должно изменяться в runtime, старые добрые SASS-переменные остаются удобными.

Мы используем оба подхода. для темизации интерфейса удобнее CSS Variables, ведь ими легко управлять через JS прямо в runtime. Но там, где значения не должны меняться (брейкпоинты, базовые размеры), оставляем SCSS-переменные.

Импорты

SASS обрабатывает импорты на этапе компиляции, в отличие от @import в CSS, который создаёт дополнительные HTTP-запросы. Для больших проектов это критично: мы можем разбивать код на модули, но при этом не перегружаем сеть.

В SCSS импорты срабатывают ещё на стадии сборки, поэтому на выходе всегда один CSS-файл (или несколько, если так задумано архитектурой). Это удобно: код структурирован, итог лёгкий.

Импорты в SCSS не раз спасали архитектуру в больших проектах. Например, в корпоративной системе с десятками страниц мы разделили стили на отдельные модули — хедер, футер, карточки, таблицы. А на продакшн все собиралось в один оптимизированный файл без лишних запросов.

Адаптивы

Чаще всего в адаптиве нужно плавно изменять свойства. Например, размер шрифта или отступы в зависимости от ширины экрана. Вместо множества медиа запросов удобно использовать CSS-функцию clamp(). Она создает не фиксированное значение, а «резиновое», которое растет или сжимается в зависимости от ширины экрана. Мы внедряем ее во всех проектах с адаптивом, например, для типографики и отступов.

В SCSS это можно автоматизировать с помощью функции:

@function fluid($min, $max, $min-vw: 360, $max-vw: 1440) {
    $slope: math.div(($max - $min), ($max-vw - $min-vw));
    $y-intercept: $min - $slope * $min-vw;

    @if $min > $max {
        @return clamp(
            #{$max}px,
            #{$y-intercept}px + #{$slope * 100}vw,
            #{$min}px
        );
    }

    @return clamp(
        #{$min}px,
        #{$y-intercept}px + #{$slope * 100}vw,
        #{$max}px
    );
}

Функция fluid принимает четыре аргумента:

$min — минимальное значение свойства (например, 16 для шрифта в 16px).
$max — максимальное значение свойства (например, 24 для шрифта в 24px).
$min-vw — минимальная ширина экрана, при которой применяется $min (по умолчанию 360px).
$max-vw — максимальная ширина экрана, при которой применяется $max (по умолчанию 1440px).

То есть мы задаем «коридор» значений, где между ними изображение плавно изменяется. И на выходе получаем clamp-функцию с автоматически рассчитанными параметрами.

Заключение

Да, SASS уже не на хайпе, как раньше. Но он по-прежнему остается мощным инструментом, особенно в проектах с жесткими требованиями к архитектуре, масштабируемости и стабильности.

Мы комбинируем SASS с современными практиками и не видим причин полностью от него отказываться, по крайней мере, пока нативный CSS не догонит его по возможностям.

А вы используете SASS или другие препроцессоры в современной разработке или решили отказаться в пользу других инструментов?

Почему мы все еще используем SASS в 2025 году