- Превод
„Кой език за предварителна обработка трябва да използвате за CSS?“ е много актуална тема напоследък. Няколко пъти ме питаха лично за това и изглежда, че на всеки няколко дни този въпрос се повдигаше в мрежата. Много е приятно, че разговорът премина от темата за плюсовете и минусите на предварителната обработка към дискусията кой език е най-добрият. Захващам се за работа!
Накратко: SASS.
Леко разширен отговор: SASS е по-добър във всички аспекти, но ако вече сте доволни от LESS е готино, поне вече сте улеснили живота си, като използвате предварителна обработка.
Планирайте обучението с Ruby и командния ред
Единственият момент е синтаксисът. За да компилирате файловете, които създавате, трябва да използвате приложение като CodeKit. Трябва да знаете основите на Ruby или командния ред или каквото и да било. Вероятно трябва да знаете това, но не непременно, така че всъщност няма значение.Победител: не.
CSS3 помощ
С всеки от езиците можете да създадете свои собствени миксини, за да улесните живота с префикси. Така че тук няма победител. Но знаете ли как да избегнете актуализирането на тези префикси във вашите проекти? (Не, не знаете). Освен това най-вероятно няма да ви се налага да актуализирате своя собствен файл с миксини. SASS ви позволява да използвате Compass, благодарение на които автоматичните актуализации можете да забравите за проблемите с префиксите. Разбира се, можете да актуализирате софтуера и да го компилирате от време на време, но това е тривиална задача и не бива да се спирате на това.Така че всичко се свежда до това: SASS има компас, но LESS не... Всъщност всичко е малко по-объркващо. Всички опити за създаване на проект тип Compass за LESS са неуспешни. Въпросът е, че LESS не е достатъчно силен език, за да направи това правилно. Малко повече подробности ще бъдат по-долу.
Победител: SASS
Езикова способност: логика / цикли
LESS ви позволява да създавате "защитени миксини". Тези примеси ще влязат в сила само ако условието е вярно. Да приемем, че искате да промените цвета на фона, който ще зависи от текущия цвят на текста. Ако цветът на текста е "достатъчно светъл", вероятно искате да направите фона тъмен. Ако е „достатъчно тъмен“, искате светъл фон. По този начин имате микс, разделен на две, с тези "протектори", които гарантират, че само един от тях ще бъде изпълнен.ПО-МАЛКО
.set-bg-color (@ text-color) when (светлина (@ text-color)> = 50%) (background: black;) .set-bg-color (@ text-color) when (светлина (@text -цвят)< 50%) {
background: #ccc;
}
След употреба ще получите подходящ фон:
ПО-МАЛКО
.box-1 (цвят: # BADA55; .set-bg-color (# BADA55);)
Много е просто, но се надявам да схванете идеята. Можете да правите много по-готини неща от това. LESS също ви позволява да правите рекурсии за саморефериране, които миксините могат да наричат себе си с актуализирани стойности.
ПО-МАЛКО
.loop (@index) когато (@index> 0) (.myclass (z-index: @index;) // Извикайте себе си .loopingClass (@index - 1);) // Спиране на цикъла .loopingClass (0) () // Извежда неща .loopingClass (10);
Това е мястото, където логиката / циклите в LESS свършват. SASS има актуални булеви и циклични оператори. if / then / else, цикъл for, цикъл while и всеки цикъл. Без трикове, истинско програмиране. SASS е достатъчно здрав, за да направи Compass възможен.
Например, Compass има миксин заден планкойто е толкова мощен, че можете да поставите каквото искате в него и в крайна сметка да получите точно това, от което се нуждаете. Снимки, градиенти и всякакви комбинации от тях, разделени със запетаи - и получавате желания резултат (включително префикси и всичко останало).
Кратък код:
SCSS
.bam (@include background (image-url ("foo.png"), линеен градиент (горе вляво, # 333, # 0c0), радиален градиент (# c00, #fff 100px));)
Този код се превръща в чудовището по-долу (което, за съжаление, е необходимо за съвместимост между браузъри):
CSS
.bam (фон: url ("/ foo.png"), -webkit-gradient (линеен, 0% 0%, 100% 100%, color-stop (0%, # 333333), color-stop (100%)) # 00cc00)), -webkit-градиент (радиален, 50% 50%, 0, 50% 50%, 100, цветен стоп (0%, # cc0000), цветен стоп (100%, #ffffff)); фон; : url ("/ foo.png"), -webkit-linear-gradient (горе вляво, # 333333, # 00cc00), -webkit-radial-gradient (# cc0000, #ffffff 100px); фон: url ("/ foo .png "), -moz-linear-gradient (горе вляво, # 333333, # 00cc00), -moz-radial-gradient (# cc0000, #ffffff 100px); фон: url (" / foo.png "), - o-linear-gradient (горе вляво, # 333333, # 00cc00), -o-radial-gradient (# cc0000, #ffffff 100px); фон: url ("/ foo.png"), -ms-linear-gradient ( горе вляво, # 333333, # 00cc00), -ms-radial-gradient (# cc0000, #ffffff 100px); фон: url ("/ foo.png"), линеен градиент (горе вляво, # 333333, # 00cc00) , радиален градиент (# cc0000, #ffffff 100px);)
Победител: SASS
Победител: ПО-МАЛКО
@разширена концепция
Да приемем, че сте създали клас с определен набор от стилове. След това трябва да създадете още един, който ще бъде като предишния, но с някои допълнения. LESS ви позволява да го направите по следния начин:ПО-МАЛКО
.module-b (.module-a (); / * Копира всичко от .module-a долу * / граница: 1px плътно червено;)
Всъщност това е редовно „включване“. Можете също да използвате тази вложка в SASS, но е по-добре да го направите с помощта @разшири . @разширине просто копира стилове от .модул-а v .модул-б(което създава раздут файл), той променя името на селектора .модул-ана .module-a, .module-bв компилирания CSS (който е по-ефективен начин).
SCSS
.module-a (/ * Купчина неща * /) .module-b (/ * Някакъв уникален стил * / @extend .module-a;)
Компилира на:
CSS
.module-a, .module-b (/ * Куп неща * /) .module-b (/ * Някакъв уникален стил * /)
Можеш ли да го видиш? SASS отменя селекторите и това е по-ефективен начин.
Победител: SASS
Променлива обработка
LESS използва @, SASS използва $. Знакът за долар не се използва в CSS, което не е така за @. Използва се за деклариране на @keyframes или @media блокове. Може да си мислите, че използването на един или друг специален знак е въпрос на вкус, но мисля, че SASS има предимство тук именно защото не обърква основните понятия.SASS има странно свойство - ако замените "глобална" променлива с "local", глобалната променлива ще приеме стойността си. Малко странно.
SCSS
$ цвят: черен; .scoped ($ цвят: бял; цвят: $ цвят;) .unscoped (// LESS = черно (глобално) // SASS = бяло (презаписано от локално) цвят: $ цвят;)
Този трик може да бъде полезен, но изобщо не е интуитивен, особено ако пишете на Javascript.
Победител: хвърляне на монета :)
Работа с медийни правила
Почти всеки от нас започва да работи с правилата @media, добавя блокове с тях в долната част на основната страница със стилове. Това работи, но води до разделяне на стиловете, например:CSS
.some-class (/ * Стил по подразбиране * /) / * Стотици редове на CSS * / @media (макс. ширина: 800px) (.some-class (/ * Отзивчиви стилове * /))
Със SASS или LESS можете да комбинирате тези стилове чрез влагане.
SCSS
.some-class (/ * Стил по подразбиране * / @media (макс. ширина: 800 пиксела) (/ * Отзивчиви стилове * /))
„Отговор на“ е доста готина техника на SASS (вижте кода на Крис Епщайн, Бен Шварц и Джеф Крофт).
SCSS
= отговор на ($ име) @if $ name == малък екран @екран само за медия и (мин. ширина: 320 пиксела) @content @if $name == голям екран @екран само за медия и (мин. ширина: 800px) @content
Тогава можете да ги използвате много накратко:
SCSS
.ширина на колоната: 25% + ширина на отговор (малък екран): 100%
Забележка: за да използвате тази техника, ще ви трябва SASS 3.2, който все още е в алфа версия, можете да го инсталирате с командата gem инсталирате sass --pre... Мисля, че не трябва да има съмнение, че това е наистина полезно нещо в развитието.
Победител: SASS
Метематика
По принцип математиката е доста сходна и на двата езика, но все още има някои странности при боравене с единици.Например LESS ще приеме стойността на първата променлива като единица, игнорирайки всички останали.
ПО-МАЛКО
div (ширина: 100px + 2em; // == 102px (странно))
SASS ще ви даде да се разбере, че тук се крие грешка:
Несъвместими единици: "em" и "px"... Разбира се, това е спорен въпрос кое е по-добре - грешка или неправилна стойност, но лично аз съм за първото. Особено ако предпочитате променливите пред числата, това прави много трудни за проследяване.
SASS ви позволява да извършвате математически операции с "неизвестни" мерни единици, които може да се появят преди следващата актуализация. LESS не позволява това. Има още по-странни разлики, като например как SASS умножава числата с единици, но това не е за това днес.
Победител: SASS (разтягане)
Синтаксисът на SASS ме харесва повече от SCSS заради своята краткост. Но тежкото влагане на стилове в SASS може бързо да премахне всички предимства на неговата краткост. Във всеки случай разликата между SASS и SCSS не е критична. LESS е по-близо до SCSS, отколкото SASS. И като цяло е същото. Няма много разлики, но няколко от тях коренно променят баланса на силите.
1. ПО-МАЛКО - може от страна на клиента, използвайки JS.
По-точно, той не е, че може, той е създаден за това. Обичайната практика за използване на LESS код е:
Именно тогава възможността за компилиране на сървъра (както в js, така и в ruby) беше завинтена върху него.
На пръв поглед някакво странно свойство. Защо да компилирате от страна на клиента, когато можете да компилирате перфектно на сървъра и да сервирате готов компресиран CSS, както сме свикнали със SASS?
Причината става очевидна след разглеждане на неописуемите последни редове на документа LESS:
@height: `document.body.clientHeight`;
Такава малка самотна линия дава възможности, за които дизайнерите на оформление са мечтали само от началото на овладяването на стиловете. Обадете се от CSS клиентския Java скрипт и вземете предвид действителните настройки на браузъра, когато създавате стиловете.
Тоест сега имаме възможност първо да заредим DOM и след това да създадем специален CSS за него точно от страна на клиента. След това помислете сами какви възможности отваря това.
Друг е въпросът дали вашият проект има нужда от това. Ясно е, че всички са свикнали с клиентската неяснота/независимост и оформление в стил „правим го универсално, така че малко или много да се показва за всички при всякакви резолюции“. Но това не е причина да забравяме, че сега има такава възможност и с нея можете да направите, например, много плавно оформление.
2. LESS, за разлика от SASS/SCSS, няма логика.
LESS няма if / then, for и т.н. Въпреки че, като се има предвид, че JS е лесно вграден в него, мисля, че логиката е напълно възможна да го прецака. Не съм го пробвал.
3. В LESS е по-лесно да се смесват + смесват класове.
Много ми хареса факта, че в LESS можете да включите в дефиницията на свойствата на други класове. Самият клас е миксин. Това е друга функция, която не се намира в SASS / SCSS. Можете да включите обикновен CSS файл в LESS и да използвате неговите класове, за да дефинирате вашите свойства. Например:
Увийте (
обвиване на текст: обвиване;
бяло пространство: предварително обвиване;
бяло пространство: -moz-pre-wrap;
word-wrap: break-word;
}
предварително (.обвивка)
Резюме
С изключение на 1-ва точка разликата не е голяма и изборът е голям за аматьора.
Лично за мен LESS изглежда по-привлекателен поради своята простота. Никога не съм имала нужда от цикли и условни условия в стиловете. Има класически помощни програми като "box-shadow, linear-gradient, darken" в LESS.
Да, много готови библиотеки вече са написани за SASS (
Напоследък писах много за Sass, но научих от някои скорошни коментари, че не всеки има ясна представа какво е Sass. Нека изясним малко:
Когато говорим за Sass, обикновено имаме предвид препроцесора и езика като цяло. Казваме, например, „ ние използваме Sass", Или" ето микс на Sass ".
Междувременно Sass (препроцесор) позволява два различни синтаксиса:
- Sass, известен също като синтаксис с отстъп;
- SCSS, синтаксис, подобен на CSS.
История
Първоначално Sass беше част от друг препроцесор, Haml, който беше изобретен и написан от разработчиците на Ruby.
Следователно стиловете Sass използваха синтаксис, подобен на Ruby, без скоби, без точки и запетая, и без силен отстъп, като този:
// Променлива! Основен цвят = hotpink // Смес = border-radius (! Radius) -webkit-border-radius =! Radius -moz-border-radius =! Radius border-radius =! Radius .my-element color = ! ширина на основния цвят = 100% преливане = скрит .my-other-element + border-radius (5px)
Както можете да видите, разликата е осезаема в сравнение с обикновения CSS! Дори ако сте потребител на Sass (препроцесор), можете да видите, че това е много различно от това, с което сме свикнали.
Променливата се означава с! , не $, символ за присвояване на стойност =, не:. Доста необичайно.
Но така изглеждаше Sass до версия 3.0, пусната през май 2010 г., която въведе напълно нов синтаксис, наречен SCSS или Sassy CSS.
Целта му беше да доближи синтаксиса на Sass до CSS, правейки го по-съвместим с CSS:
// Променлива $ първичен цвят: hotpink; // mixin @mixin border-radius ($ радиус) (-webkit-border-radius: $ радиус; -moz-border-radius: $ радиус; border-radius: $ радиус;) .my-element (цвят: $ първичен -цвят; ширина: 100%; преливане: скрит;) .my-other-element (@include border-radius (5px);)
SCSS определено е по-близо до CSS, отколкото Sass. Разработчиците на Sass са работили усилено, за да сближат двата синтаксиса, като заменят! (знак на променлива) и = (знак за присвояване) към $ и: от CSS.
Следователно, когато стартирате нов проект, може да се чудите кой синтаксис да използвате. Позволете ми да покрия тази тема и да обясня плюсовете и минусите на всеки един от синтаксисите.
Плюсове на синтаксиса с отстъп на Sass
Въпреки че този синтаксис може да ви звучи малко странно, той има няколко интересни точки. На първо място, той е по-кратък и по-лесен за писане. В него няма скоби или точки и запетая, те не са необходими.
Още по-добре! Не се нуждае от @mixin или @include, когато е достатъчно просто: = и +.
Също така синтаксисът на Sass осигурява чисти стандарти за кодиране поради използването на отстъп. Тъй като грешният отстъп може да наруши цялата таблица със стилове .sass, това е първият приоритет, за да се гарантира, че кодът е чист и правилно форматиран.
Има само един метод за съставяне на Sass кодове: правилното им композиране.
Но внимавай! Отстъпът е логичен в Sass. Когато селекторният блок е с отстъп, това означава, че е вложен селектор.
Например:
Цвят на елемент-a: hotpink .element-b float: left ... извежда следния CSS: .element-a (цвят: 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!
Превод на статията " Каква е разликата между Sass и SCSS„Подготвен е от приятелски екип по проекта
Какви са основните задачи на препроцесора и кой да изберете: SASS или LESS, ще анализираме в тази статия. Първо трябва да дефинирате препроцесор - какво е това? Това е инструмент или инструмент, който модифицира конкретен код, като го трансформира с помощта на различни функции. Входът на процесора е кодът, който се описва с различни синтактични конструкции. Тези конструкции са разбираеми само за този инструмент. Може да замени различни сложни езикови конструкции или, напротив, да добави нови. Резултатът от програмата е код с по-ниско качество с премахнати конструкции.
За по-добро разбиране на термина препроцесор, разгледайте пример. Входът на тази програма е код, който съдържа различни думи, проблеми, запетаи и точки. Ако има функция за замяна на ключова дума в нейната кратка форма, тоест в съкращение, с пълно име, тогава изходът ще бъде изречение с разширен запис. Това е най-примитивното разбиране за това какво е препроцесор. По същество той съдържа по-сложни команди и възможности.
И така, тази програма предлага различни конструкции за простота и бързина на разработка и поддръжка на стилове.
Обикновено кодът е насочен към човешките характеристики:
- Четимост.
- Структурираност.
- Производителност.
Също така, когато разглеждат препроцесорите, програмистите се натъкват на концепцията за синтактична захар. Това са някои допълнения към езика за програмиране, които не влияят на получаването на допълнителни функции, но подобряват четливостта.
Основни видове
Най-често срещаните опции са LESS, SASS и Stylus. Така че, както вече беше идентифицирано по-горе, предимствата на използването на такива инструменти са за подобряване на текстовото съдържание, структура и производителност. Малко разработчици обаче използват подобни програми в работата си, тъй като смятат, че работата с тях е трудна и много функции не са ясни.
Програмата е най-популярната в този проблем. Тази програма е разработена през 2009 г. от екип програмисти. Има цялата функционалност на основно ниво. Основният недостатък е липсата на условни условия и цикли. Основното предимство на този инструмент е неговата яснота и лекота на използване, неговата функционалност може да бъде разширена с помощта на различни плъгини.
Синтактично страхотни стилови таблици
SASS е най-мощният препроцесор. Той е разработен от цял екип програмисти. Създаден е през 2007 г. като модул за HAML и също е написан на Ruby (има C++ порт). Освен това има по-широк набор от функции в сравнение с друга програма. За да разширите възможностите на Syntactical 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, тъй като и двете имат добри свойства и функционалност. Следователно изборът се определя от целите и задачите на програмиста.
От автора:първо, какво е препроцесор? Накратко, препроцесорът е програма, която модифицира данните, за да отговори на входните изисквания на друга програма. CSS препроцесорите са скриптов език, който разширява възможностите на обикновения CSS с променливи, правила за влагане, функции и логически блокове.
Защо да го използвам?
Често ще се окажете в ситуация, в която трябва да използвате една и съща стойност за конкретен имот на различни места. Например, първо сте посочили червено като основен цвят на сайта. След това трябва да го промените на зелено.
С променливите не е нужно да търсите и заменяте всички споменавания на червено в стилове. Вие дефинирате стойността на променлива веднъж, например "основен цвят", и след това използвате тази променлива като стойност.
Стойността на основния цвят се променя на едно място. Можете също да импортирате CSS файлове от други източници, без да се притеснявате за броя на мрежовите заявки, тъй като всички те могат да бъдат обединени в един файл преди компилация.
Благодарение на вложената природа на CSS препроцесорите, в крайна сметка ще получите компактен код със същия резултат. LESS и SCSS се основават на принципа DRY, който означава „Не се повтаряй“ или „Не се повтаряй“.
Предварителни процесори. Бърз старт
Какво не е наред с LESS?
Мрежата вече е пълна с дискусии кое е по-добро: LESS или SCSS. Затова няма да разглеждам подробно и двете теми. Вместо това ще говоря за малките проблеми, които имах с LESS.
SCSS използва $ за дефиниране на променливи и ПО-МАЛКО използва @. Тъй като CSS също използва символа @ за медийни заявки, импортиране и анимации на ключови кадри, това може да бъде объркващо за разработчиците.
Символът $ не се използва в CSS. Символът @ е в SCSS, но се използва за директивите @if, @else, @each, @for и @while.
Въпреки че този сценарий не е реалистичен за всички, най-добре е да използвате различни идентификатори за разделяне на елементи.
SCSS поддържа традиционните логически if / else изрази, блокове и цикли. Охранените миксини в LESS са по-лесни за окото, но по-трудни за разбиране.
Може да се направи с ПО-МАЛКО...
... или просто с помощта на SCSS.
LESS дефинира само един защитен миксин. Следователно не можете просто да предадете втория аргумент и да го обработите в същия миксин, дублирайки кода за всички възможни сценарии. Всъщност ПО-МАЛКО (по-малко) е повече (каламбур).
Знам, че е възможно да се съкрати кодът, като се използват увеличени стойности като имена на свойства за този случай, но проблемът е, че не мога условно да съпоставя две различни части от един и същи миксин в LESS.
С този код има повече главоболие...
Предварителни процесори. Бърз старт
Научете основите на работата с препроцесорите Less и Sass от нулата за по-малко от 2 седмици
... отколкото с това.
За да постигна същия резултат с LESS, трябваше да дефинирам предварително всичко, да напиша миксин, да получа позицията на индекса, да повторя с моята логика, докато индексът стане нула, и да извикам миксина ръчно.
Въпреки че това е моето лично мнение, струва ми се, че SCSS като цяло се справя по-добре с изчислителните и математическите стойности.
Какво му е наред?
LESS, от друга страна, е много по-сложно. Например, когато го използвам, не се опитвам да изчислявам. Но дори и да го направя, откога 100% минус 50px е равно на 50%?
ПО-МАЛКО, защо пренебрегвате стойностите на единиците?
Защо ме караш да уча патериците ти, когато вече знам CSS?
И последното нещо. Благодарение на проекта LibSass, SCSS има много обвивки за други езици като C, Go, PHP, Python, Dart и др.
Защо решихме да изоставим LESS в името на SCSS?
Докато разработвахме JotForm Cards, трябваше да обработим предварително стойности на променливите - предварителна компилация и кеширане от страна на сървъра едновременно; и всичко това трябваше да се направи перфектно.
Искахме потребителите да могат да персонализират външния вид на формулярите. Така че всички промени се показват незабавно и едновременно и се кешират на сървъра. За нашите потребители не искахме да стартираме обвивка LESS от страна на клиента, защото това ще отнеме изчислителната мощност на клиента - и много неща може да се объркат.
Ние не стартирахме цикъл на разработка с цел преминаване от LESS към SCSS. Но по средата на справянето с тези дребни проблеми, липсата на прилична опаковка за LESS беше последната капка, която преля.
Като се има предвид това, разликите между LESS и SCSS са по-малко важни от това, което ги обединява. В крайна сметка няма значение кой препроцесор използвате, стига да го използвате.
Опитът да управлявате огромен проект с един CSS файл и традиционна CSS структура е много по-трудно от използването на препроцесор с няколко проблема.
