Тендеры и лиды
Информация
Делимся личным опытом работы с препроцессором, рассказываем о сильных сторонах, удобных фичах и объясняем, почему SASS по-прежнему остается частью современного фронтенд-стека.
SASS — это препроцессор CSS, который позволяет использовать переменные, функции, условия, циклы и другие конструкции, отсутствующие в стандартном CSS.
SASS имеет два синтаксиса:
Мы в своей практике используем исключительно SCSS — он проще для вхождения и легко интегрируется с современными фреймворками и сборщиками.
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 все еще дает разработчикам:
Начнем с возможностей, которых пока нет в CSS.
Миксин – это конструкция которая может содержать определенный набор свойств, @extend, вызовов функций и циклов. Все, что будет объявлено внутри миксина можно переиспользовать, указав название миксина с ключевым словом @include.
Простой пример, миксин для добавления анимации css-свойствам:
С таким кодом нет необходимости создавать для каждого блока transition-свойство, просто используем миксин, передаем нужные свойства для анимации и готово!
Миксины здорово экономят время. Мы сами в этом убедились, когда в e-commerce проекте нужно было единообразно управлять анимацией карточек. Вместо копипаста transition-свойств по всему коду вынесли в миксин и смогли централизованно обновлять поведение.
SASS позволяет использовать условные конструкции. Например, в примере о миксинах был следующий блок с задержкой анимации.
В нем мы можем указать нужное свойство или несколько свойств. Например, миксин который добавляет внешние и внутренние отступы элементу, если переменная $needOffset содержит истинное значение:
В данном случае если четвертым аргументом передаем не null-значение, то для анимации появится задержка. Конечно, значение должно быть валидным, например, 0.3s, 500ms.
Иногда на проекте появляется проблема: «вёрстка поехала» или неожиданно появился горизонтальный скролл, хотя все элементы находится в контейнере. Проверили разметку, все элементы на месте, а верстка все равно едет. В таких случаях помогает быстрый отладочный прием — включить режим дебага через SCSS-переменную:
Когда значение переменной`$debug` в `true`, все элементы получают красную обводку. Это позволяет сразу увидеть блок, который выходит за границы контейнера или ломает поток разметки (например, из-за неправильного позиционирования absolute).
Важно, что здесь используется свойство `outline`, а не `border` — оно не влияет на размеры элементов (помним о `box-sizing`) и не смещает layout. Такой приём позволяет очень быстро находить проблемные участки верстки и экономит время на дебаг.
SASS-переменные – одна из базовых возможностей препроцессора. Но с приходом CSS-переменных мы почти полностью перешли на них. Именно от переменных SASS в пользу CSS Variables, так как последние работают в runtime, с таким работать удобнее и могут быть случаи когда с переменными приходится работать через JS.
Однако, если значение не должно изменяться в runtime, старые добрые SASS-переменные остаются удобными.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13201 тендер
проведено за восемь лет работы нашего сайта.
Мы используем оба подхода. для темизации интерфейса удобнее CSS Variables, ведь ими легко управлять через JS прямо в runtime. Но там, где значения не должны меняться (брейкпоинты, базовые размеры), оставляем SCSS-переменные.
SASS обрабатывает импорты на этапе компиляции, в отличие от @import в CSS, который создаёт дополнительные HTTP-запросы. Для больших проектов это критично: мы можем разбивать код на модули, но при этом не перегружаем сеть.
В SCSS импорты срабатывают ещё на стадии сборки, поэтому на выходе всегда один CSS-файл (или несколько, если так задумано архитектурой). Это удобно: код структурирован, итог лёгкий.
Импорты в SCSS не раз спасали архитектуру в больших проектах. Например, в корпоративной системе с десятками страниц мы разделили стили на отдельные модули — хедер, футер, карточки, таблицы. А на продакшн все собиралось в один оптимизированный файл без лишних запросов.
Чаще всего в адаптиве нужно плавно изменять свойства. Например, размер шрифта или отступы в зависимости от ширины экрана. Вместо множества медиа запросов удобно использовать CSS-функцию clamp(). Она создает не фиксированное значение, а «резиновое», которое растет или сжимается в зависимости от ширины экрана. Мы внедряем ее во всех проектах с адаптивом, например, для типографики и отступов.
В SCSS это можно автоматизировать с помощью функции:
Функция fluid принимает четыре аргумента:
То есть мы задаем «коридор» значений, где между ними изображение плавно изменяется. И на выходе получаем clamp-функцию с автоматически рассчитанными параметрами.
Да, SASS уже не на хайпе, как раньше. Но он по-прежнему остается мощным инструментом, особенно в проектах с жесткими требованиями к архитектуре, масштабируемости и стабильности.
Мы комбинируем SASS с современными практиками и не видим причин полностью от него отказываться, по крайней мере, пока нативный CSS не догонит его по возможностям.
А вы используете SASS или другие препроцессоры в современной разработке или решили отказаться в пользу других инструментов?
);
}
@return clamp(
#{$min}px,
#{$y-intercept}px + #{$slope * 100}vw,
#{$max}px
);
}
