Less et Sass visent à accomplir la même chose et sont si semblables qu'il est facile de confondre les deux, mais sont-ils vraiment créés égaux? Y a-t-il quelque chose que l'on peut faire que l'autre ne peut pas?
D'une syntaxe à l'autre, chaque syntaxe comporte une ou deux choses que l'autre n'a pas. Cependant, malgré le fait que j’ai initialement été attiré par la simplicité de LESS, à long terme, je ne pouvais pas m’empêcher d’être aspiré par quelques fonctionnalités clés qui rendent Sass vraiment puissant. Suivez-moi au fur et à mesure que je souffle dans votre esprit avec certaines des caractéristiques étonnantes et uniques de Sass.
MOINS vs Sass
Sass et LESS sont tous deux présents depuis un bon bout de temps maintenant, mais il semble qu'ils aient vraiment bien progressé en 2011 et qu'ils aient gagné beaucoup de popularité. Les deux fournissent d'excellents moyens d'étendre le CSS pour qu'il soit plus convivial pour le programmeur, ce qui conduit à un code plus logique et concis qui utilise beaucoup moins de répétition.
Qui est plus amical?
Récemment ici, sur Design Shack, j'ai accordé beaucoup d'attention à LESS. Certes, je trouve que c’est la plus abordable des deux options. Certains vont argumenter contre cette idée jusqu'à ce qu'ils deviennent bleus, mais il n'en reste pas moins que LESS a une configuration vraiment sympa: utilisez un simple fichier .js pour tester et compilez le code automatiquement avec une application conviviale: Less. app.
Même si vous pensez que tous les développeurs CSS doivent connaître Ruby et être un as de Terminal, la réalité est que beaucoup ne correspondent pas à cette description et préfèrent passer la journée à apprendre une chose (MOINS) au lieu de deux (Sass + comment fonctionnent les gemmes de rubis).
Certes, Sass nécessite seulement une infime utilisation de terminal que tout le monde peut gérer, mais vous seriez surpris du nombre de personnes renvoyées pour cette raison.
Pas si vite
Récemment cependant, ce paysage a considérablement changé. Des solutions telles que CodeKit font leur apparition pour rendre l’écriture Sass et la sortie CSS tout aussi simples que l’utilisation de Sass.
En fait, CodeKit compile automatiquement les fichiers LESS, Sass, Stylus et CoffeeScript. Tout ce que vous avez à faire est de déposer votre dossier de projet et votre travail est terminé. Voilà pour MOINS d'être plus amical!
Qui est plus puissant?
Pour de nombreux développeurs, l'argument sur ce qui est le plus facile à mettre en œuvre est assez mesquin, étant donné que LESS et Sass sont assez simples à utiliser. Le vrai argument revient alors au pouvoir: quelle langue peut faire plus?
La réponse n'est pas si simple. Il s’avère que LESS et Sass ont des caractéristiques uniques qui ne sont pas partagées par l’autre. Cependant, il faut dire que dans ce domaine, Sass réussit vraiment à faire des coups impressionnants. Jetons un coup d'oeil à deux de mes favoris: @extend et structures de contrôle.
Sass @extend
Chaque fois que je parle de LESS, les membres du camp Sass commencent à s’émerveiller de la commande @extend de Sass. En fin de compte, il y a une bonne raison à cela: c'est en fait assez utile.
La magie derrière @extend est qu'elle vous permet de styler des sélecteurs qui se superposent à d'autres sélecteurs et d'emprunter leurs propriétés. Supposons que vous dessiniez un blog et vouliez deux jeux de styles différents: un jeu pour un commentaire et un autre pour toute réponse à ce commentaire. Votre style pour chacun semble presque identique, à quelques exceptions près:
Alternativement, vous ne pouvez utiliser que le? classe pour les différents styles, mais cela nécessiterait que vous appliquiez à la fois le? .comment? et? classes à votre réponse HTML divs. Alors, comment pouvons-nous garder notre balisage mince tout en rendant ce code moins répétitif?
Avec Sass '@extend, ce processus est extrêmement facile. Une fois que notre sélecteur initial est en place, nous tapons simplement? @Extend? plus le nom du sélecteur que nous voulons voler et tout le code lié au premier sélecteur sera appliqué au second. À partir de là, nous pouvons entrer et appliquer nos exceptions, ajouts, etc.
Notez que nous utilisons la syntaxe plus récente .scss.
Sortie CSS
La sortie de cette commande @extend est belle et propre et représente vraiment la façon dont nous aurions dû coder notre code CSS en premier lieu. Sass recherche automatiquement les propriétés partagées et uniques et les attribue aux sélecteurs appropriés.
Alors pourquoi ne pas simplement faire cela en premier lieu? Bonne question! Vous pouvez en fait faire juste cela. Cependant, la syntaxe Sass représente un processus de pensée légèrement plus linéaire qui est plus facile à comprendre pour certains.
Gardez à l'esprit qu'il s'agit d'un exemple trop simplifié. Si vous travailliez sur un projet de grande envergure avec des tonnes de sélecteurs, les avantages de Sass seraient encore plus clairs.
Aller plus loin
Pour renforcer son utilité, le comportement @extend peut gérer un peu de complexité.Par exemple, vous pouvez utiliser plusieurs extensions sur un même sélecteur:
Vous pouvez également chaîner @extends. Cela vous permet de construire progressivement des couches de complexité de manière simple à comprendre.
Comme vous pouvez le constater, il est en fait un peu plus facile à interpréter que le formulaire CSS compilé, qui est très concis mais peut être quelque peu déroutant.
Pour en savoir plus sur Sass @extends, consultez la documentation officielle disponible sur le site Web de Sass.
Directives de contrôle
La commande Sass @extend est certainement un argument de poids pour aller de l'avant avec Sass sur LESS. C'est super utile et aide à garder votre CSS complexe pétillant propre, organisé et facile à lire.
Cependant, sur l’échelle folle, @extends a un score assez bas. Si vous voulez vraiment voir où les gens de Sass sont partis sur un territoire peu précis, vous devriez consulter les directives de contrôle, qui insèrent quelques constructions de programmation sérieuses dans CSS.
Tous les inconditionnels du pur CSS qui ne sont pas certains de Sass n'aimeront certainement pas ce que vous allez voir. Cependant, ceux d'entre nous qui sont ouverts à s'amuser avec CSS et qui aiment déjà programmer, cela devient vraiment intéressant.
Pas pour le style au jour le jour
Si vous examinez les exemples ci-dessous et décidez qu'ils vous semblent trop compliqués à utiliser dans vos projets, vous avez probablement raison. Ils viennent avec cet avertissement dès les développeurs Sass:
Remarquez que les directives de contrôle sont une fonctionnalité avancée et qu’elles ne sont pas recommandées dans le cadre du style quotidien. Ils existent principalement pour être utilisés dans les mixins, en particulier ceux faisant partie de bibliothèques comme Compass, et nécessitent donc une grande flexibilité.
Si les déclarations
Si vous n'aviez jamais pensé voir le jour où les déclarations et CSS se rencontreraient, vous vous tromperiez. Sass supporte les fonctionnalités de base if / else et les compile en CSS. Par exemple, dans l'exemple ci-dessous, nous souhaitons que la couleur du texte soit noire dans tous les cas, à l'exception de ceux où la couleur de base est déjà noire, puis nous la définissons en blanc.
Supposons donc que nous utilisons cet extrait de code dans un modèle que nous avons configuré ailleurs et que nous importons ce modèle dans notre nouveau fichier de projet. Si, à un moment quelconque, nous plaçons la couleur de base en noir comme ceci?
notre CSS compilé définira la couleur du paragraphe en blanc.
Si d'autre part, la variable de couleur de base est définie sur autre chose?
la couleur du paragraphe sera automatiquement noire par défaut.
@for Loop
En plus des instructions if, Sass prend en charge les boucles. Par exemple, supposons que nous voulions créer quatre classes de colonnes dont la largeur augmente progressivement. Au lieu de saisir chaque classe manuellement, nous pouvons économiser beaucoup de travail en mettant simplement en place une boucle for simple.
Cette instruction sera compilée dans le CSS suivant:
Remarquez comment il a utilisé le? $ I? counter pour augmenter le nombre ajouté au nom de la classe à chaque fois, puis augmenter la largeur en multipliant le courant? $ i? valeur de dix pixels.
@ While Loop
De nombreux langages de programmation prennent en charge différents styles de boucles, donc Sass lui emboite le pas en incluant non? structure mais un? while? structure aussi bien. Cette fois, supposons que nous voulions construire les classes de grille à 1 Ko en utilisant Sass. Voici comment vous le feriez:
Cette instruction se répète douze fois, en créant des classes .grid dont les noms augmentent d’un nom à la fois et définissent une largeur qui augmente de 80 pixels à chaque fois. Ce petit bout de code CSS est compilé en un gros morceau de code:
@chaque
La structure de contrôle finale est @each, ce qui vous permet de lister de manière concise un ensemble de variables à répartir sur un bloc de code plus important. Par exemple, supposons que vous vouliez créer quelques classes qui utilisent différentes familles de polices. Vous pouvez effectuer les opérations suivantes:
Cela compilera au CSS ci-dessous.Le résultat est trois classes distinctes qui utilisent les trois noms de police que nous avons placés dans la première ligne ci-dessus.
Encore une fois, pour en savoir plus sur les directives de contrôle, vous devez absolument consulter la documentation officielle. Voici un exemple particulièrement intéressant de @each qui utilise des noms d’image au lieu de polices. C'est plus utile et pratique que mon exemple ci-dessus mais je voulais illustrer une possibilité différente.
Avant de te plaindre?
L'argument évident contre leur utilisation est qu'ils enfreignent directement mes arguments pour une lecture facile du code. Celles-ci vous font gagner du temps, mais nécessitent une interprétation assez lourde, suffisante pour vous faire tourner la tête par moments. Gardez toutefois à l'esprit que les utilisateurs de Sass recommandent principalement ces applications dans les mixins, ce qui peut encore vous aider à simplifier votre code en raison de leur nature réutilisable.
J'admets volontiers qu'il est probablement préférable d'éviter les structures de contrôle dans la mesure du possible, mais je ne peux m'empêcher d'être enthousiasmé par le fait que Sass les inclut, en avertissant ou non. Ils parlent vraiment de la puissance de la syntaxe et de l’engagement de l’équipe Sass à en faire un outil de développement Web extrêmement avancé et unique.
Conclusion
Il ne s’agit en aucun cas d’une discussion exhaustive des avantages de Sass par rapport à LESS. C’est un aperçu des deux domaines que j’ai trouvés les plus impressionnants et les plus intéressants. @Extend et les structures de contrôle fournissent aux développeurs des outils puissants que vous ne trouvez tout simplement pas ailleurs. De même, LESS a quelques astuces à son actif, telles que Namespaces, que vous ne trouverez pas dans Sass.
En fin de compte, peu importe que vous utilisiez Sass ou LESS. Cela revient à une question d’opinion et si vous en préférez une, vous ne devriez pas vraiment avoir l’impression que c’est un sujet de dispute. Si je prends la route Sass et que vous prenez la route MOINS, nos deux sites Web devraient toujours contenir un fichier CSS pur à la fin (vous devriez toujours compiler avant de télécharger). Pourquoi devrais-je m'inquiéter du fait que l'itinéraire que vous avez emprunté pour vous y rendre était différent du mien? Tant que votre code résultant est valide et bien structuré, il est aussi bon que le mien.
Cela étant dit, je suis impatient de savoir quelle syntaxe vous préférez. Quant à moi, je suis assez à l'aise d'utiliser soit. Pour être honnête, j’ai commencé fermement dans le camp LESS, mais j’ai récemment été très attiré par le pouvoir que Sass affiche dans des fonctions comme celles décrites ci-dessus.
Qu'est-ce que tu penses? Avec des outils tels que CodeKit qui rendent les deux syntaxes si facilement accessibles, quelles sont les raisons pour lesquelles vous utilisez l'une sur l'autre?