web-dev-qa-db-fra.com

Quels sont les avantages et les inconvénients de Coffeescript?

Bien sûr, un grand pro est la quantité de sucre syntaxique conduisant à un code plus court dans de nombreux cas. Sur http://jashkenas.github.com/coffee-script/ il y a des exemples impressionnants. D'un autre côté, je doute que ces exemples représentent du 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é prototype est cachée à l'utilisateur, suggérant un OOP plutôt qu'un Javascript idiomatique classique).

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...
javascriptcoffeescript
49
Philip

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 de jeu avec lui, même si le langage n'avait que quelques mois à l'époque et avait beaucoup plus d'astuces qu'aujourd'hui. Le site officiel fait un excellent travail de liste (la plupart) des fonctionnalités de la langue, donc je ne répéterai pas celles-ci ici. Je dirai plutôt que les avantages de la langue sont:

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

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

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

Une excellente bibliothèque comme nderscore.js peut prendre en charge certains de ces problèmes, mais pas tous.

Maintenant par contre:

  1. La compilation peut être pénible. Les erreurs de syntaxe lancées par le compilateur CoffeeScript sont souvent vagues. J'espère que des progrès seront réalisés sur cette voie à l'avenir. (À la défense du compilateur, il détecte souvent des choses que - si vous les avez écrites en JavaScript - vous ne découvririez pas comme une erreur jusqu'à ce que cette ligne de code s'exécute. Mieux vaut attraper ces bogues plus tôt que tard.)
  2. De même, le débogage peut être pénible. Il n'y a pas encore de moyen de faire correspondre les lignes JS compilées au CoffeeScript d'origine (bien que les gens de Firefox aient promis que cela arrive).
  3. Il a tendance à changer. Votre code peut s'exécuter différemment, ou ne pas s'exécuter du tout, sous une future version de CoffeeScript. Bien sûr, c'est le cas avec la plupart des langues - passer à une nouvelle version de Ruby ou Python est similaire - mais ce n'est pas le cas avec JavaScript, où vous pouvez raisonnablement vous attendre à ce que le code qui fonctionne correctement sur les principaux navigateurs aujourd'hui fonctionne correctement sur les principaux navigateurs aussi longtemps que le Web 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 jouisse 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.) CoffeeScript est mieux vu comme un bon complément à JavaScript, pas comme un remplacement.

54
Trevor Burnham

Nous avons une base de code JavaScript assez grande 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 vers CS en utilisant http://js2coffee.org/ . Cet outil était plutôt pratique et il a fallu environ deux ou trois heures pour porter des lignes de 1000 quelque chose de JavaScript. Quelques 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 c'était assez facile à naviguer et à déboguer. Pendant que nous portions ce module, un autre développeur de notre équipe a trouvé un bogue dedans. Ces deux développeurs ont corrigé ce bogue dans notre ancien code JavaScript et dans le nouveau code JavaScript issu du compilateur CS. Ils travaillaient indépendamment et cela leur prenait environ le même temps (15-20 minutes).

  3. En raison du fait qu'il s'agissait d'un port, le code résultant n'utilisait pas les fonctionnalités spécifiques à Coffee qui étaient appropriées ou souhaitables. Si nous écrivions dans CoffeeScript à partir de zéro, le code serait plus idiomatique. Pour cette raison, nous avons décidé plus tard de ne pas porter le code existant.

  4. En général, la lisibilité des fonctions plus courtes et des objets plus petits a augmenté dans une certaine mesure. Cependant, pour les méthodes plus longues, ce n'était pas du tout le cas. Les plus grosses économies de balles proviennent de -> et explicite return, mais à part cela, notre code n'était pas devenu beaucoup plus court ou plus simple. Certains éléments de syntaxe semblaient assez déroutants, en particulier les littéraux d'objets. CS omet les accolades autour des définitions de membres et combiné avec "tout-est-une-expression" et implicite return qui rendait certains bits de code assez difficiles à lire.

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

    Comme c'est maintenant le cas, il est assez difficile de comprendre que l'instruction de retour commence à (*) ligne. Dans notre projet, nous nous appuyons fortement sur les littéraux d'objets: 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: avec des membres de différents types et plusieurs niveaux d'imbrication. Dans notre cas, le sentiment général était que le code CoffeeScript était en fait plus difficile à lire que le code JavaScript ordinaire.

  5. Bien que le débogage de CoffeeScript se soit avéré plus facile que prévu, l'expérience d'édition s'est dégradée un peu. 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 pour notre projet et en fait, nous utilisons tous des outils différents. En fait, tout le monde dans une équipe convient que lorsqu'ils passent à CoffeeScript, ils obtiennent un support plutôt médiocre de leur outil. IDE et les plugins de l'éditeur sont en très bonne forme et dans certains cas, ils ne peuvent même pas nous fournir une prise en charge de la mise en évidence ou de l'indentation de la syntaxe appropriée. Ne pas parler d'extraits de code ou de refactorisation. Nous utilisons WebStorm, Eclipse , NetBeans, VisualStudio, Notepad ++ et SublimeText2.

  6. En parlant d'outils, je dois 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 développe sur des boîtes Windows. Jusqu'à récemment, le support Windows était presque non -existant dans Node. Nous ne pouvions pas faire fonctionner le compilateur CoffeeScript sur Windows, donc pour le moment nous avons décidé de nous en tenir à <script type="text/coffeescript"> balises et compilateur à la volée basé sur navigateur.

    Le compilateur est assez rapide et n'augmente pas beaucoup le temps de démarrage. L'inconvénient est que le JavaScript résultant est evaled et il est un peu difficile d'y mettre des points d'arrêt dans les outils de développement des navigateurs (en particulier dans IE8). Si nous avons du mal avec le débogage, nous précompilons le code CoffeeScript avec le même outil de migration que j'ai énuméré ci-dessus, mais ce n'est toujours pas très pratique.

  7. D'autres promesses de CoffeeScript comme l'insertion automatique de var ou la gestion semi-transparente de this avec l'opérateur de flèche grasse (=>) s'est avéré ne pas donner autant de gain que nous l'espérions. Nous utilisons déjà JSLint dans le cadre de notre processus de construction et nous écrivons du code dans ES3 x ES5-Strict sous-ensemble de la langue. Quoi qu'il en soit, le fait que Coffee produit le même type de code "propre" est un bonne chose. Je souhaite que chaque framework côté serveur produise également un balisage HTML5 et CSS3 valide!

    Cela dit, je ne dirais pas que CoffeeScript fait gagner beaucoup de temps en mettant des mots clés var pour moi. Les var manquants sont facilement détectés par JSLint et sont facilement réparables. De plus, une fois que vous êtes corrigé par cela pendant un certain temps, vous commencez à écrire bon JavaScript automatiquement de toute façon. Ainsi, je ne dirais pas que le café est vraiment ça utile à cet égard.

