MINDER och Sass syftar till att uppnå samma sak, och är verkligen så lika att du enkelt kan förvirra de två, men är de verkligen skapade lika? Finns det något som man kan göra som den andra inte kan?
På en funktion som grundar sig har varje syntax ett eller två saker som den andra inte gör. Trots det faktum att jag ursprungligen drogs till MINDRE enkelhet kunde jag på sikt inte hjälpa till med att sugas in av några nyckelfunktioner som gör Sass riktigt kraftfull. Följ med som jag blåsar med några av de fantastiska och unika funktionerna i Sass.
MINDRE vs SASS
Både Sass och LESS har funnits ganska länge nu men det verkar som om de verkligen slog deras steg under 2011 och fick mycket popularitet. Båda ger utmärkt sätt att utöka CSS till att vara mer programmerarevänlig, vilket leder till mer logisk och koncis kod som utnyttjar betydligt mindre upprepning.
Vem är mer vänlig?
Nyligen här på Design Shack har jag gett mycket uppmärksamhet åt MINDRE. Givetvis tycker jag att det är mer tilltalande för de två alternativen. Vissa kommer att argumentera mot denna uppfattning tills de är blåa i ansiktet, men det enkla faktumet är att MINDRE har en riktigt bra inställning: använd en enkel .js-fil för att testa och kompilera koden automatiskt med en användarvänlig app: Mindre. app.
Oavsett hur mycket du tycker att varje CSS-utvecklare borde känna Ruby och vara en Terminal Whiz, är verkligheten att många inte passar den här beskrivningen alls och vill hellre spendera dagen att lära sig en sak (LESS) istället för två (Sass + hur Ruby gems fungerar).
Beviljas, Sass kräver bara en teeny liten bit av terminalanvändning som nästan alla kan hantera, men du skulle bli förvånad över hur många människor som är bortvändna på grund av detta.
Inte så snabbt
Nyligen har detta landskap ändrats ganska dramatiskt. Lösningar som CodeKit poppar upp som gör att skriva Sass och utmatar CSS varje gång så enkelt som att använda Sass.
Faktum är att CodeKit kompilerar automatiskt LESS, Sass, Stylus och CoffeeScript-filer. Allt du behöver göra är att släppa i din projektmapp och ditt arbete är klart. Så mycket för att MINDRE är mer vänliga!
Vem är mer kraftfull?
För många utvecklare är argumentet som är lättare att implementera ganska småaktigt med tanke på att både LESS och Sass är ganska enkla att börja använda. Det verkliga argumentet kommer då till makten: vilket språk kan göra mer?
Svaret är inte fruktansvärt enkelt. Det visar sig att både LESS och Sass har unika funktioner som inte delas av den andra. Men det måste sägas att i detta område drar Sass verkligen några imponerande slag. Låt oss ta en titt på två av mina favoriter: @extend och kontrollstrukturer.
Sass @extend
Varje gång jag säger någonting om MINDRE börjar folket i Sass-läget rasa om Sass '@extend-kommandot. Det visar sig att det finns en bra anledning till detta: det är faktiskt ganska dang användbart.
Den magiska bakom @extend är att det låter dig ställa in väljare som piggyback på andra väljare och låna sina fastigheter. Låt oss säga att du stylade en blogg och ville ha två olika stiluppsättningar: en uppsättning för en kommentar och en annan för några svar på den kommentaren. Din stil för varje ser nästan identisk ut, med några undantag:
Alternativt kan du bara använda? .Reply? klass för olika stilar, men det här skulle kräva att du tillämpar både? .comment? och? .reply? klasser till ditt svar HTML divs. Så hur kan vi hålla vår markering smal men göra den här koden mindre repetitiv?
Med Sass '@extend är denna process super lätt. När vi väl har vår första väljare på plats, skriver vi helt enkelt? @Extend? plus namnet på den väljare som vi vill stjäla från och hela koden relaterad till den första väljaren kommer att tillämpas på den andra. Härifrån kan vi gå in och tillämpa våra undantag, tillägg etc.
Observera att vi använder den nya .scss-syntaxen.
CSS-utgång
Utgången från detta @extend-kommandot är fin och ren och representerar verkligen hur vi borde ha kodat vår CSS i första hand. Sass hittar automatiskt både de delade och unika egenskaperna och ställer in var och en till de lämpliga selektorerna.
Så varför gör du inte det här först? Stor fråga! Det kan du faktiskt göra just det. Sass-syntaxen representerar emellertid en något mer linjär tankeprocess som är lättare för vissa att bryta sig om.
Tänk på att detta är ett alltför förenklat exempel, om du arbetade med ett stort projekt med massor av väljare, skulle fördelarna med Sass vara ännu tydligare.
Går längre
Vidare kan dess användbarhet hantera ganska lite komplexitet.Till exempel kan du använda flera sträcker sig på en enda väljare:
Du kan också kedja @extends. Detta gör att du gradvis kan bygga lager av komplexitet på ett lättförståeligt sätt.
Som du kan se är det faktiskt lite lättare att tolka än den sammanställda CSS-formuläret, vilket är vackert koncist men kan vara något förvirrande.
För att läsa mer om Sass @extends, kolla in den officiella dokumentationen från Sass webbplats.
Kontrolldirektiv
Sass @extend-kommandot är definitivt ett mördare argument för att gå med Sass over LESS. Det är super användbart och hjälper till att hålla din komplexa CSS mousserande ren, organiserad och lätt att läsa.
Men på den galna skalan kan @extends vara ganska låg. Om du verkligen vill se var Sass-folket gick iväg till något sketchy territorium, bör du kolla in kontrolldirektiven, som sätter in några seriösa programmeringskonstruktioner i CSS.
Alla du hardcore fans av ren CSS som inte är säkra på Sass i första hand kommer definitivt inte att tycka om vad du ska se. Men de av oss som är öppna för att ha kul med CSS och redan älskar att programmera, blir det väldigt intressant.
Inte för dag till dag Styling
Om du tar en titt på exemplen nedan och bestämmer att de verkar för komplicerade för att du ska kunna använda i dina projekt, har du förmodligen rätt. De kommer med denna varning direkt från Sass-utvecklarna:
• Observera att kontrolldirektiv är en avancerad funktion, och rekommenderas inte under den dagliga styling. De finns främst för användning i mixins, särskilt de som ingår i bibliotek som Compass, och kräver så stor flexibilitet.
Om uttalanden
Om du aldrig trodde att du skulle se dagen när om uttalanden och CSS träffades, hade du fel. Sass stöder grundläggande if / else-funktionalitet och sammanställer den till CSS. Till exempel, i exemplet nedan vill vi att textfärgen är svart i alla fall utom de där basfärgen redan är svart, så ställer vi den till vit.
Så låt oss säga att vi använder det här snippet i en viss mall som vi har ställt upp någon annanstans och importerar den mallen till vår nya projektfil. Om vi vid något tillfälle ställer grundfärgen till svart så här?
vår sammanställda CSS kommer att ange punktfärgen till vit.
Om å andra sidan är basfärgvariabeln inställd på något annat?
styckfärgen kommer automatiskt att bli svart.
@for Loop
Förutom om uttalanden stöder Sass för loopar. Låt oss säga att vi ville skapa fyra kolumnklasser som gradvis ökar i bredd. I stället för att skriva ut varje klass manuellt kan vi rädda oss mycket arbete genom att bara skapa en enkel loop.
Detta uttalande kommer att sammanställas till följande CSS:
Lägg märke till hur det använde? $ I? motverka för att öka numret som bifogas klassnamnet varje gång och sedan öka bredden genom att multiplicera den aktuella? $ i? värdet med tio pixlar.
@ gång Loop
Många programmeringsspråk stöder olika stilar av loopar, så Sass följer kostym genom att inte bara inkludera en? För? struktur men en? stund? struktur också. Den här gången säger vi att vi vill bygga 1 Kb Grid klasserna med Sass. Så här skulle du göra det:
Detta uttalande upprepas tolv gånger och skapar .grid-klasser med namn som ökar med en varje gång och sätter dessa klasser i en bredd som ökar med 80px varje gång. Den här lilla småbiten av CSS kompilerar till den här stora delen av koden:
@varje
Den slutliga kontrollstrukturen är @each, som låter dig kortfattat lista ut en uppsättning variabler för att distribuera över en större bit av kod. Låt oss till exempel säga att du ville skapa några klasser som använder olika typsnittsfamiljer, så kan du göra något som följande:
Detta kommer att kompilera till CSS nedan.Resultatet är tre separata klasser som använder de tre teckensnittsnamnen som vi placerat i första raden ovan.
Återigen, för att läsa mer om kontrolldirektiv, bör du definitivt kolla in den officiella dokumentationen. Det finns ett särskilt trevligt @each exempel där som använder bildnamn istället för teckensnitt. Det är mer användbart och praktiskt än mitt exempel ovan men jag ville illustrera en annan möjlighet.
Innan du klagar?
Det uppenbara argumentet mot att använda dessa är att de direkt strider mot mina argument för att lätt läsa kod. Dessa räddar dig att skriva tid, men kräver lite ganska tung tolkning, tillräckligt för att du ska röra huvudet ibland. Tänk på att Sass-folket rekommenderar dem mest för användning i mixins, vilket i sin tur kan hjälpa till att göra din kod enklare på grund av deras återanvändbara natur.
Jag medger att det är troligt bäst att undvika kontrollstrukturer där det är möjligt, men jag kan inte låta bli upphetsad över det faktum att Sass inkluderar dessa, varning eller ingen varning. De talar verkligen med kraften i syntaxen och hur engagerade Sass-teamet är att göra det till ett extremt avancerat och unikt webbutvecklingsverktyg.
Slutsats
Detta är inte på något sätt en uttömmande diskussion om fördelarna med Sass över MINDRE, det är martly en titt på de två områden som jag funnit vara mest imponerande och intressant. Både @extend och kontrollstrukturer ger utvecklare några kraftfulla verktyg som du helt enkelt inte hittar någon annanstans. På liknande sätt har LESS några tricks på sin ärm, som Namnrymder, som du inte hittar i Sass.
I slutändan, oavsett om du använder Sass eller LESS, borde det inte vara så mycket. Det koka ner till en fråga om mening och om du gillar en bättre än den andra, borde du inte verkligen känna att det är något att argumentera för. Om jag tar Sass-rutten och tar den LESS-vägen, borde båda våra webbplatser fortfarande innehålla en ren CSS-fil i slutet (du bör alltid kompilera innan du laddar upp). Varför skulle jag bry mig om att rutten du tog för att komma dit var annorlunda än min? Så länge som din resulterande kod är giltig och välstrukturerad, är den lika bra som min.
Med detta sagt är jag angelägen att höra vilken syntax du föredrar. När det gäller mig är jag ganska bekväm med antingen. För att vara ärlig började jag fast i det lägsta lägret, men har nyligen varit riktigt dragna till en del av den kraft som Sass visar i funktioner som ovan.
Vad tror du? Med hjälp av verktyg som CodeKit gör båda syntaxerna så lättillgängliga, vilka är dina skäl att använda en över varandra?