[Résolu] De l'abandon d'un outil pour un autre (Sass vs Stylus)

Bonjour,

Amateur de Sass, puis fan inconditionnel de Stylus depuis plusieurs années, c'est la mort dans l'âme que je vois Stylus prendre du retard, inexorablement. Du retard sur son concurrent Sass bien sûr, mais aussi sur CSS pour lequel il n'arrive plus à supporter les nouvelles fonctionnalités, toujours plus nombreuses, les rapports de bugs ne pouvant être recouverts par l'équipe de maintenance (ou l'unique mainteneur ?), dépassée par les événements...

Après être passé de Sass à Stylus il y a quelques années je me prépare donc à faire le trajet retour. Je viens de lire la doc : Sass a bien évolué, dans le bon sens (les chargements par modules, tout ça), il a tué RubySass, puis LibSass dont la bibliothèque C++ n'est plus maintenue depuis 2018, une seule version étant promue (plus rassurant je trouve) je me prépare donc à passer en dart-sass sous environnement node.js.

Évidemment, provenant des mondes Stylus et Pug.js, c'est bien sûr vers le format .sass que je vais me tourner.

Ces prochains jours je poserais sans doute des questions à ce sujet sur le forum add hoc. Je suis en mesure de comprendre la doc et j'ai déjà lu pas mal de tutoriels, mais j'aime bien partager avec vous sur Alsa, pour le plaisir. Alors d'ici là si vous avez des conseils, retours d'expérience, voir anecdotes sur Sass, n'hésitez pas à partager ici.

Bien amicalement.
Modifié par Olivier C (12 Jan 2023 - 23:27)

Au final, après avoir réécrit une partie de mon code pour Sass (.sass)... je garde Stylus !
La raison principale : je me suis rendu compte que la maxime de Sass, que je trouvais alléchante, à savoir qu'un code CSS valide est valide aussi dans Sass :

"Sass" a écrit :
Sass is completely compatible with all versions of CSS. We take this compatibility seriously, so that you can seamlessly use any available CSS libraries.

... n'est pas toujours respectée, pour certaines déclarations de couleurs, mais surtout pour les sélecteurs spéciaux que j'affectionne.

Pour les curieux, un exemple de sélecteur CSS impossible sous Sass (édit : supprimé car apparemment cela dépend aussi de la version de Sass).

Je préfère donc Stylus avec quelques hacks tout à fait efficients (et en réalité des solutions de contournement prévus comme telles), que des impossibilités avérées sous Sass. Quelques "hacks" pour Stylus (oui, tout le monde s'en fou ) :

.el
  color: 'calc(%s)' % (_test - 20%) // Déclaration littérale.
  width: 'max(20em, 50%)' // Idem.

@container grid-auto (25em > width > 50em) // Pas de support des comparaisons bouléens avec les Container Queries sous Stylus, mais solution de contournement avec les Media Query Range. Le support navigateur est médiocre pour ces deniers mais au final meilleurs que pour @container.
  .grid-auto
    --n: 2

En tout cas, la maxime de Sass, je vais la défendre au profit de Stylus !

Tout cela m'a bien fait réfléchir, comme par exemple la pertinence d'Autoprefixer dans mon contexte. Si un jour l'abandon de Stylus devient un passage obligé je partirais sans doute plutôt sur du PostCSS alors que je m'y refusais jusqu'à maintenant :

Sass c'est pas mal, mais il y a beaucoup de trucs qui ne servent pas à grand chose, comme les chargements par modules avec lesquels j'ai pris plaisir à faire joujou (coucou @use, mais bon : pas dur de faire des espaces de nom par fichiers quand même). L'indexage des couleurs, basé sur HSL, est rattrapé par CSS dont les couleurs hsl() sont très bien supportées aujourd'hui. Il a pratiquement perdu l'intérêt des variables (enfin pour moi les customs properties ne sont pas équivalentes mais encore un level ou deux et on y sera). Il ne reste plus à Sass que les propriétés imbriquées et surtout les calculs mathématiques. C'est encore bien mais c'est peu, et facilement remplaçable par deux/trois plugins PostCSS. Un truc du genre :

postcss-import
postcss-nested
postcss-simple-vars
postcss-url
postcss-calc

Avec ça déjà, y'a du mal.
Modifié par Olivier C (13 Jan 2023 - 17:14)