Bli kjent med LibSass

LibSass blir stadig mer populært hver dag. Ikke en dag går uten at noen hevder at de stolt har flyttet sin kodebase til LibSass. Oh, flott.

Føler du deg litt tapt? Ikke helt sikker på hva LibSass er, hvordan det fungerer og hva er de største forskjellene sammenlignet med den opprinnelige Sass? Vel bekymre deg ikke min venn, jeg har deg dekket.

Hva er LibSass?

Før du forklarer hva LibSass er, la oss først lese om hva sass er. Sass er en CSS preprosessor skrevet i Ruby. For å bruke Sass må du installere det som en perle (en Ruby-pakke) på maskinen din. Deretter kan du samhandle med Sass enten fra CLI (Command Line Interface) eller med et program som Prepros.

Opptreden

LibSass er en port av Sass skrevet i C / C ++. Du ser, Ruby er ikke det raskeste språket på jorden. Og det viser seg å være ganske treg når det gjelder Sass. 

"Ruby er ikke et av de mest fremtredende språkene i verden, minst sagt." - Kamil Bielawski

Ikke å være en Ruby-utvikler selv, jeg kan ikke nøyaktig fortelle hvorfor; kanskje filskriving er ikke så effektiv som det kan være, jeg ærlig vet ikke. Men uansett grunn er Ruby Sass sakte og det blir enda tregere på massive prosjekter.

Dette nådd det punktet hvor noen ble sliten av prestasjonsforsinkelsen og bestemte seg for å begynne å skrive Sass i C / C ++, for å øke samlingstidene. Hva de opplevde var LibSass.

wrapper

Du kan egentlig ikke bruke LibSass av seg selv: du trenger en wrapper. For eksempel er Node-Sass en NodeJS wrapper for LibSass. Den lar deg bruke Node-Sass til å kompilere Sass fra Node ved hjelp av LibSass under. 

Node-Sass på npm

Det er også SassC, Perl-Libsass, PHP-Sass og til og med Ruby-LibSass, alle med LibSass under. Men disse sistnevnte eksemplene er ikke helt oppdaterte, derfor bruker vi mer generelt Node-Sass.

For å oppsummere er LibSass C / C ++-porten i det originale Sass-programmet skrevet i Ruby. Det er ment å bli innpakket, som Node-Sass gjør for å bruke Sass fra et Node-miljø. Hovedmål: å være blazingly rask i forhold til den opprinnelige Sass.

Forskjellen med Ruby Sass

Ok, så vi vet hva LibSass er. Vi vet at LibSass er ment å være like fort som en robotbåne enhjørning. Flink. Så hvorfor bruker vi ikke alle LibSass akkurat nå?

Hovedproblemet med LibSass er at det ligger bak den opprinnelige Ruby-implementeringen når det gjelder funksjoner. På tidspunktet for skrivingen er LibSass 3.1 fullt kompatibel med Sass 3.3, men mange funksjoner fra Sass 3.4 er fortsatt utilgjengelige. LibSass savner for eksempel bruk av referansevalgeren (&) i SassScript (evnen til å lese og oppdatere den på farten med funksjoner og slikt).

Heldigvis har Sass kjerne designere besluttet å vente på LibSass å fange opp før de går videre til Sass 3.5, slik at begge versjoner snart skal synkroniseres. Ruby-versjonen vil imidlertid alltid være hovedversjonen: patcher og utgivelser vil alltid lande på Ruby Sass først, så bli implementert av LibSass.

Som å velge?

Her kommer det øyeblikk hvor du må bestemme hvilken Sass-motor du vil kjøre: den originale Ruby Sass eller den helt nye LibSass? Som med alt i vårt felt, avhenger det.

Alt i alt vil jeg nok anbefale LibSass fordi det er generelt raskere enn Ruby Sass og hastigheten er alt i denne verden. Men hvis du trenger Sass å gjøre noe gal som krever nye funksjoner som ennå ikke skal legges til LibSass, ville Ruby være det bedre valget.

Oftere enn ikke, finner du at det ikke er tilfelle å velge en Sass-kompilator for et nytt prosjekt, men å revurdere den du allerede bruker, slik at den passer til din situasjon. Hvis du jobber på mellomstore prosjekter, kan du oppleve en kompileringstid på mellom 2 sekunder og 30 sekunder (ja ...) med Ruby Sass. Det kan bli verre med logikk-tunge avhengigheter som Compass.

På dette tidspunktet blir du syk og lei av å miste 25 minutter om dagen og venter på at Sass skal kompilere, og du vil seriøst vurdere å slippe noen funksjoner for å få fart. I dette tilfellet ser LibSass ut som en gigantisk kattungeformet cupcake mens Ruby Sass er mer som en gammel og tørr kjeks ...

Gjør bryteren

For å hjelpe deg med å avgjøre hvorvidt du kan sende hele koden din til LibSass, setter jeg opp Sass-Compatibility-prosjektet. Sass-kompatibilitet har til hensikt å liste alle store inkonsekvenser mellom de forskjellige Sass-motorene (i hovedsak Ruby Sass 3.2, Sass 3.3, Ruby Sass 3.4 og nyeste LibSass). Jeg har nylig introdusert prosjektet på SitePoint, hvis du vil ta opp.

Sass-Kompatibilitetsprosjektet

Merk: Sass-kompatibilitet bruker SassMeister til å kjøre sine tester. SassMeister bruker Node-Sass til å kjøre LibSass. Node-Sass er imidlertid ikke kompatibel med LibSass 3.1 ennå (selv om det burde være snart), noe som betyr at Sass-kompatibilitetsresultater for LibSass ser verre ut enn situasjonen faktisk er.

Siste tanker

Der er vi, folk. Jeg håper denne artikkelen hjalp deg med å forstå hva og hvorfor av LibSass.

Vi er for tiden i en merkelig situasjon der LibSass er ekstremt praktisk takket være sin hastighet, men gir ikke alt Ruby Sass gjør det, kan ikke bli betingelsesløst vedtatt ennå. Dette kommer snart til å slå seg ned når begge versjonene blir fullt kompatible.

Nå, siden LibSass er mye raskere enn Ruby Sass (og jeg tror uansett hvor hardt Ruby Sass kjerneutviklere prøver, vil det alltid være slik), jeg vet ikke hva slags fremtid det kan være for Ruby-implementeringen. På et visst punkt tror jeg ikke det vil gi stor mening å bruke Ruby Sass hvis det er tregere, med mindre det bringer noe ekstra til bordet. Som vi sier: vent og se.