В чем разница между Sass и SCSS?

Я много писал в последнее время о Sass, но по некоторым недавним комментариям я понял, что не все четко себе представляют, что такое Sass. Внесем немного ясности:

Когда мы говорим о Sass, мы обычно имеем в виду препроцессор и язык в целом. Мы говорим, например, «мы используем Sass», или «вот примесь Sass».

Между тем, Sass (препроцессор) допускает два различных синтаксиса:

  • Sass, также известный как синтаксис с отступами;
  • SCSS, CSS-подобный синтаксис.

История

Первоначально Sass являлся частью другого препроцессора — Haml, который придумали и написали разработчики из Ruby.

Поэтому стили Sass использовали Ruby-подобный синтаксис, без скобок, без точек с запятой и строгих отступов, например:

// Переменная
!primary-color= hotpink
 
// Примесь
=border-radius(!radius)
    -webkit-border-radius= !radius
    -moz-border-radius= !radius
    border-radius= !radius
 
.my-element
    color= !primary-color
    width= 100%
    overflow= hidden
 
.my-other-element
    +border-radius(5px)

Как видите, по сравнению с обычным CSS разница ощутимая! Даже если вы пользователь Sass (препроцессора), вы можете видеть, что это сильно отличается от того, к чему мы привыкли.

Переменная обозначается через !, а не $, символ присвоения значения =, а не :. Довольно необычно.

Но так Sass выглядел до версии 3.0, выпущенной в мае 2010 года, в которой был представлен совершенно новый синтаксис под названием SCSS или Sassy CSS.

Его целью было приблизить синтаксис Sass к CSS, сделав его более совместимым с CSS:

// Переменная
$primary-color: hotpink;
 
// Примесь
@mixin border-radius($radius) {
    -webkit-border-radius: $radius;
    -moz-border-radius: $radius;
    border-radius: $radius;
}
 
.my-element {
    color: $primary-color;
    width: 100%;
    overflow: hidden;
}
 
.my-other-element {
    @include border-radius(5px);
}

SCSS определенно более близок к CSS, чем Sass. Разработчики Sass потрудились над тем, чтобы сделать оба синтаксиса ближе друг к другу, заменив ! (знак переменной) и = (знак присвоения) на $ и : из CSS.

Поэтому при запуске нового проекта вы можете задуматься, какой синтаксис использовать. Позвольте мне осветить эту тему и пояснить все плюсы и минусы каждого из синтаксисов.

Плюсы синтаксиса Sass с отступами

Хотя этот синтаксис может казаться вам немного странным, у него есть несколько интересных моментов. Прежде всего, он короче и его легче набирать. В нем нет скобок и точек с запятой, они не нужны.

Даже лучше! В нем не нужны @mixin или @include, когда достаточно простого символа: = и +.

Также синтаксис Sass обеспечивает чистые стандарты кодирования из-за использования отступов. Так как неправильный отступ может сломать всю таблицу стилей .sass, здесь в первую очередь обеспечивается, чтобы код был чистым и надлежащим образом отформатированным.

Существует только один метод составления кодов Sass: составлять их правильно.

Но будьте осторожны! Отступы имеют логическое значение в Sass. Когда применяется отступ блока селектора, это означает, что это вложенный селектор.

Например:

.element-a
    color: hotpink
 
    .element-b
        float: left
... выводит следующий код CSS:
	.element-a {
    color: hotpink;
}
 
.element-a .element-b {
    float: left;
}

Простой факт смещения .element-b на один уровень вправо означает, что он является дочерним элементом от .element-a, что приводит к изменению результативного CSS-кода. Так что, будьте осторожны с отступами!

Как сторонний наблюдатель, я думаю, что синтаксис на основе отступов, вероятно, больше понравится команде, работающей в основном с Ruby/Python, нежели команде PHP/Java программистов (хотя не факт, я хотел бы услышать и обратные мнения).

Плюсы SCSS синтаксиса

Для начала — он полностью совместим с CSS. Это означает, что вы можете переименовать файл CSS в .scss, и он будет работать, как ни в чем не бывало.

Создание SCSS, полностью совместимого с CSS, всегда было приоритетом для поддержки Sass с самого момента релиза SCSS, и, на мой взгляд, это серьезный аргумент.

Кроме того, они стараются следить, за тем, что может стать валидным синтаксисом CSS в будущем, и реализовать это (отсюда @directives).

Так как SCSS совместим с CSS, он практически не требует дополнительного обучения. Синтаксис почти тот же: в конце концов, это просто CSS с некоторыми дополнениями.

Это важно для начинающих разработчиков: они смогут быстро начать составлять код, почти ничего не зная о Sass.

Кроме того, он более читаем, так как конкретные конструкции уже имеют смысл. Когда вы видите @mixin, вы знаете, что это объявление примеси; когда вы видите @include, вы знаете, что это вызов примеси.

Нет никаких привязок, и все имеет смысл без интерпретации.

Также почти все существующие инструменты, плагины и демо-презентации для Sass разрабатываются с помощью синтаксиса SCSS. Этот синтаксис становится все более ориентированным на профессионалов и выбирается ими по умолчанию (если не является единственно возможным).

В основном в силу указанных выше причин. Например, становится все труднее найти подсветку чистого синтаксиса Sass с отступами; как правило, доступны только варианты подсветки SCSS.

Заключение

Выбор в любом случае остается за вами, но если у вас нет действительно веских причин использовать синтаксис с отступами, я бы настоятельно рекомендовал использовать SCSS, а не Sass. Это не только более просто, но и более удобно.

Как-то я попробовал синтаксис с отступами, и он мне понравился. Особенно его краткость и простота. Я уже хотел было перевести все свои рабочие коды на Sass, но в последнюю минуту передумал.

Я рад, что не совершил этот шаг, потому что сейчас мне было бы очень трудно работать с некоторыми инструментами, если бы я использовал синтаксис с отступами.

Кроме того, обратите внимание, Sass никогда не обозначается аббревиатурой из прописных букв, независимо синтаксис ли это или язык программирования. В то время как SCSS всегда обозначается большими буквами. Хотите узнать почему? Ознакомьтесь с SassnotSASS.com!

Перевод статьи «What’s the Difference Between Sass and SCSS» был подготовлен дружной командой проекта Сайтостроение от А до Я.