Share
LibSass wordt elke dag meer en meer populair. Er gaat geen dag voorbij zonder dat iemand beweert dat hij trots zijn codebasis naar LibSass heeft verhuisd. Oh geweldig.
Voel je je een beetje verloren? Niet helemaal zeker wat LibSass is, hoe het werkt en wat de belangrijkste verschillen zijn met het originele Sass? Maak je geen zorgen, mijn vriend, ik heb je gedekt.
Voordat we uitleggen wat LibSass is, laten we eerst een samenvatting geven van wat Sass is. Sass is een CSS-preprocessor geschreven in Ruby. Om Sass te gebruiken, moet je het installeren als een edelsteen (een Ruby-pakket) op uw computer. Vervolgens kunt u communiceren met Sass vanuit de CLI (opdrachtregelinterface) of met een toepassing zoals Prepros.
LibSass is een poort van Sass geschreven in C / C ++. Zie je, Ruby is niet de snelste taal op aarde. En het blijkt nogal traag te zijn als het op Sass aankomt.
"Ruby is op zijn minst een van de meest performante talen ter wereld." - Kamil Bielawski
Omdat ik zelf geen Ruby-ontwikkelaar ben, kan ik niet precies zeggen waarom; misschien is het schrijven van bestanden niet zo efficiënt als het zou kunnen zijn, ik weet het eerlijk gezegd niet. Maar om welke reden dan ook, Ruby Sass is traag en het wordt zelfs langzamer bij enorme projecten.
Dit bereikte het punt waarop sommige mensen de prestatieliag beu werden en besloten om Sass te gaan schrijven in C / C ++, om compilatietijden te versnellen. Wat ze bedachten was LibSass.
Je kunt LibSass niet echt alleen gebruiken: je hebt een wrapper nodig. Node-Sass is bijvoorbeeld een NodeJS-wrapper voor LibSass. Hiermee kun je Node-Sass gebruiken om je Sass van Node te compileren met LibSass eronder.
Node-Sass op npmEr zijn ook SassC, Perl-Libsass, PHP-Sass en zelfs Ruby-LibSass, allemaal met LibSass eronder. Deze laatste voorbeelden zijn echter niet helemaal up-to-date, dus gebruiken we vaker Node-Sass.
Samenvattend is LibSass de C / C ++ -poort van het originele Sass-programma geschreven in Ruby. Het is bedoeld om te worden ingepakt, zoals Node-Sass doet om Sass te gebruiken vanuit een knooppuntomgeving. Belangrijkste doel: ontzettend snel zijn in vergelijking met de originele Sass.
Oké, dus we weten wat LibSass is. We weten dat LibSass bedoeld is om net zo snel te zijn als een regenboogrobot van een robot. Goed. Dus waarom gebruiken we LibSass nu niet allemaal??
Het grootste probleem met LibSass is dat het achterloopt op de oorspronkelijke Ruby-implementatie als het gaat om functies. Op het moment van schrijven is LibSass 3.1 volledig compatibel met Sass 3.3, maar veel functies van Sass 3.4 zijn nog steeds niet beschikbaar. LibSass mist bijvoorbeeld het gebruik van de referentieselector (&) in SassScript (de mogelijkheid om het on the fly te lezen en bij te werken met functies en dergelijke).
Gelukkig hebben de kernontwerpers van Sass besloten te wachten totdat LibSass de achterstand inhaalt voordat ze doorgaat naar Sass 3.5, zodat beide versies binnenkort moeten worden gesynchroniseerd. De Ruby-versie zal echter altijd de hoofdversie zijn: patches en releases zullen altijd eerst op Ruby Sass terechtkomen en vervolgens worden geïmplementeerd door LibSass.
Hier komt het moment waarop je moet beslissen welke Sass-engine je wilt gebruiken: de originele Ruby Sass of de gloednieuwe LibSass? Zoals met alles in ons vakgebied, hangt het ervan af.
Al met al zou ik waarschijnlijk LibSass aanbevelen omdat het over het algemeen sneller is dan Ruby Sass en snelheid alles in deze wereld is. Als je echter Sass nodig hebt om iets geks te doen dat nieuwe functies vereist die nog moeten worden toegevoegd aan LibSass, zou Ruby de betere keuze zijn.
Vaker wel dan niet, je zult merken dat het niet een kwestie is van het kiezen van een Sass-compiler voor een nieuw project, maar om de Sass-compilatie die je al gebruikt te heroverwegen, zodat het past bij jouw situatie. Als u werkt aan middelgrote tot grote projecten, kunt u een compilatietijd van 2 seconden tot 30 seconden (ja ...) ervaren met Ruby Sass. Het kan slechter met logica-zware afhankelijkheden zoals Compass.
Op dit punt zul je het beu worden om 25 minuten per dag te wachten op Sass om te compileren en je zult serieus overwegen sommige functies te laten vallen om snelheid te winnen. In dit geval lijkt LibSass op een gigantische, katachtige cupcake, terwijl Ruby Sass meer op een oud en droog koekje lijkt ...
Om u te helpen beslissen of u uw volledige codebasis naar LibSass kunt overbrengen, heb ik het Sass-compatibiliteitsproject opgezet. Sass-compatibiliteit is bedoeld om een lijst te maken met alle belangrijke inconsistenties tussen de verschillende Sass-engines (in feite Ruby Sass 3.2, Sass 3.3, Ruby Sass 3.4 en de nieuwste LibSass). Ik heb het project onlangs geïntroduceerd op SitePoint, als je het wilt inhalen.
Het Sass-compatibiliteitsprojectNotitie: Sass-Compatibility gebruikt SassMeister om zijn tests uit te voeren. SassMeister gebruikt Node-Sass om LibSass uit te voeren. Node-Sass is echter nog niet compatibel met LibSass 3.1 (hoewel het binnenkort zou moeten zijn), wat betekent dat de resultaten van Sass-compatibiliteit voor LibSass slechter lijken dan de situatie eigenlijk is.
Daar zijn we, mensen. Ik hoop dat dit artikel je heeft geholpen om het wat en waarom van LibSass te begrijpen.
We bevinden ons momenteel in een vreemde situatie waarin LibSass buitengewoon handig is dankzij zijn snelheid, maar niet alles biedt wat Ruby Sass doet, dus het kan nog niet onvoorwaardelijk worden overgenomen. Dit zal snel oplossen als beide versies volledig compatibel worden.
Nu, omdat LibSass veel sneller is dan Ruby Sass (en ik denk dat het niet uitmaakt hoe hard Ruby Sass-kernontwikkelaars het proberen, het zal altijd zo blijven), ik weet niet wat voor toekomst er kan zijn voor de Ruby-implementatie. Op een bepaald moment denk ik niet dat het veel zin heeft om Ruby Sass te gebruiken als het langzamer is, tenzij het iets extra's op tafel brengt. Zoals we zeggen: afwachten.
Accentsconagua