Share
LibSass devient de plus en plus populaire chaque jour. Il ne se passe pas un jour sans que quelqu'un prétende avoir déplacé fièrement sa base de code vers LibSass. Oh génial.
Vous sentez-vous un peu perdu? Vous ne savez pas vraiment ce qu'est LibSass, comment cela fonctionne et quelles sont les principales différences par rapport au Sass original? Eh bien, ne vous inquiétez pas mon ami, je vous ai couvert.
Avant d’expliquer ce que LibSass est, récapitulons d’abord sur quoi Toupet est. Sass est un préprocesseur CSS écrit en Ruby. Pour utiliser Sass, vous devez l’installer en tant que gemme (un paquet Ruby) sur votre machine. Ensuite, vous pouvez interagir avec Sass à partir de la CLI (interface de ligne de commande) ou avec une application telle que Prepros..
LibSass est un portage de Sass écrit en C / C ++. Vous voyez, Ruby n'est pas la langue la plus rapide sur terre. Et il s'avère être assez lent quand il s'agit de Sass.
"Le ruby n'est pas l'une des langues les plus performantes au monde, c'est le moins qu'on puisse dire." - Kamil Bielawski
N'étant pas moi-même un développeur Ruby, je ne peux pas dire exactement pourquoi; Peut-être que l'écriture de fichier n'est pas aussi efficace qu'elle pourrait l'être, honnêtement, je ne sais pas. Mais pour une raison quelconque, Ruby Sass est lente et elle ralentit encore plus sur des projets de grande envergure.
Cela a atteint le point où certaines personnes se sont lassées du retard de performance et ont décidé de commencer à écrire Sass en C / C ++, afin d’accélérer les temps de compilation. Qu'est-ce qu'ils sont venus avec était LibSass.
Vous ne pouvez pas vraiment utiliser LibSass par lui-même: vous avez besoin d'un wrapper. Par exemple, Node-Sass est un wrapper NodeJS pour LibSass. Il vous permet d’utiliser Node-Sass pour compiler votre Sass à partir de Node en utilisant LibSass sous.
Node-Sass sur npmIl y a aussi SassC, Perl-Libsass, PHP-Sass et même Ruby-LibSass, qui utilisent tous LibSass dessous. Cependant, ces derniers exemples ne sont pas totalement à jour et nous utilisons donc plus couramment Node-Sass.
Pour résumer, LibSass est le port C / C ++ du programme Sass original écrit en Ruby. Il est censé être encapsulé, comme le fait Node-Sass pour utiliser Sass à partir d’un environnement de nœud. Objectif principal: être incroyablement rapide par rapport au Sass original.
Bon, on sait ce que c'est LibSass. Nous savons que LibSass est conçu pour être aussi rapide qu'une licorne arc-en-robot. Bien. Alors, pourquoi n'utilisons-nous pas tous LibSass maintenant??
Le principal problème de LibSass est qu’il est à la traîne par rapport à l’implémentation originale de Ruby en ce qui concerne les fonctionnalités. Au moment de la rédaction de ce document, LibSass 3.1 est entièrement compatible avec Sass 3.3, mais de nombreuses fonctionnalités de Sass 3.4 ne sont toujours pas disponibles. LibSass manque, par exemple, l’utilisation du sélecteur de référence (Et) en SassScript (la possibilité de le lire et de le mettre à jour à la volée avec des fonctions et autres).
Heureusement, les concepteurs principaux de Sass ont décidé d'attendre que LibSass rattrape leur retard avant de passer à Sass 3.5, de sorte que les deux versions devraient bientôt être synchronisées. Cependant, la version Ruby sera toujours la version principale: les correctifs et les versions arriveront toujours sur Ruby Sass en premier, puis seront implémentés par LibSass..
Voici le moment où vous devez choisir le moteur Sass que vous souhaitez utiliser: le Ruby Sass original ou le tout nouveau LibSass? Comme pour tout dans notre domaine, cela dépend.
Dans l’ensemble, je recommanderais probablement LibSass car il est généralement plus rapide que Ruby Sass et que la vitesse est primordiale dans ce monde. Cependant, si vous avez besoin que Sass fasse quelque chose de fou qui nécessite de nouvelles fonctionnalités qui doivent encore être ajoutées à LibSass, Ruby serait le meilleur choix..
Le plus souvent, vous constaterez qu'il ne s'agit pas de choisir un compilateur Sass pour un nouveau projet, mais de repenser celui que vous utilisez déjà pour l'adapter à votre situation. Si vous travaillez sur des projets de moyenne à grande envergure, vous pouvez rencontrer un temps de compilation compris entre 2 et 30 secondes (oui…) avec Ruby Sass. Cela pourrait être pire avec des dépendances très logiques telles que Compass.
À ce stade, vous en aurez assez de perdre 25 minutes par jour à attendre la compilation de Sass et vous envisagerez sérieusement de supprimer certaines fonctionnalités pour gagner de la vitesse. Dans ce cas, LibSass ressemble à un petit gâteau géant en forme de chaton, tandis que Ruby Sass ressemble davantage à un vieux biscuit sec…
Pour vous aider à décider si vous pouvez ou non porter toute votre base de code sur LibSass, j'ai configuré le projet Sass-Compatibility. Sass-Compatibility a l'intention de répertorier toutes les incohérences majeures entre les différents moteurs Sass (essentiellement Ruby Sass 3.2, Sass 3.3, Ruby Sass 3.4 et la dernière LibSass). J'ai récemment présenté le projet sur SitePoint, si vous voulez rattraper son retard.
Le projet Sass-CompatibilityRemarque: Sass-Compatibility utilise SassMeister pour exécuter ses tests. SassMeister utilise Node-Sass pour exécuter LibSass. Cependant, Node-Sass n'est pas encore compatible avec LibSass 3.1 (bien que cela devrait l'être dans peu de temps), ce qui signifie que les résultats de Sass-Compatibility pour LibSass sont pires que la situation actuelle..
Nous y voilà. J'espère que cet article vous a aidé à comprendre le quoi et le pourquoi de LibSass.
Nous sommes actuellement dans une situation étrange où LibSass est extrêmement pratique en raison de sa rapidité, mais ne fournit pas tout ce que fait Ruby Sass et ne peut donc pas encore être adopté sans condition. Tout cela sera bientôt réglé lorsque les deux versions deviendront pleinement compatibles..
Maintenant, puisque LibSass est beaucoup plus rapide que Ruby Sass (et je pense que peu importe les efforts des développeurs principaux de Ruby Sass, ce sera toujours comme ça), je ne sais pas quel genre d’avenir il peut y avoir pour la mise en oeuvre de Ruby. À un moment donné, je ne pense pas qu'il soit logique d'utiliser Ruby Sass s'il est plus lent, à moins que cela apporte quelque chose de plus à la table. Comme on dit: attendre et voir.
Accentsconagua