Nous avons évalué CoffeeScript pendant environ une semaine. Tous les membres de l'équipe y écrivaient du code et nous avons partagé nos expériences les uns avec les autres. Nous avons écrit du nouveau code avec lui et porté du code existant quand nous l'avons jugé bon. Nos sentiments sur la langue étaient mitigés.

En général, je dirais que cela n'a pas accéléré notre développement mais cela ne nous a pas ralenti non plus. Certains gains de vitesse dus à moins de frappe et moins de surface d'erreur ont été compensés par des ralentissements dans d'autres domaines, principalement le support d'outils. Après une semaine nous avons décidé de ne pas rendre obligatoire l'utilisation de CoffeeScript mais nous ne l'interdirons pas non plus. Étant donné le libre choix, dans la pratique, personne ne l'utilise, du moins pour l'instant. De temps en temps, je pense à prototyper une nouvelle fonctionnalité, puis convertir le code en JavaScript avant de l'intégrer avec le reste du projet pour obtenir un démarrage plus rapide mais je n'ai pas encore essayé cette approche.

31
Andrew Андрей Листочкин

Avantages

voir réponse de Trevor Burnham .

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

Contre

CoffeeScript n'est rien d'autre que du sucre syntaxique et des verres roses.

Pour des choses faciles - CoffeeScript est redondant, car faire des choses faciles est facile dans n'importe quel langage. Et jQuery est probablement encore plus simple que CoffeeScript.

Pour les choses difficiles - vous devez comprendre votre médium. Et votre support est HTML, DOM et CSS, Javascript n'est qu'un outil pour les interconnecter, pourtant - 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 Java (GWT), Dart ou CoffeeScript.

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

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

11
c69

Le plus gros pro, selon moi, c'est:

Le coffescript simple se compile dans le javascript que vous auriez dû écrire, mais pas, car ce n'était pas simple.

Il y a quelques coins désagréables de javascript qui ne sont évités qu'avec vigilance - des exemples du haut de ma tête:

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

Si vous écrivez du coffeescript, tout cela est géré pour vous automatiquement.

Les inconvénients sont, à mon avis, principalement mineurs:

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

avantages

  1. CoffeeScript m'a aidé à en savoir plus sur JavaScript
  2. est assez facile à lire, même pour les rappels imbriqués complexes
  3. offre une sécurité autour de certains des problèmes de langage difficiles à repérer de javascript

L'exemple de travail ci-dessus d'Andrew que j'ai trouvé éclairant. Je crois que la lisibilité de leurs retours littéraux d'objet existants serait améliorée en identifiant simplement manuellement le retour

revenir

// objet littéral ici

Les outils IDE ont été améliorés, TextMate et Cloud9 prennent en charge CoffeeScript. Certes, la prise en charge de Windows a pris du retard (n'est-ce pas vrai pour le développement Web en général?)

les inconvénients

L'interprétation de CoffeeScript par le navigateur peut être difficile à déboguer.

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

3
user38265

avantages

  1. ils ont vraiment optimisé les cas communs de manière syntatique, en fait, CoffeeScript est l'un, sinon le langage le plus concis qui est "couramment" utilisé http://redmonk.com/dberkholz/2013/03/25/programming- langues classées par expressivité /
  2. cache les mauvaises parties de JavaScript (coercition automatique ==, globaux 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 sur plusieurs lignes + 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 un objet, ou `var fall_back_to_js;` hacks [pourquoi pas une autre instruction d'affectation ': =' qui ne réattribue qu'une valeur donc 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 :(; btw: vous pouvez déboguer CoffeeScript à partir de Chrome en ajoutant la prise en charge des cartes sources; yeoman (npm install yeoman) peut vous aider vous écrivez un fichier de configuration gulp ou grunt pour CoffeeScript
  3. pas de typage statique optionnel (il faut attendre le prochain standard EcmaScript)
  4. besoin de bibliothèques tierces pour un système de modules
  5. pièges de syntaxe à prendre en compte: 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é
0
aoeu256