Что лучше less или sass
Краткий обзор отличий LESS от SASS
Вчера пол дня потратил на подробное изучение LESS и его отличие от используемых нами SASS/SCSS.
Синтаксис SASS мне импонирует больше чем SCSS за его краткость. Но большая вложенность стилей в SASS может быстро ликвидировать все преимущества его краткости. В любом случае разницу между SASS и SCSS не принципиальна. LESS оказался ближе к SCSS чем к SASS. И, в общем, это тоже самое. Отличий не много, но парочка из них принципиально меняют расстановку сил.
1. LESS — может client-side с использованием JS.
Точнее он не то чтобы может, он на это и расчитан. Обычная практика использования LESS-кода:
Это потом уже к нему прикрутили возможность компиляции на сервере (и на js и на ruby).
На первый взгляд какое-то странное свойство. Зачем компилить на стороне клиента, если можно отлично скомпилить на сервере и отдавать уже готовую ужатую CSS как мы привыкли с SASS?
Причина становится видна после изучения невзрачных самых послених строках документации к LESS:
Вот такая маленькая одинокая строчка дает возможности о которых только мечтали верстальщики с начала освоения стилей. Вызов из CSS ява-скрипта на стороне клиента и учет фактических параметров браузера при создании стилей.
Тоесть у нас появилась возможность сначала загрузить DOM, а потом под него создать специальный CSS прямо на стороне клиента. Дальше сами думаейте какие возможности этот открывает.
Нужно ли это вашему проекту это вопросу другой. Понятно что все привыкли к клиентской неизвестности/независимости и верстке в стиле «делаем универсально, чтобы более-менее показывалось у всех на всех разрешениях». Но это не повод забывать что теперь такая возможность есть и с ней вы можете делать, к примеру, ну очень резиновую верстку.
2. LESS, в отличии от SASS/SCSS не имеет логики.
В LESS нет if/then, for и т.п. Хотя, учитывая то, что в него легко встраивается JS думаю логику вполне возможно прикрутить. Не пробовал.
3. В LESS проще миксинг + миксить можно классы.
Очень понравилось то, что в LESS можно включать в определение свойства других классов. Собственно класс и является миксином. Это еще одна особенность которой нет в SASS/SCSS. Вы можете включить в LESS обычный CSS файл и использовать его классы для определия своих свойств. Например:
Резюме
За исключением 1-го пункта разница не велика и выбор большена любителя.
Лично для меня LESS выглядит более привлекательным из-за своей простоты. Циклы и условия в стилях мне еще никогда не были нужны. Классические утилиты типа «box-shadow, linear-gradient, darken’ в LESS есть.
Да, под SASS написано уже множество готовых библиотек (compass, bourbone и достаточно широкое сообщество), но под LESS есть тот же Twitter Bootstrap и этого более чем достаточно.
SASS или LESS что лучше начать учить
В этой статье я бы хотел разобрать, что лучше начать учить в 2020 году, SASS или LESS, надеюсь статья для вас будет полезна, и вы найдёте здесь ответ на свой вопрос.
Что такое SASS и LESS:
Для начала хочу рассказать что такое SASS и LESS, для тех кто не знает.
Тут всё просто, это препроцессоры CSS, которые должны упростить работу со стилями, но об этом может в другой статьи.
Сравнение SASS и LESS:
Теперь перейдём к самому сравнению этих двух технологий.
Подробнее о каждом:
SASS (Syntactically Awesome Stylesheets) — это метаязык на основе CSS, предназначенный для увеличения уровня абстракции CSS кода и упрощения файлов каскадных таблиц стилей.
Был создан в 2006 году, не большой командой разработчиков, но главный автор этого языка Хамптон Катлин (англ. Hampton Catlin).
Также стоит упомянуть, что у SASS есть два синтаксиса, что может показаться на первый взгляд удобно, но об этом ниже
Этот язык был создан в 2009 году, силами человека по имени Алексис Селье (англ. Alexis Sellier).
Также надо сказать, что сейчас его разработка прикрашена, ещё в 2016 году, но зато он перерос практически в отдельную JavaScript библиотеку, что усложнит его использование не подготовленному человеку, то есть не знающего JS.
Синтаксис:
Как говорилось выше у SASS есть два синтаксиса, первый это стандартный который был изначально, но он на мой взгляд не удобный и не понятный сразу, поэтому буду использовать второй, который был создан под влиянием LESS, называется SCSS.
Для LESS всё стандартно, покажу как использовать именно в обычно LESS, без JavaScript.
Попытаемся сделать эту картинку.
Сначала посмотрите как сделать это на SASS со синтаксисом SCSS.
Что использовать LESS или SASS?
less, scss и stylus для 98% работ обладают полностью идентичной функциональностью и выбор меж ними или чисто эстетический или технологический (какие-то ограничения проекта).
сам для себя выбрал Less — привычно, наглядно, красиво, удобно работать с emmet
и не верьте статьям 12-х годов о том, что «scss намного мощнее».
на данный момент (конец осени 2014) все перечисленные препроцессоры равны по возможностям на 98%.
п.с.: реально каждый день из всех возможностей препроцессоров используются: переменные, примеси и вложения. ОЧЕНЬ странно под каждый проект заново писать генераторы модульной сетки и т.п. вещи, требующие условий и циклов.
Не SASS а SCSS, это вопервых.
Во вторых, SCSS помощнее будет, но по сути и less вам хватит за глаза. В плане готовых снипетов и прочее, они приблизительно равны.
старый — sass — отличается отсутствием фигурных скобок, в нём вложенные элементы реализованы с помощью отступов;
новый — SCSS (Sassy CSS) — использует фигурные скобки, как и сам CSS.
Рекомендую SASS (версия SCSS). Он намного функциональнее и более динамично развивается.
Подробнее изложено в статье Криса Койера:
habrahabr.ru/post/144309
SASS только SASS используйте SASS!
compas? серьезно? А как же postcss + autoprefixer? Миксины для префиксов не нужны вообще.
nort1986: нет, не логично хотеть чего-то одного. Ну и я использую autoprefixer вместе с less например, и оно работает достаточно быстро. Намного быстрее ruby-sass.
Суть postcss в постобработке. Изначальную структуру нам формирует препроцессор, а мелочи вроде префиксов, о которых париться вот вообще не хочется, можно возложить на постпроцессоры. Ну и много других прикольных вещей можно делать с постпроцессорами что бы вставлять хаки и кастыли для браузеров не завязывая на них свои стили.
nort1986: пользовался gulp-ом года так два назад, до него был grunt. Сейчас использую webpack, less или scss в зависимости от проекта, + postcss для того что бы перестать беспокоиться о этом бреде с префиксами. В итоге у меня необходимость использовать миксины возникает не так часто и только для реюза каких-то отдельных блоков.
Есть разные подходы к разработке, и мои подходы меня устраивают. Кричать что есть какой-то единственно вернвый подход как-то не ок. Учитывая что крутые чуваки (тот же гугл) отказались от добавления новых CSS штук под префиксами в пользу флагов.
Сергей Протько: так я никому ничего и не навязываю))))
Я выше писал, что я пользуюсь gulp-ом и scss. У меня compass, свой css-framework и свои миксины (тут совсем не префиксы), я похожие свойства объединяю через @extend, а миксины использую чтобы задавать для них значения к примеру @include size(15px, 20px) я так размеры задаю. Эра префиксов конечно закончилась, но у меня на работе есть поддержка 8, 9 IE и подобных старых браузеров, для них еще нужны префиксы. Сейчас 10 винда вышла, говорят они отказались от поддержки IE, его там не будет, можно вообще про него забыть как страшный сон года через два))))
Просто у меня друг пользуется stylys и autoprefixer, я вижу, что работает это не очень быстро (где-то больше секунды). Наверно если использовать компилятор sass и autoprefixer результат будет таким же, меня это не устраивает, но я никому ничего не навязываю. Сколько разработчиков, столько и подходов, это нормально.
nort1986: больше секунды это нормально когда стилей под несколько десятков тысяч строк.
Ну и еще есть куча факторов, типа уменьшение обращений к диску и т.д. in-memory кэш и всякие другие извращения.
zooks: ну да, кому нравится рубиподобный синтаксис, тому лучше пользоваться stylys, тут вы абсолютно правы. Я про это уже писал, я похожие свойства группирую через @extend, а миксины использую для префиксов, или для быстрого задания свойств. К примеру @include logo(15px, 15px) у меня преобразуется в width:15px, height: 15px, display: block, text-decoration: none. Мне очень удобно, хотя кому-то это не нравится))) Это нормально.
Я выше тоже про это писал, у меня друг пользуется stylys и autoprefixer’ом. И я видел как он работает. Он сделал изменение, обновил браузер, а они не вступили в силу, мы кое чего не успевали поэтому работали быстро. После этого я решил autoprefixer’ом не пользоваться. Смотрите он из stylys генерит css-ку, потом эта css-ка просматривается autoprefixer’ом и еще раз генерится (подставляются префиксы), я видел что работает это не быстро.
Если на то пошло, то если человек пользуется постпроцессорами, то пусть и пользуется ими, насколько я знаю, там можно и extend-ы делать и переменные задавать. Фактически постпроцессоры могут заменить less, sass и stylys. Просто смотрите при использовании препроцессора формируется css-ка и потом она просматривается постпроцессором. Это не может быть быстро. У меня проектна 6 000 строчек с миксинами, compas-ом и моим css-framework-ом генерится за 4 милисекунды. Получается потом autoprefixer будет его просматривать, тоже сгенерит префиксы за сколько-то, я сомневаюсь, что это быстро будет. Если пользоваться, то пользоваться чем-то одним, так быстрее будет. А так действительно штука хорошая, тут кто к чему привык.
Написано 4 минуты назад
styles + что угодно будет в разы медленнее gulp-sass + autoprefixer как минимум потому что stylus в 10 раз медленнее чем libsass и в
5 раз медленнее less. Сам же автопрефиксер работает очень быстро, так как нет операций с файловой системой и т.д.
Вы видили пример комбинации медленного препроцессора и быстрого пост процессора. Если вы добавите autoprefixer к своей сборке вы не почувствуете разницы особой в плане скорости компиляции. В этом суть.
Кидаться же в крайности я смысла не вижу (типа либо только пре процессоры либо только пост процессоры). Они очень хорошо дополняют друг дружку. Хотя не скрою что возможность кастомайзить синтаксис под себя меня привлекает, но мне проще дополнить существующие препроцессоры.
Почему мы решили отказаться от LESS в пользу SCSS: сравнение препроцессоров CSS
Дата публикации: 2018-05-22
От автора: прежде всего, что такое препроцессор? Вкратце препроцессор – это программа, модифицирующая данные под входные требования другой программы. Препроцессоры CSS – это скриптовый язык, расширяющий возможности обычного CSS переменными, правилами вложенности, функциями и логическими блоками.
Зачем мне его использовать?
Часто вы будете попадать в ситуацию, когда придется использовать одинаковое значение для определенного свойства в разных местах. Например, сначала вы указали красный первичным цветом сайта. Потом вам необходимо сменить его на зеленый.
С переменными вам не нужно искать и заменять все упоминания красного в стилях. Вы один раз определяете значение переменной, например, «primary color», а затем используете эту переменную как значение.
Значение primary color меняется в одном месте. Можно также импортировать CSS файлы из других источников, не думая о количестве сетевых запросов, так как перед компиляцией их все можно объединить в один файл.
Благодаря вложенной природе CSS препроцессоров, вы получите компактный код с таким же результатом. В основе LESS и SCSS лежит принцип DRY, который расшифровывается как «Don’t repeat yourself» или «не повторяйтесь».
Хотите узнать, что необходимо для создания сайта?
Посмотрите видео и узнайте пошаговый план по созданию сайта с нуля!
Что не так с LESS?
В сети уже полно обсуждений о том, что лучше: LESS или SCSS. Поэтому я не буду подробно раскрывать обе темы. Вместо этого я расскажу про маленькие проблемы, которые у меня возникли с LESS.
Хотя этот сценарий реален не для всех, лучше использовать разные идентификаторы для разделения элементов.
SCSS поддерживает традиционные логические выражения типа if/else, блоки и циклы. Guarded миксины в LESS легче для глаза, но их сложнее понять.
Можно сделать с помощью LESS…
… или просто с помощью SCSS.
LESS определяет лишь один guarded миксин. Поэтому нельзя просто передать второй аргумент и обработать его в том же миксине, продублировав код для всех возможных сценариев. На самом деле, LESS (меньше) значит больше (игра слов).
Я знаю, что можно сократить код, используя аугментированные значения в качестве имен свойств для этого случая, но проблема в том, что я не могу условно сопоставлять две разные части одного и того же миксина с LESS.
С таким кодом головной боли больше…
Хотите узнать, что необходимо для создания сайта?
Посмотрите видео и узнайте пошаговый план по созданию сайта с нуля!
Чтобы достичь такого же результата с помощью 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 намного сложнее, чем использовать препроцессор с парой проблем.
Автор: Kaan Kavuştuk
Редакция: Команда webformyself.
Хотите узнать, что необходимо для создания сайта?
Посмотрите видео и узнайте пошаговый план по созданию сайта с нуля!
Хотите узнать, что необходимо для создания сайта?
Посмотрите видео и узнайте пошаговый план по созданию сайта с нуля!
SASS против LESS
«Какой препроцессорный язык стоит использовать для CSS?» является очень актуальным вопросом в последнее время. Несколько раз меня спрашивали об этом лично, и казалось бы, каждые пару дней этот вопрос поднимался в сети. Очень приятно что беседа перешла из темы о плюсах и минусах препроцессинга к обсуждению какой же язык является лучшим. За дело!
Если быть кратким: SASS.
Немного развернутый ответ: SASS лучше по всем пунктам, но если вы уже счастливы с LESS — это круто, по крайней мере вы уже упростили себе жизнь используя препроцессинг.
Развернутый ответ: ниже
График обучения с Ruby и командной строкой
Единственным пунктом является синтаксис. Для компиляции созданных вами файлов стоит использовать такое приложение как CodeKit. Вы должны знать основы Ruby или командной строки или еще чего-то другого. Наверное вам стоит это знать, но не обязательно, так что это не играет большой роли.
В помощь CSS3
С любым из языков вы можете создавать собственные примеси для упрощения жизни с префиксами. Так что здесь нет победителя. Но знаете ли вы как сделать так, чтобы не обновлять эти префиксы во своих своих проектах? (Нет, не знаете). Также вам, скорей всего, не придется обновлять ваш собственный файл с примесями. SASS позволяет использовать Compass, благодаря автообновлениям которого вы можете забыть о проблемах с префиксами. Конечно же вы можете обновлять программное обеспечение и время от времени его компилировать, но это тривиальная задача и не стоит на этом зацикливаться.
Так что все это сводится к следующему: у SASS есть Compass, а у LESS его нет. На самом деле все немного запутанней. Все попытки создать проект типа Compass для LESS потерпели неудачу. Дело в том, что LESS не является достаточно сильным языком, что бы сделать это корректно. Немного подробней будет ниже.
Способности языка: логика/циклы
LESS позволяет создавать «защищенные примеси». Эти примеси вступят в силу только в случае если условие верно. Допустим вы захотите поменять цвет фона, который будет зависеть от текущего цвета текста. Если цвет текста «достаточно светлый» вы, наверное, захотите сделать темный фон. Если же он «достаточно темный» — вы захотите светлый фон. Таким образом у вас получится примесь, разбитая на две части с этими «защитниками», которые гарантируют что только один из них будет исполнен.
После использования вы получите подходящий фон:
Это очень просто, но суть, надеюсь, понятна. Вы можете делать вещи гораздо круче этого. LESS также позволяет делать ссылающейся на себя рекурсии, примеси которых могут вызывать самих себя с обновленными значениями.
На этом логика/циклы в LESS и заканчиваются. SASS обладает актуальными логическими и циклическими операторами. if/then/else, цикл for, цикл while и цикл each. Без каких либо трюков, настоящее программирование. SASS является достаточно надежным языком, что делает возможным использование Compass.
Лаконичный кусок кода:
Превращается этот код в монстра ниже (который, к сожалению, нужен в целях кроссбраузерности):
Сайты
Сайт LESS более красив и удобен. Нельзя сказать что документация SASS ужасна, она достаточно хорошо наполнена и вы можете найти в ней все что душа пожелает. Но как показывает практика, фронтенд разработчика привлекает красивый интерфейс, что дает LESS преимущество. Бесспорно, это играет большую роль и LESS выигрывает эту партию. Хотя все может поменяется.
@extend концепция
Допустим вы создали класс с неким набором стилей. Затем вам понадобится создать еще один, который будет как предыдущий, но с некими дополнениями. LESS позволяет сделать это так:
Вы это видите? SASS переопределяет селекторы, и это более эффективный путь.
Обработка переменных
SASS имеет странное свойство — если вы переопределите «глобальную» переменную «локальной», глобальная переменная примет ее значение. Немного странно.
Это трюк может быть полезным, но он совсем не интуитивен, особенно если вы пишете на Javascript.
Победитель: надо бросить монетку 🙂
Работа с правилами media
С помощью SASS или LESS вы можете объединить эти стили используя вложения.
«respond-to» — довольно таки крутая техника SASS (ознакомьтесь с кодом Chris Eppstein, Ben Schwarz, и Jeff Croft).
Дальше использовать их можно очень лаконично:
Метематика
В основном, математическая часть в обеих языках довольно похожа, но все же есть некоторые странности при обработке единиц измерения.
Например, LESS возьмет за единицу измерения значение первой переменной, игнорируя все остальные.
SASS позволяет проводить математические операции с «неизвестными» единицами измерения, которые могут появиться до следующего обновления. LESS этого не позволяет. Есть еще более странные отличия, например, как SASS умножает числа с единицами измерения, но об этом не сегодня.
Победитель: SASS (с натяжкой)
Развитие
За время написания статьи…
Количество коммитов за последний месяц LESS: 11
Количество коммитов за последний месяц SASS: 35
Ни один из этих пунктов не может твердо определить какой же проект является более активным, но, кажется, цифрам больше нравится SASS. Насколько я понял, главные разработчики обеих языков, продолжают работать над этими проектами, как только у них появляется немного свободного времени между разработкой других новых, не менее важных проектов.