В чем разница между Sass и SCSS? Что такое Less и 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 .

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

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

Даже лучше! В нем не нужны @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 программистов (хотя не факт, я хотел бы услышать и обратные мнения).

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

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

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

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

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

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

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

В сети уже полно обсуждений о том, что лучше: 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 и т.д.

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

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

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

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

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

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

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

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

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

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

@height: `document.body.clientHeight`;

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

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

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

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

Очень понравилось то, что в 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 написано уже множество готовых библиотек (

Лень двигатель прогресса. Хороший пример - принцип DRY - Don"t repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:

• организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
• Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
• Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
• Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.

Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

• У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
• С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
• Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
• Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.

Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

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

Каковы основные задачи препроцессора, и какой выбрать: SASS или LESS, разберем в данной статье. Для начала необходимо определить, препроцессор – что это такое? Это средство или инструмент, который изменяет определенный код, преобразуя его с помощью различных возможностей. На вход процессора идет код, который описан различными синтаксическими конструкциями. Данные конструкции понятны только данному инструменту. Он может замещать различные сложные конструкции языка или наоборот добавлять новые. На выходе из программы получается код более низкого качества с удаленными конструкциями.

Для лучшего понимания термина препроцессор рассмотрим пример. На вход данной программы идет код, который содержит различные слова, проблемы, запятые и точки. При наличии функции замены ключевого слова в краткой его форме, то есть в аббревиатуре, на полное название, то на выходе получим предложение с расширенной записью. Это самое примитивное понимание, что такое препроцессор. По-существу в нем заложены более сложные команды и возможности.

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

Обычно код направлен на особенности человека:

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

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

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

Syntactically Awesome Style Sheets

SASS является самым мощным препроцессором. Его разрабатывала целая команда программистов. Он был основан в 2007 году в качестве модуля для HAML и, кроме того, написан на Ruby (есть порт на C++). Также он обладает более широким спектром возможностей по сравнению с другой программой. Чтобы расширить возможности Syntactically Awesome Style Sheets, можно использовать многофункциональную библиотеку Compass. Программа SASS имеет два варианта синтаксиса: Sass и SCSS.

Это самый молодой и перспективный инструмент. Его основали в 2010 году. Препроцессор Stylus является самым удобным и расширяемым препроцессором.

Обычно программист уже работает с LESS. Любой файл считается валидным LESS-файлом. При этом, нет необходимости в расширении файла. При взятии обычного CSS-кода поместим его в файл с тем же именем, но с расширением.less. По факту был получен идентичный файл без ошибок и с точным содержанием. Разница между файлами была только в наличии пустых строк после селекторов. Таким образом, при использовании данного инструмента времени на компиляцию уходит намного меньше. Поэтому действие данного средства направлено на конкретные цели, построения удобной структуры. Это можно выполнить и с обычным CSS, но удобства при этом будет меньше.

Согласно функциональным характеристикам Sass определенно лучше других программ по многим параметрам. Но если работа уже проходит с помощью Less, нет никакого смысла его менять. Как было указано выше, SASS позволяет применять Compass, что приводит к облегчению при работе с префиксами. У других программ нет проекта Compass, так как язык инструмента довольно сложен. SASS имеет логические и циклические операторы. Сайт LESS красивый и удобный по сравнению с другими сайтами.

При работе с правилами @media программист добавляет блоки с ними внизу страницы стилей. Это приводит к разъединению стилей. Less и Sass – оба инструмента, которые решают эту проблему, математика в них в целом похожа. По скорости работы оба препроцессора обладают хорошими показателями.

Разработчики обоих вариантов продолжают их дальнейшее совершенствование.

Согласно отзывам и комментариям программистов оба инструмента могут быть использованы с равными возможностями. Syntactically Awesome Style Sheets по некоторым данным имеет более низкую скорость по сравнению с другими. Некоторые считают, что Stylus сегодня превзошел оба препроцессора.

Итак, точного решения вопроса об использовании Less и Sass нет, так как они оба обладают хорошими свойствами и функционалом. Поэтому выбор определен целями и задачами программиста.