Pour la minification, c'était à moitié du troll, j'avoue, parce que oui, il suffit de développer en non minifié et de minifier en prod uniquement.
Reste la transpilation, où tu débugges dans un langage ce que tu as écris dans un autre.
Donc il y a l'option source map pour vraiment faire le lien avec le code d'origine.
Mais tu as quand même bien intérêt à connaître le javascript, et rapidement à savoir aussi comment ton code source se transpile vers le javascript.
J'ai surtout de l'expérience avec jQuery, donc pas de transpilage, pas de surcouche, direct en javascript et tu peux être à peu près sûr que si ça plante c'est de la faute de ton code et non de celui de jQuery. Ben rien que là les messages d'erreur sont parfois complètement inutilisables...
J'ai juste du mal à appréhender l'idée de rajouter des couches entre ton code et le logiciel qui va te dire où et comment ça bugge :)
Cela dit ce n'est pas pire qu'un « segmentation fault - core dumped », faut connaître les outils derrière pour interpréter ce qu'il se passe.
Pour avoir - très brièvement - fait du coffeescript, j'ai abhorré à cause de ça, et aussi du manque d'intérêt général pour la chose quand on sait déjà coder en Javascript simple : quel est l'intérêt d'un langage moins verbeux si en pratique tu dois connaître les deux, débugger dans l'un pour écrire dans l'autre, et en plus gérer les éventuels bugs du transpilage ? Le gain de temps à l'écriture du code vaut-il la perte de temps en apprentissage et débuggage ?
Clairement mon projet d'alors n'était pas en faveur du coffeescript ^^
[^] # Re: On n'est pas limité au JS côté front
Posté par Yth (Mastodon) . En réponse au journal 8 mois avec Javascript (ES6) et vue.js : mon retour d'expérience du développement front en 2018. Évalué à 2.
Pour la minification, c'était à moitié du troll, j'avoue, parce que oui, il suffit de développer en non minifié et de minifier en prod uniquement.
Reste la transpilation, où tu débugges dans un langage ce que tu as écris dans un autre.
Donc il y a l'option source map pour vraiment faire le lien avec le code d'origine.
Mais tu as quand même bien intérêt à connaître le javascript, et rapidement à savoir aussi comment ton code source se transpile vers le javascript.
J'ai surtout de l'expérience avec jQuery, donc pas de transpilage, pas de surcouche, direct en javascript et tu peux être à peu près sûr que si ça plante c'est de la faute de ton code et non de celui de jQuery. Ben rien que là les messages d'erreur sont parfois complètement inutilisables...
J'ai juste du mal à appréhender l'idée de rajouter des couches entre ton code et le logiciel qui va te dire où et comment ça bugge :)
Cela dit ce n'est pas pire qu'un « segmentation fault - core dumped », faut connaître les outils derrière pour interpréter ce qu'il se passe.
Pour avoir - très brièvement - fait du coffeescript, j'ai abhorré à cause de ça, et aussi du manque d'intérêt général pour la chose quand on sait déjà coder en Javascript simple : quel est l'intérêt d'un langage moins verbeux si en pratique tu dois connaître les deux, débugger dans l'un pour écrire dans l'autre, et en plus gérer les éventuels bugs du transpilage ? Le gain de temps à l'écriture du code vaut-il la perte de temps en apprentissage et débuggage ?
Clairement mon projet d'alors n'était pas en faveur du coffeescript ^ ^
Yth.