CSS Preprocessors Sammenlignet Sass vs MINDRE
Der er en række CSS Preprocessor, LESS, Sass, Stylus og Swith CSS, for blot at nævne nogle få. CSS Preprocessor, som vi tidligere har sagt, er primært beregnet til at gøre CSS mere dynamisk, organiseret og produktiv. Men, spørgsmålet er, hvilket af dem gør jobbet bedst?
Nå, selvfølgelig, ville vi ikke se på hver enkelt af dem, i stedet vil vi kun sammenligne to af de mere populære: Sass og mindre. At afgøre, vi vil sammenligne de to i syv faktorer: den der udfører bedre får et punkt; I tilfælde af et slips vil begge blive tildelt et point.
Lad os begynde.
Installation
Lad os starte med det meget grundlæggende skridt, Installation. Både Sass og LESS er bygget på forskellige platforme, Sass kører på Ruby, mens LESS er et JavaScript-bibliotek (som det var faktisk også bygget på Ruby i første omgang).
Sass: Sass har brug for Ruby for at kunne arbejde, i Mac har dette været forudinstalleret, men i Windows skal du nok få det installeret, før du kan begynde at spille med Sass. Desuden skal Sass installeres via Terminal eller Command Prompt. Der er flere GUI-applikationer, du kan bruge på plads, men de er ikke gratis.
MINDRE: Mindre er bygget på JavaScript, så det er mindre nemt at knytte JavaScript-bibliotek til dit HTML-dokument. Der er også et par GUI-applikationer, der hjælper med at kompilere MINDER til CSS, og de fleste af dem er gratis og fungerer meget godt (f.eks. WinLess og LESS.app).
Konklusion: MINDRE er tydeligt i spidsen.
Udvidelser
Både Sass og LESS har udvidelser til hurtigere og lettere webudvikling.
Sass: I vores sidste indlæg havde vi diskuteret om Compass, den nuværende og populære Sass-baserede udvidelse. Kompas har en række Mixins til at skrive CSS3 syntaks på mindre tid.
Men Compass er ud over bare CSS3 Mixins, den har tilføjet andre meget nyttige funktioner som Hjælpere, Layout, Typografi, Grid Layout og endda Sprite Images. Det har også config.rb fil, hvor vi kan styre CSS output og nogle andre præferencer. Så kort sagt er Compass en alt-i-en-pakke til webudvikling med Sass.
MINDRE: LESS har også flere udvidelser, men i modsætning til Compass, der har alt, hvad vi har brug for på ét sted, er de adskilt, og hver af dem er bygget af forskellige udviklere. Dette vil ikke være et problem for erfarne brugere, men for dem, der lige er begyndt med MINDRE, skal de tage lidt tid at vælge de rigtige udvidelser, der passer til deres arbejdsgang.
Her er et par mindre udvidelser, som du måske skal medtage i dit projekt:
- CSS3 Mixins: MINDER Elementer, Preboot, MINDER MIXINTER.
- Grid: 960.gs, Frameless, Semantic.gs
- Layout: Endnu mindre
- Diverse: Twitter Bootstrap
Konklusion: Jeg tror vi er enige Sass og Compass er en stor duo, og Sprite-billedfunktionen er virkelig kickass, så man peger på Sass her.
Sprog
Hver CSS Preprocessor har deres eget sprog, og de er mest almindelige. For eksempel har både Sass og LESS variabler, men der er ingen signifikant forskel i det, medmindre Sass definerer variabler med en $ tegn mens mindre gør det med en @ skilt. De gør stadig det samme: gemme en konstant værdi.
Nedenfor vil vi undersøge nogle af de mest almindeligt anvendte sprog både i Sass og LESS (baseret på min erfaring).
nesting
Nestende regel er god praksis for at undgå at skrive selektorer gentagne gange, og både Sass og LESS har samme måde i nesting regler;
Sass / Scss og mindre
nav margin: 50px auto 0; bredde: 788px; højde: 45px; ul polstring: 0; margen: 0;
Men Sass / Scss tager denne metode et skridt videre ved at tillade os også at neste individuelle egenskaber, her er et eksempel:
nav margin: 50px auto 0; bredde: 788px; højde: 45px; ul polstring: 0; margen: 0; grænse: style: solid; venstre: width: 4px; farve: # 333333; højre: bredde: 2px; farve: # 000000;
Denne kode genererer følgende output.
nav margin: 50px auto 0; bredde: 788px; højde: 45px; grænsestil: solid; grænse-venstre-bredde: 4px; border-left-color: # 333333; grænse-højre bredde: 2px; grænse-højre-farve: # 000000; nav ul polstring: 0; margen: 0;
Konklusion: Nestende individuelle egenskaber er en god tilføjelse og overvejes bedste praksis, især hvis vi følger princippet DRY (Do not Repeat Yourself). Så jeg synes, det er klart, hvem der gør det bedre i dette tilfælde.
Mixins og Selector Arv
Mixins i Sass og LESS defineres lidt anderledes. I Sass bruger vi@mixin direktivet, mens vi MINDRE definerer det med klassevælgeren. Her er et eksempel:
Sass / SCSS
@mixin border-radius ($ values) border-radius: $ values; nav margin: 50px auto 0; bredde: 788px; højde: 45px; @include border-radius (10px);
MINDRE
.grænse (@radius) grænse-radius: @radius; nav margin: 50px auto 0; bredde: 788px; højde: 45px; .border (10px);
Mixins, i Sass og mindre, er vant til omfatte egenskaber fra et regelsæt til en anden regelsæt. I Sass, denne metode er taget videre med Selector Arv. Konceptet er identisk, men i stedet for at kopiere hele egenskaberne vil Sass udvide eller gruppere selektorer, der har de samme egenskaber og værdier ved hjælp af @forlænge direktiv.
Se dette eksempel nedenfor:
.cirkel border: 1px solid #ccc; grænse-radius: 50px; overløb: skjult; .avatar @extend .circle;
Denne kode vil resultere som;
.cirkel, .avatar grænse: 1px solid #ccc; grænse-radius: 50px; overløb: skjult;
Konklusion: Sass er et skridt foran med forskellige Mixins og Selectors Arv.
operationer
Både Sass og LESS kan lave grundlæggende matematiske operationer, men nogle gange vender de forskellige resultater. Se, hvordan de udfører denne tilfældige beregning:
Sass / SCSS
$ margin: 10px; div margin: $ margin - 10%; / * Syntaksfejl: Inkompatible enheder: '%' og 'px' * /
MINDRE
@ margin: 10px; div margin: @margin - 10%; / * = 0px * /
Konklusion: Sass gør i dette tilfælde det mere præcist; da% og px ikke er ækvivalent, skal det returnere en fejl. Selvom jeg faktisk håber, at det kan være noget 10px - 10% = 9px.
Fejlmeddelelser
Fejlmeddelelse er vigtig for at se, hvad vi gør forkert. Forestil dig tusindvis af kodeord og en lille smule fejl et sted i kaoset. Et klart fejlmeddelelse vil være den bedste måde at finde ud af problemet hurtigt.
Sass: I dette eksempel bruger jeg kun kommandoprompt til at køre kompilatoren. Sass vil generere en fejlmeddelelse, når der er invaliditet i koden. I dette tilfælde fjerner vi et semikolon på linje 6, og dette skal vise sig at være en fejl. Tag et kig på skærmbilledet nedenfor.
Da jeg først så denne meddelelse, kunne jeg næppe forstå det. Det ser også ud til, at Sass er lidt væk med hvor fejlen er. Det sagde, at fejlen er på linje 7, i stedet for 6.
MINDRE: Med det samme fejlscenarie er MINDRE underretning mere velpræsenteret, og det synes også at være mere præcist. Se et kig på dette skærmbillede:
Konklusion: LESS leverer bedre erfaring i denne sag og vinder hænder ned.
Dokumentation
Dokumentation er meget afgørende for hvert produkt; selv erfarne udviklere ville finde det svært at gøre tingene uden Dokumentation.
Sass: Hvis vi kigger på dokumentationen på det officielle websted, føler jeg mig selv som jeg er midt i et bibliotek, dokumentationen er meget omfattende. Men udseendet og følelsen, hvis det betyder noget for dig, er ikke motiverende til læsning, og baggrunden er almindelig hvid.
Præsentationen er meget mere som W3-dokumentation eller WikiPedia. Jeg ved ikke, om dette er standarden for at vise dokumentation på internettet, men det er ikke den eneste vej.
MINDRE: På den anden side er mindre dokumentation klarere uden for mange tekstforklaringer, og det dykker direkte ind i eksemplerne. Det har også god typografi og et bedre farveskema. Jeg synes det var derfor, at MINDRE tiltrak min opmærksomhed i første omgang, og jeg kan lære det hurtigere på grund af layout og præsentation af dokumentationen.
Konklusion: Den MINDRE dokumentationspræsentation er bedre, selvom Sass har mere omfattende dokumentation, så jeg tror, vi kan kalde denne sammen.
Endelig tanke
Jeg synes det er en klar konklusion, at Sass er bedre med en samlet score på 5 mod 3 for mindre. Det betyder dog ikke, at mindre er dårlig; de skal bare være bedre. I sidste ende er det stadig op til slutbrugerens beslutning at vælge præprocessoren efter eget valg. Det er Sass eller mindre, så længe de er komfortable og mere produktive, så er det vinderen i deres liste.
Endelig, hvis du har noget i tankerne om dette emne, er du velkommen til at dele det i kommentarfeltet nedenfor.
