Share
LibSass devine din ce în ce mai popular în fiecare zi. Nu trece o zi fără ca cineva să pretindă că și-a mutat mândria cu codul în LibSass. Oh, minunat.
Te simți un pic pierdut? Nu este sigur ce este LibSass, cum funcționează și ce diferențe principale sunt comparate cu Sass original? Nu-ți face griji, prietenul meu, te-am acoperit.
Înainte de a explica ce este LibSass, să recapitulăm mai întâi ce Sass este. Sass este un preprocesor CSS scris în Ruby. Pentru a utiliza Sass, trebuie să-l instalați ca a bijuterie (un pachet Ruby) pe mașina dvs. Apoi puteți interacționa cu Sass fie din CLI (Command Line Interface), fie cu o aplicație cum ar fi Prepros.
LibSass este un port al Sass scris în C / C ++. Vedeți, Ruby nu este cea mai rapidă limbă de pe pământ. Și se pare că este destul de lent când vine vorba de Sass.
"Ruby nu este una dintre cele mai performante limbi din lume, să spunem cel mai puțin" - Kamil Bielawski
Fiindcă nu eram un dezvoltator de Ruby, nu pot spune exact de ce; poate că scrierea de fișiere nu este la fel de eficientă cum ar putea fi, sincer nu știu. Dar din orice motiv, Ruby Sass este lent și devine și mai lent pe proiecte masive.
Acest lucru a atins punctul în care unii oameni s-au săturat de decalajul de performanță și au decis să înceapă scrierea lui Sass în C / C ++, pentru a grăbi timpii de compilare. Ceea ce au venit au fost LibSass.
Nu puteți folosi cu adevărat LibSass de la sine: aveți nevoie de un ambalaj. De exemplu, Node-Sass este un pachet NodeJS pentru LibSass. Vă permite să utilizați Node-Sass pentru a vă compila Sass de la Nod folosind LibSass dedesubt.
Node-Sass pe npmExistă, de asemenea, SassC, Perl-Libsass, PHP-Sass și chiar Ruby-LibSass, toate folosind LibSass dedesubt. Cu toate acestea, aceste ultime exemple nu sunt complet actualizate, astfel că folosim mai frecvent Node-Sass.
Pentru a rezuma, LibSass este portul C / C ++ al programului original Sass scris în Ruby. Se intenționează să fie înfășurat, ca Node-Sass să utilizeze Sass dintr-un mediu nod. Scopul principal: să fie rapid rapid în comparație cu originalul Sass.
Bine, deci știm ce este LibSass. Știm că LibSass este destinat să fie la fel de rapid ca un robot unicorn de curcubeu. Bun. Deci, de ce nu folosim cu toții LibSass chiar acum?
Principala problemă cu LibSass este că acesta se află în spatele implementării inițiale a Ruby atunci când vine vorba de caracteristici. La momentul scrierii, LibSass 3.1 este pe deplin compatibil cu Sass 3.3, cu toate acestea multe funcții de la Sass 3.4 sunt încă indisponibile. LibSass ratează, de exemplu, utilizarea selectorului de referință (&) în SassScript (abilitatea de a citi și de a le actualiza în zbor cu funcții și altele asemenea).
Din fericire, designerii de la Sass au decis să aștepte ca LibSass să se prindă înainte de a avansa la Sass 3.5, astfel încât ambele versiuni ar trebui să fie sincronizate în curând. Cu toate acestea, versiunea Ruby va fi întotdeauna versiunea principală: patch-urile și versiunile vor ateriza întotdeauna pe Ruby Sass, apoi vor fi implementate de LibSass.
Iată momentul în care trebuie să decideți ce motor Sass doriți să rulați: originalul Ruby Sass sau noul LibSass? Ca și în cazul tuturor lucrurilor din domeniul nostru, depinde.
În general, probabil aș recomanda LibSass deoarece este în general mai rapid decât Ruby Sass și viteza este totul în această lume. Cu toate acestea, dacă aveți nevoie de Sass pentru a face ceva nebun, care necesită noi funcții care urmează să fie adăugate la LibSass, Ruby ar fi cea mai bună alegere.
De cele mai multe ori, veți găsi că nu este cazul să alegeți un compilator Sass pentru un nou proiect, ci să îl regândiți pe cel pe care îl folosiți deja, astfel încât să se potrivească situației dvs. Dacă lucrați la proiecte de dimensiuni medii sau mari, este posibil să întâlniți o perioadă de compilare cu Ruby Sass între 2 secunde și 30 de secunde (da ...). Ar putea fi mai rău cu dependențe logice grele, cum ar fi Compass.
În acest moment, vă veți îmbolnăvi și veți obosi să pierdeți 25 de minute pe zi, așteptând ca Sass să compileze și veți lua în considerare serios scăderea unor caracteristici pentru a obține viteză. În acest caz, LibSass arată ca un cupcake gigant în formă de pisoi, în timp ce Ruby Sass este mai mult ca un biscuit vechi și uscat ...
Pentru a vă ajuta să decideți dacă puteți sau nu să transferați întreaga bază de coduri LibSass, am creat proiectul Sass-Compatibility. Sass-Compatibility intenționează să enumere toate incoerențele majore dintre diferitele motoare Sass (practic Ruby Sass 3.2, Sass 3.3, Ruby Sass 3.4 și ultima versiune LibSass). Recent am prezentat proiectul la SitePoint, dacă vreți să vă prindeți.
Proiectul Sass-CompatibilityNotă: Sass-Compatibility foloseste SassMeister pentru a-si executa testele. SassMeister utilizează Node-Sass pentru a executa LibSass. Cu toate acestea, Node-Sass nu este compatibil cu LibSass 3.1 încă (deși ar trebui să fie în curând), ceea ce înseamnă că rezultatele Sass-Compatibility pentru LibSass ar arăta mai rău decât situația este de fapt.
Suntem, oameni buni. Sper că acest articol v-a ajutat să înțelegeți ce și de ce este LibSass.
Suntem în prezent într-o situație ciudată în care LibSass este extrem de convenabil datorită vitezei sale, dar nu oferă tot ceea ce Ruby Sass face astfel încât să nu poată fi adoptat încă necondiționat. Toate acestea se vor rezolva în curând când ambele versiuni vor deveni pe deplin compatibile.
Acum, deoarece LibSass este mult mai rapid decât Ruby Sass (și cred că indiferent cât de tare încearcă dezvoltatorii de bază din Ruby Sass, acesta va fi întotdeauna așa), nu știu ce fel de viitor ar putea fi implementarea Ruby. Într-un anumit moment, nu cred că va avea sens să folosești Ruby Sass dacă este mai lent, dacă nu aduce ceva în plus la masă. Așa cum spunem: așteptați și vedeți.
Accentsconagua