Почему мы все еще используем SASS в 2025 году
Привет, Хабр! На связи Герман, TL Frontend-разработчик в Webest, и сегодня хочу поделиться тем, почему мы продолжаем использовать препроцессор SASS/SCSS в наших проектах, несмотря на растущую популярность Tailwind и CSS-in-JS решений.
К слову, мы не «олдскульные фанаты» SASS, и Tailwind тоже используем, но в зависимости от типа проекта. Комбинированный подход дает гибкость, особенно в масштабируемых фронтенд-системах.
Что такое SASS/SCSS
SASS — это препроцессор CSS, который позволяет использовать переменные, функции, условия, циклы и другие конструкции, отсутствующие в стандартном CSS.
SASS имеет два синтаксиса:
SASS — оригинальный синтаксис с отступами вместо фигурных скобок.
SCSS — более современный и популярный вариант, максимально похожий на CSS (добавляет расширения без изменения привычной структуры).
Мы в своей практике используем исключительно 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-свойство, просто используем миксин, передаем нужные свойства для анимации и готово!
Миксины здорово экономят время. Мы сами в этом убедились, когда в 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 или другие препроцессоры в современной разработке или решили отказаться в пользу других инструментов?