Nicolas Hoizey

Ça a l’air très intéressant (mais j’ai toujours l’impression qu’on cavale dans tous les sens, des ressources / méthodologies nouvelles chaque jour, des remises en question, des nouvelles pistes, des technos à apprendre…)

@kozlika normal, c’est en mouvement perpétuel (même HTML est un « living standard »)… même si ce n’est pas toujours dans le bon sens. L’intérêt de ce framework semble justement être de consolider pas mal de choses tout en restant modulaire…

Moi je ne comprends pas pourquoi il faudrait obligatoirement Ruby (par ex, mais c’est courant) pour utiliser un préprocesseur CSS. Il faut à mon avis absolument distinguer la syntaxe (SCSS en l’occurence) et les moyens de le compiler, qui par défaut viennent de Ruby, mais qui peuvent théoriquement être programmés autrement ensuite.

Là ce n’est pas juste le compilateur SCSS qui est en Ruby (et il en existe désormais, même imparfaits, dans d’autres langages, PHP, Python etc). Non, il y a du code Ruby dans les dépôts des frameworks eux-mêmes ! Compass, Susy, etc !

C’est parfaitement rébarbatifs quand on veut intégrer ça n’importe où, et je ne trouve pas ça très propre. Ça fait que c’est moins générique et universel. Ou en tout cas il faut faire plus d’efforts quand on veut les utiliser dans d’autres projets quelconques. Moi ça me rebute alors même que j’ai commencé à apprendre et utiliser le SCSS et que je voudrais l’insérer plus souvent partout (@touti a porté un compilateur SCSS dans SPIP par exemple, sur le même principe que celui de LESS).

Bref, c’est un peu une digression, mais dès qu’il y a un super nouveau framework qui sort, et qu’on me dit « install ruby », j’ai juste envie de me barrer.

@rastapopoulos : j’utilise Sass sur mon poste avec Ruby sur mon poste, et je ne déploie que la CSS générée. Il y a un souci avec Ruby que je ne connaîtrais pas ?

(question de profane)

@rastapopoulos Ruby est une dépendance comme une autre sur le poste de dev, je ne vois pas le problème.

Je l’ai expliqué précédemment : Ruby est le langage du premier compilateur (il s’agit de compilation d’un langage), mais ce langage lui-même, SCSS, sa syntaxe, ne devrait PAS être dépendant d’un autre langage : si d’autres personnes développent des compilateurs autrement (PHP, Python, JS, etc), tout devrait marcher pareil sans aucune dépendance à Ruby.

Quand tu fais du Java (par exemple), tu écris dans ce langage, et personne ne t’oblige à utiliser tel compilateur précis, il en existe plusieurs, certains écrits en C, d’autres en Java, etc.

C’est pareil pour les préprocesseurs : si tu es intégrateur, développeur front, tu apprends le SCSS et ensuite qu’il soit compilé en Ruby, en PHP ou autre ne devrait pas spécialement être ton affaire.

Et justement, la compilation ne se fait pas forcément sur le poste de dev : on peut avoir un compilateur côté serveur qui met les fichiers compilés en cache, et chez soi, un dev n’a qu’à toucher les feuilles SCSS ou LESS.

dès qu’il y a un super nouveau framework qui sort, et qu’on me dit « install ruby », j’ai juste envie de me barrer.

J’ai eu ce genre de réaction vis à vis de Sass. Au boulot, on a un environnement hétérogène (Windows, Linux, macOS)... une dépendance supplémentaire à gérer... bof (Et pourtant, j’essaierais bien Ruby :-)

@rastapopoulos ok, Ruby ne doit pas être une dépendance, mais alors que certains développent des compilateurs aussi complets et à jour dans d’autres langages. Je ne suis pas sûr que ce soit le cas, ni que ce soit pertinent vu la déperdition d’énergie que cela provoque.

Pour ce qui est de la compilation en prod, je suis contre, c’est trop risqué.