Nous avons une base de code JavaScript assez importante et il y a environ un mois, nous avons décidé d'essayer CoffeeScript. L'un de nos développeurs a commencé par migrer l'un de nos modules de JS à CS à l'aide de http://js2coffee.org/ . Cet outil était plutôt pratique et il a fallu environ deux ou trois heures pour porter une ligne de code JavaScript d'environ 1000 mots. Certaines observations que nous avons remarquées à ce stade:
Le code CoffeeScript résultant était assez lisible.
Nous l'avons compilé en JavaScript et il était assez facile de naviguer et de déboguer. Pendant que nous portions ce module, un autre développeur de notre équipe a trouvé un bogue dans celui-ci. Ces deux développeurs ont corrigé ce bogue dans notre ancien code JavaScript et dans le nouveau code JavaScript issu du compilateur CS. Ils ont travaillé indépendamment et cela leur a pris à peu près le même temps (15-20 minutes).
Du fait qu'il s'agisse d'un port, le code résultant n'utilisait pas de fonctionnalités spécifiques à Coffee appropriées ou souhaitables. Si nous écrivions à partir de zéro dans CoffeeScript, le code serait plus idiomatique. A cause de cela plus tard, nous avons décidé de ne pas transférer le code existant.
En général, la lisibilité d'une fonction plus courte et d'un objet plus petit a augmenté dans une certaine mesure. Cependant, pour des méthodes plus longues, ce n'était pas du tout le cas. Les économies les plus importantes ont été réalisées de manière ->explicite return, mais à part cela, notre code n'avait pas été considérablement réduit ni simplifié. Certaines parties de la syntaxe semblaient assez déroutantes, en particulier les littéraux d'objet. CS omet les accolades entourant les définitions des membres et est combiné avec "tout est une expression" et implicite, ce returnqui rendait difficile la lecture de certains éléments de code.
Voici JavaScript:
var rabbitGenerator = {
makeRabbit: function(rabbitName, growCarrots) {
if (growCarrots) {
carrots.growMore(10);
} else {
carrots.ensureSupply();
}
return {
name: rabbitName,
height: 0,
actions: {
jump: function (height) {
this.height += height;
},
eatCarrot: function () {
// etc
}
}
};
},
// more members
}
Et voici à quoi ressemblerait le code CoffeeScript correspondant:
rabbitGenerator =
makeRabbit: (rabbitName, growCarrots) ->
if growCarrots
carrots.growMore 10
else
carrots.ensureSupply()
name: rabbitName // (*)
height: 0
actions:
jump: (height) ->
@height += height
eatCarrot: ->
En l'état actuel des choses, il est assez difficile de comprendre que l'instruction de retour commence à la (*)ligne. Dans notre projet, nous nous basons fortement sur les littéraux d'objet: nous les transmettons en tant que paramètres de fonction et les renvoyons à partir d'autres fonctions. Dans de nombreux cas, ces objets ont tendance à être assez complexes: ils comportent des membres de types différents et plusieurs niveaux d'imbrication. Dans notre cas, le sentiment général était que le code CoffeeScript était en réalité plus difficile à lire que le code JavaScript simple.
Bien que le débogage, CoffeeScript s’est avéré plus facile que prévu, l’expérience de l’édition s’est quelque peu dégradée. Nous n'avons pas pu trouver un bon éditeur / IDE pour cette langue. Nous n'avons pas standardisé l'éditeur / IDE pour le code côté client de notre projet et, en fait, nous utilisons tous des outils différents. En fait, tous les membres d'une équipe conviennent que, lorsqu'ils passent à CoffeeScript, leur outil leur fournit un support plutôt médiocre. Les plugins IDE et éditeur sont très anciens et dans certains cas, ils ne peuvent même pas nous fournir un support de mise en évidence de la syntaxe ou d'indentation approprié. Ne pas parler d'extraits de code ou de refactoring. Nous utilisons WebStorm, Eclipse, NetBeans, VisualStudio, Notepad ++ et SublimeText2.
En parlant d’outils, je devrais mentionner que le compilateur CoffeScript lui-même se présente sous la forme d’un package Node JS. Nous sommes principalement une boutique Java / .NET, donc tout le monde se développe sur des machines Windows. Jusqu'à récemment, le support Windows était presque inexistant dans Node. Nous ne pouvions pas faire fonctionner le compilateur CoffeeScript sous Windows, nous avons donc décidé pour l’instant de nous en tenir aux <script type="text/coffeescript">balises et au compilateur à la volée basé sur un navigateur.
Le compilateur est assez rapide et n'augmente pas beaucoup le temps de démarrage. L'inconvénient est que le code JavaScript résultant est evalédité et qu'il est un peu difficile d'y insérer des points d'arrêt dans les outils de développement des navigateurs (en particulier dans IE8). Si nous avons du mal à déboguer, nous pré-compilons le code CoffeeScript avec le même outil de migration que celui que j'ai énuméré ci-dessus, mais ce n'est toujours pas très pratique.
D'autres promesses de CoffeeScript, telles que l' varinsertion automatique ou la gestion semi-transparente de l' thisopérateur avec une grosse flèche ( =>) se sont avérées moins rentables que nous l'espérions. Nous utilisons déjà JSLint dans le cadre de notre processus de construction et nous écrivons du code dans un ES3 x ES5-Strictsous-ensemble du langage. Quoi qu'il en soit, le fait que le café produise le même type de code "propre" est une bonne chose . Je souhaite que chaque infrastructure côté serveur produise des balises HTML5 et CSS3 valides également!
Cela dit, je ne dirais pas que CoffeeScript permet de gagner beaucoup de temps en mettant des varmots clés pour moi. Les fichiers manquants varsont facilement récupérés par JSLint et sont facilement réparables. De plus, une fois que vous avez été corrigé pendant un certain temps, vous commencez à écrire un bon JavaScript automatiquement quand même. Ainsi , je ne dirais pas que le café est vraiment que utile à cet égard.
Nous avons évalué CoffeeScript pendant environ une semaine. Tous les membres de l'équipe écrivaient du code et nous partagions nos expériences les uns avec les autres. Nous avons écrit du nouveau code avec celui-ci et en avons porté le code existant lorsque nous le jugions utile. Nos sentiments à propos de la langue étaient mélangés.
En général, je dirais que cela n’a pas accéléré notre développement, mais que cela ne nous a pas ralenti non plus. Certains gains de vitesse dus à moins de dactylographie et à moins de surface d'erreur ont été compensés par des ralentissements dans d'autres domaines, principalement le support des outils. Après une semaine, nous avons décidé de ne pas imposer l’utilisation de CoffeeScript, mais nous ne l’interdisons pas non plus . Si le choix est libre, personne ne l'utilise en pratique, du moins pour le moment. De temps en temps, je pense à prototyper une nouvelle fonctionnalité, puis à convertir le code en JavaScript avant de l'intégrer au reste du projet pour un démarrage plus rapide, mais je n'ai pas encore essayé cette approche.