Что лучше less или css. Препроцессоры LESS vs 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 написано уже множество готовых библиотек (

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 – это скриптовый язык, расширяющий возможности обычного 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 намного сложнее, чем использовать препроцессор с парой проблем.

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