Важные отличия между Sass и SCSS. Что такое Less и Sass

Синтаксис SASS мне импонирует больше чем SCSS за его краткость. Но большая вложенность стилей в SASS может быстро ликвидировать все преимущества его краткости. В любом случае разницу между SASS и SCSS не принципиальна. LESS оказался ближе к SCSS чем к SASS. И, в общем, это тоже самое. Отличий не много, но парочка из них принципиально меняют расстановку сил.

1. LESS - может client-side с использованием JS.

Точнее он не то чтобы может, он на это и расчитан. Обычная практика использования LESS-кода:

Это потом уже к нему прикрутили возможность компиляции на сервере (и на js и на ruby).

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

Причина становится видна после изучения невзрачных самых послених строках документации к LESS :

@height: `document.body.clientHeight`;

Вот такая маленькая одинокая строчка дает возможности о которых только мечтали верстальщики с начала освоения стилей. Вызов из CSS ява-скрипта на стороне клиента и учет фактических параметров браузера при создании стилей.

Тоесть у нас появилась возможность сначала загрузить DOM, а потом под него создать специальный CSS прямо на стороне клиента. Дальше сами думаейте какие возможности этот открывает.

Нужно ли это вашему проекту это вопросу другой. Понятно что все привыкли к клиентской неизвестности/независимости и верстке в стиле «делаем универсально, чтобы более-менее показывалось у всех на всех разрешениях». Но это не повод забывать что теперь такая возможность есть и с ней вы можете делать, к примеру, ну очень резиновую верстку.

2. LESS, в отличии от SASS/SCSS не имеет логики.

В LESS нет if/then, for и т.п. Хотя, учитывая то, что в него легко встраивается JS думаю логику вполне возможно прикрутить. Не пробовал.

3. В LESS проще миксинг + миксить можно классы.

Очень понравилось то, что в LESS можно включать в определение свойства других классов. Собственно класс и является миксином. Это еще одна особенность которой нет в SASS/SCSS. Вы можете включить в LESS обычный CSS файл и использовать его классы для определия своих свойств. Например:

Wrap {
text-wrap: wrap;
white-space: pre-wrap;
white-space: -moz-pre-wrap;
word-wrap: break-word;
}
pre { .wrap }

Резюме

За исключением 1-го пункта разница не велика и выбор большена любителя.

Лично для меня LESS выглядит более привлекательным из-за своей простоты. Циклы и условия в стилях мне еще никогда не были нужны. Классические утилиты типа «box-shadow, linear-gradient, darken" в LESS есть.

