Aujourd'hui, nous allons opposer deux préprocesseurs CSS. Vous avez sans doute vu beaucoup de discussions sur la façon dont SCSS se compare à LESS, mais en quoi Stylus, le nouveau venu, intervient-il? Peut-il correspondre à la puissance et à la polyvalence du SASS?
Nous allons passer directement aux deux syntaxes et les comparer côte à côte pour déterminer celle qui est la plus logique et la plus polyvalente. Nous parlerons également de fonctionnalités et vous expliquerons clairement pourquoi un préprocesseur est plus puissant. Vous pouvez être rassuré, nous n'allons pas nous faufiler et vous donner des conneries à propos d'une cravate, il y aura un gagnant!
Sass, pas SCSS
Un petit détail doit être abordé avant de plonger davantage dans cette question. La syntaxe que nous allons utiliser aujourd'hui est Sass, pas de SCSS. Le dernier de ces derniers est la forme la plus récente, c'est donc probablement celle que vous connaissez le mieux.
Cependant, à des fins de comparaison, Sass est en réalité beaucoup plus proche de Stylus que son frère SCSS. Alors que SCSS était une tentative de contrôler Sass et de rendre la syntaxe plus proche de CSS, Stylus suit le modèle du langage Sass original en abandonnant la plupart des syntaxes structurelles telles que les points-virgules et les accolades.
Hélas, ce n’est pas un article sur les mérites de Sass contre SCSS, c’est pourquoi je ne vais pas m'étendre sur ce sujet. Si vous recherchez une bonne discussion sur ce sujet, consultez la page suivante: Sass vs SCSS: quelle syntaxe est la meilleure? de la façon Sass. En général, gardez simplement à l'esprit que Sass et SCSS ont essentiellement les mêmes fonctionnalités, la seule différence est la façon dont vous les écrivez.
Syntaxe de base
Commençons par une comparaison directe des deux syntaxes à leur niveau le plus élémentaire. Nous écrirons la même déclaration dans les deux langues et verrons où se situent les différences.
Comme vous pouvez le voir, ils sont presque identiques. Aucune des deux syntaxes ne nécessite des accolades ou des points-virgules, ce qui signifie bien sûr qu'ils dépendent tous les deux assez de l'espace pour une compilation correcte. La grande différence que nous voyons à ce stade concerne les deux points: Sass les exige, pas Stylus.
La flexibilité
Une chose que j'ai toujours appréciée avec LESS et SCSS est que je peux toujours écrire du vieux CSS vanille dans ma feuille de style. Ces syntaxes sont si proches du CSS que vous pouvez choisir des points clés pour mettre en œuvre leurs fonctionnalités spéciales, mais vous n'avez pas à vraiment réentraîner votre cerveau pour écrire du CSS.
Autant que je sache, Sass n’a pas cette capacité, mais Stylus l’a apparemment (démontré ici). Cependant, j'utilise CodeKit pour compiler mon stylet, ce qui ne me permet pas de mélanger du CSS pur avec Sass ou Stylus. Si je jette une simple ligne de code CSS pur sur l'un ou l'autre, le code ne sera pas compilé (les deux langues ont un rapport d'erreur).
Cela étant dit, Stylus et Codekit offrent un peu de flexibilité que vous ne trouverez pas dans Sass. Par exemple, Stylus ne nécessite pas l'utilisation de deux points ni de points-virgules, mais permet d'utiliser les deux. Il n'aime tout simplement pas les accolades. Sass, d’autre part, requiert des deux-points et ne compilera pas si vous utilisez des points-virgules.
Syntaxe de base Vainqueur: Stylet
Si vous utilisez une syntaxe de préprocesseur simplifiée, Stylus est le meilleur des deux à mon avis. La réponse simple est que Stylus vous permet de choisir votre niveau de verbosité pendant que Sass vous force à utiliser une méthode définie.
En toute honnêteté, la raison même pour laquelle je déclare Stylus vainqueur ici pourrait vous faire considérer comme un perdant. La syntaxe flexible est un mot sale comportant de nombreux codeurs car elle peut entraîner un codage bâclé et incohérent. Si vous souhaitez utiliser Stylus, vous devez choisir une méthode de déclaration et vous y tenir. N'écrivez pas deux lignes de code n'utilisant que des points-virgules, puis basculez vers le basculement entre deux points, puis utilisez à nouveau ni l'un ni l'autre.
Nidification
L'imbrication vous permet d'économiser du codage répétitif en imbriquant des sélecteurs les uns dans les autres. Alors quand un? P? le sélecteur est niché dans un? div? sélecteur, le résultat de la compilation sera à la fois? div? et? div p ?. Cette fonctionnalité est presque identique dans Stylus et Sass.
Sass va même plus loin dans le concept d'imbrication et vous évite d'avoir à taper des noms de propriété répétitifs. Par exemple, considérons l'exemple ci-dessous. Dans Stylus, vous devez répéter la police? partie, mais Sass permet l’imbrication en tant que méthode alternative.
Gagnant: Sass
Le simple fait est que Sass a une fonctionnalité intéressante que Stylus n’a pas. Je ne l'ai jamais utilisé et je ne suis pas sûr de commencer maintenant, mais je vois à quel point cela pourrait être utile, en particulier dans les cas d'alignement de texte, d'ombre de texte, de décoration de texte, etc., là où aucune alternative abrégée n'existe. .
Variables
L’inclusion de variables est l’un des principaux avantages des pré-processeurs. Beaucoup de développeurs de la vieille école pensent que les variables n’ont pas d’affaires proches de CSS, mais d’innombrables autres pensent que les variables sont l’une des possibilités les plus cool de faire tourner CSS. Personnellement, je trouve les variables CSS extrêmement utiles.
Stylus et Sass incluent un support variable. Voici à quoi ressemble chacune d’entre elles en utilisant une variable pour déclarer la taille de police d’un paragraphe.
Une fois encore, nous voyons que la syntaxe Stylus était un peu plus succincte. Notez que Sass nécessite l'utilisation d'un caractère supplémentaire (le signe dollar) pour référencer les variables. Stylus utilise également un symbole d'égalité au lieu de deux points, ce qui devrait sembler familier aux développeurs JavaScript.
Les deux langues permettent également des opérations variables, vous pouvez donc ajouter, soustraire, multiplier et diviser des variables au contenu qui vous convient.
Gagnant: Draw (je préfère la syntaxe Sass)
Soyons clairs, si nous marquons tout simplement sur la verbosité, Stylus continuera à gagner. C'est la syntaxe la plus courte, point. Mais l'hypothèse selon laquelle plus court est le mieux, n'est pas toujours correcte.
Chose intéressante, sur le plan personnel, je pense que je préfère la méthode Sass ici. La syntaxe du côlon juste se sent plus comme CSS. De plus, les gens sont tellement peu habitués à voir des variables dans leur CSS que les signes du dollar les aident vraiment à se démarquer. Je peux facilement parcourir des centaines de lignes de Sass et repérer les variables, tâche qui est considérablement plus difficile avec Stylus.
Recherche de propriété
Alors que nous sommes sur le sujet des variables, il convient de mentionner que Stylus a un unique? Property Lookup? fonctionnalité qui vous permet de réellement vous épargner certaines des variables que vous auriez normalement à utiliser avec Sass. Par exemple, supposons que vous souhaitiez définir le remplissage d'un élément sur la moitié de sa marge. Avec Sass, vous devez utiliser des variables pour y parvenir (pour autant que je sache), mais avec Stylus, vous pouvez utiliser le paramètre? @? syntaxe pour référencer la valeur d'une autre propriété dans le même bloc de déclaration.
Gagnant: Stylet
Sass n'a même pas d'équivalent à la fonctionnalité de recherche de propriétés, donc celle-ci n'est pas un concours. Personnellement, j’aime vraiment avoir cette capacité et espère que les Sass envisagent de l’ajouter.
Mixins & Fonctions
Ensuite, nous examinerons les mixins. Celles-ci sont un peu comme des variables pour de gros morceaux de code au lieu d'une propriété ou d'une valeur unique. Les mixins sont peut-être l’un des outils les plus puissants dont disposent les préprocesseurs CSS pour vous faire gagner du temps et de l’énergie. Savoir utiliser correctement les mixins facilitera votre travail!
Voici un exemple de syntaxe Stylus et Sass sur une définition type de bord-rayon. L'avantage ici est qu'il vous suffit d'écrire tous les préfixes de votre navigateur une fois, puis de permettre au préprocesseur de jouer de sa magie partout où vous les implémentez.
Encore une fois, nous voyons que Sass a besoin de plusieurs symboles et syntaxes supplémentaires, tandis que Stylus garde les choses propres. Notez également que Stylus a la possibilité d’utiliser quelque chose appelé "mixins transparents". où vous n'avez même pas besoin d'utiliser des parenthèses lorsque vous appelez le mixin. Il semble que j'utilise simplement la propriété default border-radius alors qu'en fait, j'utilise mon mixin.
Les fonctions sont une construction similaire, mais elles sont généralement conçues pour effectuer une opération et renvoyer une valeur. Voici la syntaxe de la fonction pour chaque langue:
Gagnant: Stylet
Après avoir écrit le mixin et les fonctions avec Stylus, puis revenir à Sass, ce dernier semblait être un travail beaucoup plus laborieux. La manière Stylus est vraiment sans effort tandis que Sass vous écrit constamment? @Mixin ?,? @Include ?,? @Function? et? @retour ?, qui semble superflu.
La viande de l'argument: quel est le meilleur?
Je ne suis pas le premier à faire une comparaison directe d'exemples tels que celui ci-dessus, bien que j'aie volontairement fait un pas de plus que d'autres, en indiquant clairement ma préférence dans chaque cas.
Honnêtement, Sass et Stylus sont bien trop énormes pour que je puisse continuer sur cette voie de comparaison syntaxique. Il y a beaucoup plus de cas où vous pourriez trouver que Stylus et Sass sont presque identiques dans leurs approches. Voici quelques fonctionnalités que les deux partagent:
- Interpolation
- Héritage du sélecteur via @extend
- Conditions de style if et else (directives de contrôle)
- Fonctions de couleur intégrées
- Itération
- Directives d'importation
Vous devriez avoir une idée de la façon dont chaque langue fonctionne maintenant, alors passons à une discussion pure et simple sur les différences entre elles et pourquoi c'est important. Une chose à laquelle il faut penser tout de suite, c'est que Stylus est spécifiquement conçu pour s'associer à Node.js. Par conséquent, si vous êtes un fan de Node, cela pourrait être la voie à suivre.
Dans l'ensemble, il semble que Stylus soit l'option la plus flexible et la plus puissante. Il y a quelques cas où Sass réussit un tour que Stylus ne peut pas, mais je n'ai pas rencontré de "stylus tueur". caractéristique qui me ferait dire clairement que Sass est le meilleur.
Inversement, il semble y avoir une tonne de petites choses que vous trouvez en creusant dans Stylus et que vous manquez lorsque vous revenez à Sass. J'en ai déjà mentionné quelques-unes, telles que la fonctionnalité de recherche de propriétés. Un autre élément intéressant est le? Arguments? variable locale automatique pour mixins, ce qui vous permet de passer l'étape de création de votre propre variable afin de dupliquer tous les arguments d'un mixin. Il y a aussi la fonctionnalité rest params qui utilise les arguments restants passés à un mixin ou à une fonction (cette fonctionnalité peut être dans Sass, mais je ne l'ai pas trouvée):
Enfin, Stylus simplifie énormément les requêtes des médias, qui sont un peu volumineuses et délicates avec tous ces supports. Voici une requête de support d'impression Stylus:
Qu'en est-il du SCSS?
Mon préprocesseur quotidien préféré est Sass avec la syntaxe SCSS. Jusqu'à la rédaction de cet article, je n'avais pas beaucoup expérimenté les syntaxes allégées, car je trouvais un peu effrayant de jeter toutes les règles que j'avais tellement enracinées dans mon cerveau.
De plus, j'aime bien l'idée que quelque chose se connecte à mon flux de travail CSS actuel plutôt que d'essayer de le changer complètement. Cela étant dit, je me suis rapidement adapté à la façon de faire des stylets et je ne m'en soucie pas autant que je le pensais. C'est plutôt agréable de laisser tomber ces deux-points!
Mais disons que vous ne pouvez tout simplement pas vous y habituer ou pensez que c'est une mauvaise pratique d'utiliser une syntaxe simplifiée, car cela vous ferait oublier comment écrire un code CSS correct. Dans ce cas, SCSS est la solution idéale? Peut-être pas.Tant que vous utilisez la ligne de commande ou un meilleur compilateur que CodeKit, Stylus vous permet d’adopter le style? CSS? de syntaxe, ce qui signifie que vous pouvez tirer parti de tous les goodies trouvés dans Stylus sans accepter la méthode effrayante de la création CSS.
Qu'en est-il de Compass?
Une des pièces absolument fondamentales de ce casse-tête est Compass, qui permet à Sass d'atteindre de nouveaux sommets. Évidemment, si vous comptez sur cet outil, le passage à Stylus sera beaucoup plus difficile. Cependant, il existe un projet étroitement lié appelé Nib qui tente d’apporter une certaine qualité CSS3 similaire à Stylus.
Conclusion
Cela me fait mal de le dire mais Stylus semble vraiment avoir le dessus à bien des égards. Il a l'avantage d'apprendre et d'améliorer ce qui a été fait avec Sass et s'en tire mieux. Cela étant dit, je ne vais probablement pas abandonner le SCSS de si tôt. Je crois au projet Sass et suis convaincu que son adoption généralisée continuera à apporter de nombreuses améliorations. Je ne suis pas sûr d'avoir la même confiance en Stylus.
Laissez un commentaire ci-dessous et dites-nous ce que vous pensez. Quel pré-processeur vous semble le mieux et pourquoi? Indépendamment de ce qui a plus d'astuces dans sa manche, lequel utiliserez-vous à long terme?