Idag ska vi kasta två CSS-förprocessorer från början till huvudet. Du har utan tvekan sett mycket diskussion om hur SCSS jämförs till MINST, men var är Stylus, den nya grabben i kvarteret, faktor i? Kan det eventuellt matcha SASSs makt och mångsidighet?
Vi hoppar huvudet först i båda syntaxerna och jämför dem sida vid sida för att se vilka som är mer logiska och mångsidiga. Vi pratar också om funktioner och ger dig ett tydligt argument för varför en förprocessor är kraftfullare. Du kan vara säker, vi kommer inte att wuss ut och ge dig lite skit om ett slips, det kommer bli en vinnare!
Sass, inte SCSS
En liten detalj måste åtgärdas innan vi dyker in på detta längre. Syntaxen vi använder idag är Sass, inte SCSS. Den senare av dessa är den nyaste formen, så det är sannolikt det du är mest bekant med.
Men för jämförelsens skull är Sass faktiskt mycket närmare Stylus än sitt syskon SCSS. Medan SCSS var ett försök att regera Sass tillbaka och göra syntaxen närmare spegeln CSS, följer Stylus sätten för det ursprungliga Sass-språket i dess övergivande av de flesta strukturella syntaxerna, såsom semikolon och lockiga axlar.
Tyvärr är detta inte en artikel om fördelarna med Sass vs SCSS men så kommer jag att avstå från att växa på om detta ämne. Om du letar efter en bra diskussion om detta ämne, kolla? Sass vs SCSS: Vilken syntax är bättre ?? från The Sass Way. Generellt, kom ihåg att Sass och SCSS är i stort sett samma funktion, den enda skillnaden är hur du skriver dem.
Grundläggande syntax
Låt oss börja med en direkt jämförelse av båda syntaxerna på deras mest grundläggande nivå. Vi skriver samma förklaring båda språk och ser var skillnaderna ligger.
Som ni kan se är de nästan identiska. Varken syntaxen kräver krökiga parenteser eller semikolon, vilket givetvis innebär att de båda är ganska beroende av blankutrymme för korrekt sammanställning. Den stora skillnaden som vi ser på denna punkt är med kolon: Sass kräver dem, Stylus gör det inte.
Flexibilitet
En sak som jag alltid uppskattat om LESS och SCSS är att jag fortfarande kan skriva vanlig gammal vanilj CSS i mitt stylesheet. Dessa syntaxer är så nära CSS att du kan välja och välja viktiga punkter för att genomföra sina specialfunktioner, men du behöver inte omskola din hjärna för att skriva CSS.
Såvitt jag kan säga har Sass inte denna förmåga, men Stylus verkar tydligen (demonstreras här). Jag använder emellertid CodeKit för att kompilera min Stylus, vilket inte låter mig blanda ren CSS med Sass eller Stylus. Om jag slänger en enkel linje med ren CSS, kommer koden inte att kompileras (båda talen har felrapportering).
Det sägs att det finns lite flexibilitet med Stylus och Codekit som du inte hittar i Sass. Till exempel kräver Stylus inte användning av kolon eller semikolon, men det tillåter att båda används. Det gillar helt enkelt inte lockiga fästen. Sass å andra sidan krävs kolon och kommer inte att kompilera om du använder semikolon.
Basic Syntax Winner: Stylus
Om du ska använda en avkortad preprocessorsyntax är Stylus bättre för de två enligt min mening. Det enkla svaret är att Stylus låter dig välja din nivå av verbosity medan Sass tvingar dig till en bestämd metod.
Med all ärlighet kan jag helt enkelt anse det som förloraren, den enda anledningen till att jag förklarar Stylus vinnaren här. Flexibel syntax är ett smutsigt ord med många kodare eftersom det kan leda till slarvig, inkonsekvent kodning. Om du ska använda Stylus ska du välja en metod för deklaration och hålla fast vid den. Skriv inte två koder som bara använder semikolon, sedan växla till kasta i kolonner, sedan växla igen till att använda varken.
Nesting
Med Nesting kan du spara lite repetitiv kodning genom att nesta selektörer inom varandra. Så när a? P? väljaren är indelad i en? div? väljaren kommer kompileringsresultatet att vara både div? och? div p ?. Denna funktion är nästan identisk i Stylus och Sass.
Sass tar faktiskt begreppet att bo i ett steg längre och låter dig rädda dig själv för att skriva upp repetitiva fastighetsnamn. Tänk exempel på exemplet nedan. I Stylus måste du upprepa? Fonten? del, men Sass tillåter häckning som en alternativ metod.
Vinnare: Sass
Det enkla faktum här är att Sass har en cool funktion som Stylus inte gör. Jag har aldrig använt det, och jag är inte säker på att jag ska börja nu, men jag kan se hur det skulle vara användbart, särskilt i fall som textjustering, textskuggning, textdekoration etc. där inget stenografi alternativ finns .
variabler
En av de största dragningarna till förprocessorer är införandet av variabler. Många äldre utvecklare tror att de variablerna inte har någon verksamhet någonstans nära CSS, men otaliga andra tycker att variabler är en av de coolaste möjligheterna att någonsin slå CSS. Jag tycker personligen att CSS-variabler är oerhört användbara.
Både Stylus och Sass inkluderar variabelt stöd. Här är vad som ser ut som att använda en variabel för att deklarera typstorleken på en paragraf.
Återigen ser vi att Stylus-syntaxen var lite mer kortfattad. Lägg märke till hur Sass kräver användning av ett extra tecken (dollarns tecken) för att referera till variabler. Stylus tar också vägen för att använda en likhetssymbol istället för ett kolon, vilket ska vara känt för JavaScript-utvecklare.
Båda språken tillåter också variabla operationer, så att du kan lägga till, subtrahera, multiplicera och dela upp variabler i ditt hjärta innehåll.
Vinnare: Rita (jag föredrar Sass-syntaxen)
Låt oss få det här rakt, om vi gör allt rent på verbositet, kommer Stylus fortsätta vinna. Det är den kortaste syntaxen, perioden. Men antagandet att briefer är bättre är inte alltid en riktig.
Intressant nog, på en personlig nivå tror jag att jag föredrar Sass-vägen här. Kolon syntax bara känner mer som CSS. Dessutom är människor så vana att se variabler i deras CSS att dollarns tecken verkligen hjälper dem att sticka ut. Jag kan enkelt skanna igenom hundratals linjer av Sass och upptäcka variablerna, en uppgift som är betydligt svårare med Stylus.
Fastighetssökning
Medan vi är på ämnet variabler, är det värt att nämna att Stylus har en unik? Property Lookup? funktion som gör att du faktiskt kan spara dig några av de variabler som du normalt skulle behöva anställa med Sass. Låt oss säga att du ville ställa in vaddering på ett element till hälften av marginalen. Med Sass måste du använda variabler för att uppnå detta (så långt jag kan säga), men med Stylus kan du använda? @? syntax för att referera till värdet på en annan egenskap inom samma deklarationsblock.
Vinnare: Stylus
Sass har inte ens en motsvarighet till egenskapsuppslagfunktionen så det här är ingen tävling. Jag personligen gillar verkligen att ha denna förmåga och hoppas att Sass-folket överväger att lägga till det.
Mixins & Funktioner
Därefter tar vi en titt på mixins. Dessa är typ av som variabler för stora bitar av kod istället för en enda egenskap eller värde. Mixins är kanske ett av de kraftfullaste verktygen som CSS preprocessorer har för att spara tid och energi. Att veta hur man hävdar mixins på rätt sätt kommer att göra ditt jobb så mycket lättare!
Här är ett exempel på Stylus och Sass-syntaxen på en typisk gränsvärdesdefinition. Fördelen här är att du bara måste skriva ut alla dessa webbläsarprefixer en gång, så låta preprocessorn arbeta sin magi någon annanstans du implementerar dem.
Återigen ser vi att Sass kräver en massa extra symboler och syntax medan Stylus håller sakerna ganska rena. Observera också att Stylus har möjlighet att använda något som kallas? Transparent mixins? där du inte ens behöver använda parentes när du ringer mixin. Det verkar som om jag bara använder standardgränsradiusegenskapen när jag faktiskt använder min mixin.
Funktioner är en liknande konstruktion, bara de är vanligtvis avsedda att utföra en operation och returnera ett värde. Här är funktionssyntaxen för varje språk:
Vinnare: Stylus
Efter att ha skrivit ut mixin och fungerar med Stylus och sedan återgår till Sass, tycktes den senare bara som så mycket mer arbete. Stylus-sättet är väldigt enkelt, medan Sass har ständigt skrivit ut? @ Mix ?,? @ Include ?,? @ Function? och? @return ?, vilket känns överflödigt.
Argumentets kött: Vilket är bättre?
Jag är inte den första som gör en jämn jämförelse med exempel som ovan, men jag gjorde med vilseledande ett steg längre än andra genom att tydligt förklara min preferens i varje enskilt fall.
I all ärlighet är både Sass och Stylus alltför stora för mig att fortsätta på denna syntaxjämförelse. Det finns många fler fall där du kan upptäcka att Stylus och Sass är nästan identiska i sina metoder. Här är några funktioner som båda delar:
- Interpolation
- Välja arv genom @extend
- Om och annat stil villkor (kontrolldirektiv)
- Inbyggda färgfunktioner
- Iteration
- Importdirektiv
Du borde ha en känsla för hur varje språk fungerar nu, så låt oss flytta på en ren diskussion om var de skiljer sig och varför det är viktigt. En sak att tänka på omedelbart är att Stylus är speciellt byggd för att samarbeta med Node.js, så om du är en Node-fan kan det vara vägen att gå.
För det mesta verkar det som att Stylus är det flexiblare och ännu kraftfullaste alternativet. Det finns några fall där Sass drar ett knep som Stylus inte kan, men jag har inte stött på en? Stylus Killers? funktion som skulle få mig att tydligt säga att Sass är bäst.
Omvänt verkar det finnas massor av små saker som du hittar när du gräver i Stylus som du saknar när du växlar tillbaka till Sass. Jag har nämnt några redan som egenskapen Lookup-funktionen, en annan intressant är? Argumenten? automatisk lokal variabel för mixins, vilket gör att du kan hoppa över steget att skapa din egen variabel för att duplicera alla argument från en mixin. Det finns också resten parametrar som förbrukar de återstående argumenten som skickas till en mixin eller funktion (den här funktionen kan vara i Sass, men jag har inte hittat det):
Slutligen tar Stylus också mycket av smärtan av mediafrågor, vilket är lite skrymmande och besvärligt med alla dessa konsoler. Här är en Stylus-utskriftsmediafråga:
Vad om SCSS?
Min faktiska föredragna varje dag preprocessor är Sass med SCSS-syntaxen. Innan jag skrev den här artikeln hade jag inte experimenterat mycket med någon av de avkortade syntaxerna eftersom jag tyckte att det var lite skrämmande att kasta bort alla de regler som jag hade så inbrott i min hjärna.
Dessutom gillar jag idén om att bara plugga in i mitt nuvarande CSS-arbetsflöde istället för att försöka helt ändra det från grunden. Med detta sagt har jag snabbt anpassat mig till Stylus sätt att göra saker och bryr mig inte så mycket som jag trodde att jag skulle. Det är ganska trevligt att dike dessa kolon!
Låt oss säga att du bara inte kan vänja dig eller tror att det är en dålig övning att använda en avkortad syntax eftersom det får dig att glömma hur man skriver korrekt CSS, i det här fallet är SCSS vägen att gå rätt? Kanske inte.Så länge du använder kommandoraden eller en bättre kompilator än CodeKit, kan du låta Stylus anta? CSS-stilen? av syntax, vilket betyder att du kan dra nytta av alla godisarna som finns i Stylus utan att acceptera den skrämmande minimalmetoden för CSS-författande.
Vad om kompass?
En helt grundläggande del av detta pussel är Compass, som tar Sass till nya höjder av awesomeness. Självklart, om du är beroende av det här verktyget kommer det att bli mycket svårare att byta till Stylus. Det finns dock ett nära relaterat projekt som heter Nib som försöker få en liknande CSS3-godhet till Stylus.
Slutsats
Det smärjer mig att säga det men Stylus verkar verkligen ha överhanden i många hälsningar. Det har fördelen att lära av och förbättra vad som gjordes med Sass, och kommer bättre ut för det. Med det sagt kommer jag förmodligen inte att ge upp SCSS någon gång snart. Jag tror på Sass-projektet och är övertygad om att dess vida adoption kommer att fortsätta medföra en hel del förbättringar. Jag är inte säker på att jag har samma tro på Stylus.
Lämna en kommentar nedan och låt oss veta vad du tycker. Vilken förprocessor tycker du är bättre och varför? Oavsett vilken har mer trick upp sin ärm, vilken kommer du att använda på lång sikt?