Quels sont les avantages et les inconvénients de Coffeescript? [fermé]

Bien sûr, un gros avantage est la quantité de sucre syntaxique qui conduit à un code plus court dans de nombreux cas. Sur http://jashkenas.github.com/coffee-script/, vous trouverez des exemples impressionnants. Par ailleurs, je doute que ces exemples représentent un code d’applications complexes du monde réel. Dans mon code, par exemple, je n’ajoute jamais de fonctions à des objets nus, mais plutôt à leurs prototypes. De plus, la fonctionnalité du prototype est cachée à l'utilisateur, suggérant une POO classique plutôt que du Javascript idiomatique.

L'exemple de compréhension de tableau ressemblerait probablement dans mon code à ceci:

cubes = $.map(list, math.cube); // which is 8 characters less using jQuery...

Je suis l'auteur d'un prochain livre sur CoffeeScript:
http://pragprog.com/titles/tbcoffee/coffeescript

J'étais convaincu que CoffeeScript valait la peine d'être utilisé après environ une semaine d'utilisation, même si le langage n'était que vieux de quelques mois à l'époque et comportait beaucoup plus de bords rugueux qu'aujourd'hui. Le site officiel fait un excellent travail en énumérant (la plupart des) les fonctionnalités de la langue, je ne vais donc pas les répéter ici. Je dirai plutôt que les avantages de la langue sont les suivants:

1. Encourage l'utilisation de bons modèles JavaScript
2. Décourage les anti-patterns JavaScript
3. Rend même le bon code JavaScript plus court et plus lisible

Le n ° 3 attire beaucoup plus l'attention que les deux premiers (même dans mon livre), mais plus j'y pense, plus je réalise que je n'ai pas fait le saut uniquement pour la jolie syntaxe; J'ai fait le saut parce que le langage m'a poussé vers un meilleur JavaScript, moins sujet aux erreurs. Pour donner quelques exemples rapides:

• Comme les variables ont une portée automatique, vous ne pouvez pas écraser accidentellement des éléments globaux en omettant var, masquer une variable portant le même nom (sauf avec les arguments nommés) ou avoir des variables dans des fichiers différents qui interagissent (voir https://stackoverflow.com/questions / 5211638 / pattern-for-coffeescript-modules / 5212449 ).
• Parce que ->c’est beaucoup plus facile à écrire function(){}qu’il est plus facile d’utiliser des rappels. L'indentation sémantique indique clairement quand les rappels sont imbriqués. Et =>facilite la conservation, le thiscas échéant.
• Parce qu’il unless xest plus facile pour les anglophones d’analyser que if (!x), et if x?est plus facile if (x != null), de ne donner que deux exemples, vous pouvez passer moins de cycles cérébraux sur la syntaxe logique et davantage sur la logique elle-même.

Une excellente bibliothèque comme Underscore.js peut résoudre certains de ces problèmes, mais pas tous.

Maintenant pour les inconvénients:

1. La compilation peut être pénible. Les erreurs de syntaxe générées par le compilateur CoffeeScript sont souvent vagues. Je m'attends à des progrès sur cette voie dans le futur. (Dans la défense du compilateur, il détecte souvent des erreurs que vous ne découvririez pas comme une erreur avant que cette ligne de code ne soit exécutée. Si vous les écriviez en JavaScript, il est préférable d'attraper ces bogues plus tôt que plus tard.)
2. Relativement, le débogage peut être une douleur. Il n’existe pas encore de moyen de faire correspondre les lignes JS compilées à la version originale de CoffeeScript (bien que les utilisateurs de Firefox aient promis que cela arriverait).
3. C'est sujet au changement. Votre code peut être exécuté différemment ou ne pas être exécuté du tout sous une future version de CoffeeScript. Bien sûr, c’est le cas de la plupart des langages (le passage à une nouvelle version de Ruby ou de Python est similaire), mais ce n’est pas le cas avec JavaScript, où l’on peut raisonnablement s’attendre à ce que le code qui fonctionne bien sur les principaux navigateurs fonctionne bien sur les principaux navigateurs. navigateurs aussi longtemps que le Web tel que nous le connaissons existe.
4. Ce n'est pas aussi connu. JavaScript est une lingua franca . CoffeeScript est devenu très populaire en peu de temps, mais il est peu probable qu'il profite jamais d'une communauté aussi vaste que JavaScript.

Évidemment, je pense que les avantages l'emportent sur les inconvénients pour moi personnellement, mais ce ne sera pas le cas pour chaque personne, équipe ou projet. (Même Jeremy Ashkenas écrit beaucoup de JavaScript.) Il est préférable de considérer CoffeeScript comme un complément parfait à JavaScript, et non comme un substitut.

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:

