5139 sujets

Le Bar du forum

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 Smiley cligne ) :
.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)
Tiens ! Un de mes propre sujet sur lequel je retombe via Google...

Du coup un p'tit retour pour mon moi du futur : après avoir tenté SASS trois jours, j'ai viré le truc car j'ai découvert une incompatibilité avec le nested CSS vanilla, marre de me battre avec des outils qui sont censés me faciliter la tâche... Du coup, hop : PostCSS. Surtout pour une gestion fine des outputs avec "postcss-preset-env", le top, j'avais pas saisi le concept au départ, c'est vraiment un plus qui fait pencher la balance.

J'ai un problème avec le plugin "postcss-each" qui semble incompatible avec "postcss-simple-vars", il semble qu'il faille configurer une option du genre "beforeEach" ou "afterEach"... pas encore compris le principe... Rien de bien grave, je poserais peut-être une question à ce sujet sur le forum.

Édit : "postcss-each" était archivé, du coup j'ai remplacé différents plugins en un seul comme ça pas de problème de compatibilité, il s'agit de "postcss-advanced-variables". Il fait donc les variables, les boucles for et each, les mixins, et quelques autres bricoles propre à des outils tel que SASS, mais sans les inconvénients de compatibilité.

Voici ma config pour l'instant :
// postcss.config.cjs

module.exports = {
  map: { inline: false },
  plugins: [
    require('postcss-import'),
    require('postcss-advanced-variables'),
    require('postcss-calc'),
    require('postcss-preset-env')({
      stage: 4,
      features: {
        'nesting-rules': true
      }
    }),
    process.env.NODE_ENV === 'production' ? require('postcss-minify') : ''
  ],
}

Et pour les lignes de commande :
// package.json (extrait)

{
  "type": "module",
  "scripts": {
    "css": "pnpm cssexp | pnpm csscom",
    "csscom": "postcss styles/development/{main,print,prism,gridFallback}.css --dir styles --config tasks/postcss.config.cjs --env production --watch --verbose",
    "cssexp": "postcss styles/development/{main,print,prism,gridFallback}.css --dir styles/expanded --config tasks/postcss.config.cjs --watch --verbose"
  }
}

Modifié par Olivier C (31 Dec 2023 - 21:54)