Да, под SASS написано уже множество готовых библиотек (

От автора: прежде всего, что такое препроцессор? Вкратце препроцессор – это программа, модифицирующая данные под входные требования другой программы. Препроцессоры CSS – это скриптовый язык, расширяющий возможности обычного CSS переменными, правилами вложенности, функциями и логическими блоками.

Зачем мне его использовать?

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

С переменными вам не нужно искать и заменять все упоминания красного в стилях. Вы один раз определяете значение переменной, например, «primary color», а затем используете эту переменную как значение.

Значение primary color меняется в одном месте. Можно также импортировать CSS файлы из других источников, не думая о количестве сетевых запросов, так как перед компиляцией их все можно объединить в один файл.

Благодаря вложенной природе CSS препроцессоров, вы получите компактный код с таким же результатом. В основе LESS и SCSS лежит принцип DRY, который расшифровывается как «Don’t repeat yourself» или «не повторяйтесь».

Препроцессоры. Быстрый старт

Что не так с LESS?

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

SCSS использует символ $ для определения переменных, а LESS – @. Поскольку CSS тоже использует символ @ для медиа запросов, импортов и keyframe анимации, это может ввести разработчиков в заблуждение.

Символ $ не используется в CSS. Символ @ есть в SCSS, но он используется для директив @if , @else , @each, @for и @while.

Хотя этот сценарий реален не для всех, лучше использовать разные идентификаторы для разделения элементов.

SCSS поддерживает традиционные логические выражения типа if/else, блоки и циклы. Guarded миксины в LESS легче для глаза, но их сложнее понять.

Можно сделать с помощью LESS…

… или просто с помощью SCSS.

LESS определяет лишь один guarded миксин. Поэтому нельзя просто передать второй аргумент и обработать его в том же миксине, продублировав код для всех возможных сценариев. На самом деле, LESS (меньше) значит больше (игра слов).

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

С таким кодом головной боли больше…

Препроцессоры. Быстрый старт

Изучите азы работы с препроцессорами Less и Sass с полного нуля менее чем за 2 недели

… чем с таким.

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

Хотя это лично мое мнение, мне кажется, что SCSS в целом лучше обрабатывает значения вычислений и математические значения.

Что с этим не так?

LESS, с другой стороны, гораздо сложнее. Например, когда я использую его, я не пытаюсь проводить вычисления. Но даже если бы я это делал, с каких пор 100% минус 50px равно 50%?

LESS, почему ты игнорируешь значения с единицами изменений?

Зачем ты заставляешь меня учить твои костыли, когда я уже знаю CSS?

И последнее. Благодаря проекту LibSass, у SCSS есть много оберток для других языков, например, C, Go, PHP, Python, Dart и т.д.

Почему мы решили отказаться от LESS в угоду SCSS?

Пока мы разрабатывали JotForm Cards, нам нужно было предварительно обрабатывать значения переменных – предварительная компиляция и кеширование на стороне сервера одновременно; и все это нужно было сделать идеально.

Мы хотели, чтобы пользователи могли настраивать внешний вид форм. Чтобы любые изменения мгновенно и одновременно отображались и кэшировались на сервере. Ради наших пользователей мы не хотели запускать клиентскую LESS-оболочку, потому что это потребует вычислительной мощности клиента — и много чего может пойти не так.

Мы не начали цикл разработки с целью перехода от LESS к SCSS. Но на полпути, занимаясь этими незначительными проблемами, отсутствие достойной обертки для LESS стало последней каплей.

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

Пытаться управлять огромным проектом с одним CSS-файлом и традиционной структурой CSS намного сложнее, чем использовать препроцессор с парой проблем.

1. LESS - может client-side с использованием JS.

Точнее он не то чтобы может, он на это и расчитан. Обычная практика использования LESS-кода:

Это потом уже к нему прикрутили возможность компиляции на сервере (и на js и на ruby).

Причина становится видна после изучения невзрачных самых послених строках документации к LESS :

@height: `document.body.clientHeight`;

2. LESS, в отличии от SASS/SCSS не имеет логики.

3. В LESS проще миксинг + миксить можно классы.

Wrap {
text-wrap: wrap;
white-space: pre-wrap;
white-space: -moz-pre-wrap;
word-wrap: break-word;
}
pre { .wrap }

Резюме

За исключением 1-го пункта разница не велика и выбор большена любителя.

Да, под SASS написано уже множество готовых библиотек (

Перевод

«Какой препроцессорный язык стоит использовать для CSS?» является очень актуальным вопросом в последнее время. Несколько раз меня спрашивали об этом лично, и казалось бы, каждые пару дней этот вопрос поднимался в сети. Очень приятно что беседа перешла из темы о плюсах и минусах препроцессинга к обсуждению какой же язык является лучшим. За дело!

Если быть кратким: SASS.

Немного развернутый ответ: SASS лучше по всем пунктам, но если вы уже счастливы с LESS - это круто, по крайней мере вы уже упростили себе жизнь используя препроцессинг.

График обучения с Ruby и командной строкой Единственным пунктом является синтаксис. Для компиляции созданных вами файлов стоит использовать такое приложение как CodeKit . Вы должны знать основы Ruby или командной строки или еще чего-то другого. Наверное вам стоит это знать, но не обязательно, так что это не играет большой роли.

Победитель: нет.

В помощь CSS3 С любым из языков вы можете создавать собственные примеси для упрощения жизни с префиксами. Так что здесь нет победителя. Но знаете ли вы как сделать так, чтобы не обновлять эти префиксы во своих своих проектах? (Нет, не знаете). Также вам, скорей всего, не придется обновлять ваш собственный файл с примесями. SASS позволяет использовать Compass , благодаря автообновлениям которого вы можете забыть о проблемах с префиксами. Конечно же вы можете обновлять программное обеспечение и время от времени его компилировать, но это тривиальная задача и не стоит на этом зацикливаться.

Так что все это сводится к следующему: у SASS есть Compass, а у LESS его нет . На самом деле все немного запутанней. Все попытки создать проект типа Compass для LESS потерпели неудачу. Дело в том, что LESS не является достаточно сильным языком, что бы сделать это корректно. Немного подробней будет ниже.

Победитель: SASS

Способности языка: логика/циклы LESS позволяет создавать «защищенные примеси». Эти примеси вступят в силу только в случае если условие верно. Допустим вы захотите поменять цвет фона, который будет зависеть от текущего цвета текста. Если цвет текста «достаточно светлый» вы, наверное, захотите сделать темный фон. Если же он «достаточно темный» - вы захотите светлый фон. Таким образом у вас получится примесь, разбитая на две части с этими «защитниками», которые гарантируют что только один из них будет исполнен.

LESS
.set-bg-color (@text-color) when (lightness(@text-color) >= 50%) { background: black; } .set-bg-color (@text-color) when (lightness(@text-color) < 50%) { background: #ccc; }
После использования вы получите подходящий фон:

LESS
.box-1 { color: #BADA55; .set-bg-color(#BADA55); }
Это очень просто, но суть, надеюсь, понятна. Вы можете делать вещи гораздо круче этого. LESS также позволяет делать ссылающейся на себя рекурсии, примеси которых могут вызывать самих себя с обновленными значениями.

LESS
.loop (@index) when (@index > 0) { .myclass { z-index: @index; } // Call itself .loopingClass(@index - 1); } // Stop loop .loopingClass (0) {} // Outputs stuff .loopingClass (10);

На этом логика/циклы в LESS и заканчиваются. SASS обладает актуальными логическими и циклическими операторами. if/then/else, цикл for, цикл while и цикл each. Без каких либо трюков, настоящее программирование. SASS является достаточно надежным языком, что делает возможным использование Compass.

Например, у Compass есть примесь background , которая является настолько мощной, что вы можете положить в нее все что захотите и в итоге получите именно то, что вам нужно. Картинки, градиенты и любая их комбинация, разделенная запятой - и вы получаете нужный результат (включая префиксы и все прочее).

Лаконичный кусок кода:

SCSS
.bam { @include background(image-url("foo.png"), linear-gradient(top left, #333, #0c0), radial-gradient(#c00, #fff 100px)); }
Превращается этот код в монстра ниже (который, к сожалению, нужен в целях кроссбраузерности):

CSS
.bam { background: url("/foo.png"), -webkit-gradient(linear, 0% 0%, 100% 100%, color-stop(0%, #333333), color-stop(100%, #00cc00)), -webkit-gradient(radial, 50% 50%, 0, 50% 50%, 100, color-stop(0%, #cc0000), color-stop(100%, #ffffff)); background: url("/foo.png"), -webkit-linear-gradient(top left, #333333, #00cc00), -webkit-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), -moz-linear-gradient(top left, #333333, #00cc00), -moz-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), -o-linear-gradient(top left, #333333, #00cc00), -o-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), -ms-linear-gradient(top left, #333333, #00cc00), -ms-radial-gradient(#cc0000, #ffffff 100px); background: url("/foo.png"), linear-gradient(top left, #333333, #00cc00), radial-gradient(#cc0000, #ffffff 100px); }
Победитель: SASS

Победитель: LESS

@extend концепция Допустим вы создали класс с неким набором стилей. Затем вам понадобится создать еще один, который будет как предыдущий, но с некими дополнениями. LESS позволяет сделать это так:

LESS
.module-b { .module-a(); /* Copies everything from .module-a down here */ border: 1px solid red; }
По сути это обычный «include». Вы также можете использовать эту вставку и в SASS, но лучше это делать используя @extend . @extend не просто копирует стили из .module-a в .module-b (что производит к раздуванию файла), он меняет название селектора .module-a на .module-a, .module-b в скомпилированном CSS (что является более эффективным способом).

SCSS
.module-a { /* A bunch of stuff */ } .module-b { /* Some unique styling */ @extend .module-a; }
Компилируется в:

CSS
.module-a, .module-b { /* A bunch of stuff */ } .module-b { /* Some unique styling */ }
Вы это видите? SASS переопределяет селекторы, и это более эффективный путь.

Победитель: SASS

Обработка переменных LESS использует @, SASS использует $. Знак доллара не используется в CSS, чего нельзя сказать про @. Он используется для объявления @keyframes или блоков @media. Вы можете считать что использования того или другого спецсимвола это дело вкуса, но я думаю что SASS имеет здесь преимущество именно за счет того, что не путает базовые концепции.

SASS имеет странное свойство - если вы переопределите «глобальную» переменную «локальной», глобальная переменная примет ее значение. Немного странно.

SCSS
$color: black; .scoped { $color: white; color: $color; } .unscoped { // LESS = black (global) // SASS = white (overwritten by local) color: $color; }
Это трюк может быть полезным, но он совсем не интуитивен, особенно если вы пишете на Javascript.

Победитель: надо бросить монетку:)

Работа с правилами media Почти каждый из нас, начиная работать с правилами @media , добавляет блоки с ними внизу главной страницы стилей. Это работает, но приводит к разъединению стилей, например:

CSS
.some-class { /* Default styling */ } /* Hundreds of lines of CSS */ @media (max-width: 800px) { .some-class { /* Responsive styles */ } }
С помощью SASS или LESS вы можете объединить эти стили используя вложения.

SCSS
.some-class { /* Default styling */ @media (max-width: 800px) { /* Responsive styles */ } }
«respond-to» - довольно таки крутая техника SASS (ознакомьтесь с кодом Chris Eppstein , Ben Schwarz , и Jeff Croft).

SCSS
=respond-to($name) @if $name == small-screen @media only screen and (min-width: 320px) @content @if $name == large-screen @media only screen and (min-width: 800px) @content
Дальше использовать их можно очень лаконично:

SCSS
.column width: 25% +respond-to(small-screen) width: 100%
Примечание: для использования этой техники вам будет нуже SASS 3.2, который пока находится в альфе, установить его можно командой gem install sass --pre . Я думаю что тут не должно быть сомнений в том, что это действительно полезная вещь в разработке.

Победитель: SASS

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

LESS
div { width: 100px + 2em; // == 102px (weird) }
SASS даст вам четко и ясно понять что здесь спряталась ошибка:
Incompatible units: "em" and "px" . Конечно, это спорный вопрос что лучше - ошибка или неверное значение, но лично я - за первое. Особенно если вы отдаете предпочтение переменными вместо использования цифр, это очень сильно затрудняет их отслеживание.

SASS позволяет проводить математические операции с «неизвестными» единицами измерения, которые могут появиться до следующего обновления. LESS этого не позволяет. Есть еще более странные отличия, например, как SASS умножает числа с единицами измерения, но об этом не сегодня.

Победитель: SASS (с натяжкой)

Я много писал в последнее время о 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 » был подготовлен дружной командой проекта