1. Le code CoffeeScript résultant était assez lisible.

2. 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).

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

Avantages

Voir la réponse de Trevor Burnham .

De plus, vous pouvez penser à vous comme à un gars branché, qui fait des choses à la mode, au lieu de jouer avec la saleté du javascript.

Les inconvénients

CoffeeScript n'est rien de plus que du sucre syntaxique et des lunettes roses.

Pour des choses faciles - CoffeeScript est redondant, parce que faire des choses faciles est facile dans toutes les langues. Et jQuery est probablement encore plus simple que CoffeeScript.

Pour les choses difficiles - vous devez comprendre votre média. Et votre support est HTML, DOM et CSS, Javascript est simplement un outil pour les interconnecter, mais toutes les API sont écrites spécifiquement pour Javascript. Utiliser un autre langage, qui serait ensuite compilé en un "vrai" - est assez risqué, que ce soit en Java (GWT), Dart ou CoffeeScript.

Les anti-modèles ou l'ignorance banale des règles de langue peuvent être corrigés en lisant un ou deux bons livres. Et je suis tout à fait sûr que Coffeescript a ses propres anti-modèles.

Le support IDE pour Coffeescript est encore pire que pour JS.

Le plus grand pro, dans mon esprit, c'est:

Coffescript simple compile dans le javascript que vous auriez dû écrire, mais ne l'a pas fait, car ce n'était pas simple.

Il y a de mauvais coins de javascript qui ne sont évités que par la vigilance - des exemples spontanés:

• régler le prototype correctement
• en utilisant === au lieu de ==
• vérification de null
• déclarer toutes les variables avec var
• envelopper tout dans une fonction anonyme auto-exécutable.

Si vous écrivez coffeescript, tout cela est traité automatiquement pour vous .

Les inconvénients sont, IMO, principalement mineurs:

• Le débogage est une douleur
• Il y a moins de programmeurs coffeescript
• Vous devez traduire la documentation de javascript à coffeescript.

avantages

1. CoffeeScript m'a aidé à en apprendre davantage sur JavaScript
2. est assez facile à lire, même pour les rappels complexes imbriqués
3. offre une sécurité relative à certains problèmes de langage javascript difficiles à détecter

L'exemple de travail ci-dessus d'Andrew m'a semblé éclairant. Je crois que la lisibilité de leurs retours littéraux d’objet existants serait améliorée par une simple identification manuelle du retour.

revenir

// objet littéral ici

Les outils IDE ont été améliorés, TextMate et Cloud9 prennent en charge CoffeeScript. Certes, le support de Windows est à la traîne (n'est-ce pas vrai pour le développement web en général?)

les inconvénients

CoffeeScript interprété par le navigateur peut être difficile à déboguer.

C'est une couche supplémentaire au-dessus de JavaScript qui nécessite une compréhension et une considération de la part des développeurs.

avantages

1. ils ont vraiment optimisé les cas courants sur le plan de la synchronisation, en fait, CoffeeScript est l’un des langages les plus concis, voire le plus concis, qui est utilisé couramment http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked- par expressivité /
2. cache les mauvaises parties de JavaScript (auto-coercion ==, globals implicites, un système de classes plus traditionnel facilite les choses courantes)
3. extrêmement facile à apprendre pour les programmeurs Python / Ruby
4. fonctions anonymes multilignes + syntaxe d'espaces

les inconvénients

1. la suppression de var signifie que vous ne pouvez pas modifier une variable de portée externe dans une portée interne sans utiliser d'objet, ou `var fall_back_to_js;` hacks [pourquoi pas une autre instruction d'affectation ': =', qui ne fait que réaffecter une valeur, ainsi obj.naem: = 5 fautes de frappe plus faciles à déboguer]
2. vous devez en informer tous les outils, sauf si vous souhaitez déboguer JavaScript: vous pouvez déboguer CoffeeScript à partir de Chrome en ajoutant le support des mappages sources; yeoman (npm install yeoman) peut vous aider à écrire un fichier de configuration gulp ou grunt pour CoffeeScript
3. pas de typage statique optionnel (faut attendre la prochaine norme EcmaScript)
4. toujours besoin de bibliothèques tierces pour un système de module
5. les syntaxes sont à surveiller : retours implicites, abgo signifie a (b (g (o))) , fp, b: 2, c: 8 signifie f (p, {b: 2, c: 8}) plutôt que f (p, {b: 2}, {c: 8})
6. ne change pas le système de numéro / type JavaScript cassé