CSS Preprocessors сравнява Sass срещу LESS
Има редица CSS Preprocessor, LESS, Sass, Stylus и Swith CSS, само за да назовем няколко. CSS Preprocessor, Както казахме често преди, целта е да се направи CSS на авторството по-динамичен, организиран и продуктивен. Но, Въпросът е кой от тях върши работата най-добре?
Е, разбира се, не бихме погледнали всеки един от тях, а ще сравним само две от най-популярните: Sass и LESS. За да решим, ние ще сравним двете в седем фактора: този, който работи по-добре, получава една точка; в случай на равенство, и двамата ще получат една точка.
Нека да започнем.
Инсталация
Нека започнем с много фундаменталната стъпка, Инсталация. И Sass, и LESS са изградени на различна платформа, Sass работи на Ruby, докато LESS е JavaScript библиотека (която тя е беше всъщност също е построен на Ruby първо).
Sass: Sass се нуждае от Ruby, за да работи, в Mac това е предварително инсталирано, но в Windows вероятно трябва да го инсталирате, преди да можете да започнете да играете с Sass. Освен това, Sass трябва да бъде инсталиран чрез терминала или командния ред. Има няколко GUI приложения, които можете да използвате на място, но те не са безплатни.
ПО-МАЛКО: LESS е изграден на базата на JavaScript, така че интелигентното LESS е толкова лесно, колкото свързването на JavaScript библиотеката към вашия HTML документ. Има и няколко GUI приложения, които могат да помогнат при компилирането на LESS в CSS и повечето от тях са безплатни и се представят много добре (например WinLess и LESS.app).
заключение: LESS е очевидно начело.
Разширения
И Sass, и LESS имат разширения за по-бързо и по-лесно уеб програмиране.
дръзки приказки: В последната ни публикация обсъдихме Compass, сегашното и популярно Sass базирано разширение. Компас има няколко Mixins за писане на CSS3 синтаксис за по-малко време.
Но Компас е извън просто CSS3 Mixins, той е добавил и други много полезни функции като Helpers, Layout, Typography, Grid Layout и дори Sprite Images. Тя също има config.rb файл, където можем да контролираме изхода на CSS и някои други предпочитания. Така че, накратко, Compass е пакет „всичко в едно“ за уеб разработка с Sass.
ПО-МАЛКО: LESS също има няколко разширения, но за разлика от Компас, който има всичко необходимо на едно място, те са разделени и всеки от тях е изграден от различни разработчици. Това няма да е проблем за опитни потребители, но за тези, които току-що започват с LESS, трябва да отделят известно време, за да изберат правилните разширения, които отговарят на техния работен процес..
Ето няколко разширения на LESS, които може да се наложи да включите в проекта си:
- CSS3 Mixins: LESS Елементи, Preboot, LESS Mixins.
- решетка: 960.gs, Без рамки, Semantic.gs
- оформление: Дори по-малко
- Разни: Twitter Bootstrap
заключение: Мисля, че трябва да се съгласим, че Sass и Compass са чудесен дует, а функцията на Sprite е наистина пикантна, така че една точка за Sass тук.
Езици
Всеки CSS Preprocessor има свой собствен език и те са най-често срещани. Например, както Sass, така и LESS имат променливи, но няма значителна разлика в него, освен ако Sass дефинира променливи с $ знак, докато МАЛКО го прави с @ знак. Те все още правят същото: съхранява постоянна стойност.
По-долу ще разгледаме някои от най-често използваните езици в Sass и LESS (въз основа на моя опит).
Разполагане
Правилото за гнездене е добра практика, за да се избегне многократното писане на селектори и както Sass, така и LESS имат еднакъв начин в правилата за влагане;
Sass / Scss и LESS
nav марж: 50px auto 0; ширина: 788px; височина: 45px; ul padding: 0; марж: 0;
Но Sass / Scss използва този метод като стъпка напред, като ни позволява също да се гнездят индивидуални свойства, ето един пример:
nav марж: 50px auto 0; ширина: 788px; височина: 45px; ul padding: 0; марж: 0; border: style: solid; ляво: width: 4px; цвят: # 333333; дясно: ширина: 2px; цвят: # 000000;
Този код ще генерира следния изход.
nav марж: 50px auto 0; ширина: 788px; височина: 45px; граничен стил: твърдо; ширина на границата отляво: 4px; border-left-color: # 333333; border-right-width: 2px; цвят-десен-граница: # 000000; nav ul padding: 0; марж: 0;
заключение: Гнезденето на индивидуални свойства е хубаво допълнение и се разглежда най-добри практики, особено ако следваме принципа DRY (Не повтаряй себе си). Така че мисля, че е ясно кой се справя по-добре в този случай.
Mixins и Selector Inheritance
Mixins в Sass и LESS се дефинират малко по-различно. В Sass ние използваме@mixin директива, докато в LESS го определяме с класа селектор. Ето един пример:
Sass / SCSS
@mixin border-radius ($ values) стойности на граничния радиус: $; nav margin: 50px auto 0; ширина: 788px; височина: 45px; @include border-radius (10px);
ПО-МАЛКО
.граница (@radius) border-radius: @radius; nav margin: 50px auto 0; ширина: 788px; височина: 45px; .border (10px);
Mixins, в Sass и LESS, е свикнал включва свойства от един набор от правила към друг набор от правила. В Sass този метод е продължен Наследяване на селектора. Концепцията е идентична, но вместо да копира всички свойства, Sass ще разшири или групира селектори, които имат същите свойства и стойности, като @разшири директива.
Разгледайте този пример по-долу:
.кръг border: 1px solid #ccc; граничен радиус: 50px; overflow: hidden; .avatar @extend .circle;
Този код ще се получи като;
.кръг, .avatar border: 1px solid #ccc; граничен радиус: 50px; overflow: hidden;
заключение: Sass е една крачка напред от отделните Mixins и Selectors Inheritance.
Операции
И Sass, и LESS могат да извършват основни математически операции, но понякога се връщат различни резултати. Вижте как те извършват това случайно изчисление:
Sass / SCSS
$ марж: 10px; div margin: $ margin - 10%; / * Синтактична грешка: Несъвместими единици: '%' и 'px' * /
ПО-МАЛКО
@margin: 10px; div margin: @margin - 10%; / * = 0px * /
заключениеSass, в този случай, го прави по-точно; тъй като% и px не са еквивалентни, трябва да върне грешка. Въпреки, че всъщност се надявам, че може да бъде нещо подобно 10px - 10% = 9px.
Известия за грешка
Уведомлението за грешка е важно, за да видите какво вършим погрешно. Представете си хиляди редове от код и малко грешка някъде в хаоса. Чисто съобщение за грешка ще бъде най-добрият начин бързо да разберете проблема.
дръзки приказки: В този пример използвам командния ред, за да стартирам компилатора. Sass ще генерира съобщение за грешка, когато има невалидност в кода. В този случай ще премахнем една точка и запетая в ред 6 и това ще се превърне в грешка. Погледнете скрийншота по-долу.
Когато за първи път видях това известие, едва мога да го разбера. Също така, изглежда, че Sass е малко по-близо до мястото, където грешката е. Той каза, че грешката е включена ред 7, вместо 6.
ПО-МАЛКО: С един и същ сценарий за грешка, LESS уведомление е по-добре представено и също изглежда по-точно. Погледнете тази снимка на екрана:
Заключение: LESS доставя по-добър опит по този въпрос и печели ръце.
документация
Документацията е много важна част за всеки продукт; дори и опитни разработчици биха имали трудности да правят неща без документация.
дръзки приказки: Ако погледнем документацията на официалния сайт, аз лично се чувствам като в библиотека, документацията е много изчерпателна. И все пак видът и усещането, ако това е важно за вас, не е мотивационно за четене, а фонът е обикновен бял.
Представянето е много повече като W3 документация или WikiPedia. Не знам дали това е стандартът за показване на документация в интернет, но това не е единственият начин.
ПО-МАЛКООт друга страна, LESS документацията е по-ясна, без много текстови обяснения и тя потапя направо в примерите. Тя също има добра типография и по-добра цветова схема. Мисля, че затова LESS привлече вниманието ми на първо място и аз мога да го науча по-бързо, поради оформлението и представянето на документацията.
заключение: По-добро е представянето на документацията на LESS, въпреки че Sass има по-изчерпателна документация, така че мисля, че можем да наречем тази връзка равна.
Заключителна мисъл
Мисля, че това е ясен извод Sass е по-добре с общ резултат 5 срещу 3 за по-малко. Това обаче не означава, че LESS е лошо; те просто трябва да бъдат по-добри. В крайна сметка, все още е до решението на крайния потребител да избере препроцесора по техен избор. Независимо дали става дума за Sass или LESS, стига да са удобни и по-продуктивни, тогава това е победителят в списъка им.
И накрая, ако имате предвид нещо по този въпрос, можете да го споделите в полето за коментари по-долу.
