Journal Javascript Garden

Posté par  . Licence CC By‑SA.
Étiquettes :
18
29
mai
2012

Bondour Nal !

Ces derniers temps, j'ai du abandonner la sérénité et la bienfaisante rigueur de l'OCaml pour le Javascript. C'est un peu comme faire découvrir l'open bar a un ascète: ça rend fou et il y a un risque de coma.

Bref, je connaissais le Javascript, mais faut avouer que ça a pas mal évolué. Et pour mes travaux actuels, j'avais besoin de vraiment comprendre le Javascript (le this, le pourquoi du Namespace.Prototype, etc.).

Et donc, j'ai découvert JavaScript Garden qui explique de façon très claire et efficace quels sont les pièges du javascript, ses forces, ses différences de comportement par rapport a nos habitudes.

Il me manque plus qu'un moyen de détecter rapidement que j'ai créé une propriété a cause d'une typo au lieu de modifier l'existante…

  • # Sujet du commentaire

    Posté par  . Évalué à 10.

    http://wtfjs.com

    • [^] # Re: Sujet du commentaire

      Posté par  . Évalué à 10. Dernière modification le 29 mai 2012 à 13:47.

      l’ascète est tombé dans le coma je crois, quelque part vers

          ",,," == Array((null,'cool',false,NaN,4)); // true

  • # js of OCaml

    Posté par  . Évalué à 2.

    Pourquoi ne pas garder la rigueur bienfaisante du OCaml tout en faisant du javascript ?

    • [^] # Re: js of OCaml

      Posté par  . Évalué à 4.

      Parce que le code js de js_of_ocaml est illisible pour un humain, et que le javascript est imposé par le projet. Dommage. :)

  • # Google est ton amis

    Posté par  (site web personnel) . Évalué à 6.

    Il me manque plus qu'un moyen de détecter rapidement que j'ai créé une propriété a cause d'une typo au lieu de modifier l'existante…

    C'est peut-être pas tout à fait le plus rapide mais dans la collections d'outils JS de Google (Google closure tools) il y en a deux qui peuvent t'aider :

    • Linter : comme son nom l'indique il va valider / vérifier la tronche de ton code, les commentaires, toussa
    • Compiler : il faut bien comprendre que c'est un compilateur et non un minifieur. Bon ok, c'est un compilateur js -> js mais quand même, il a des choses bien puissantes comme la suppression de code mort, l'inlining de fonctions, etc. A double tranchant, nécessite un code propre, typé et documenté. Par contre, une fois que ton code est ok les gains sont réellement importants, il est facile de faire des applis complètes en moins de 200ko (bien moins). Pour la partie qui nous intéresse il permet aussi de relever certains erreurs.

    Et si tu veux le faire de manière assez sympa, regarder plovr, c'est plutôt bien fait et réellement pratique.

    C'est pas parfait, mais ça aide déjà pas mal.

    Ha oui, et n'oublie pas

    use strict;

  • # Tableaux associatifs

    Posté par  (site web personnel) . Évalué à 1. 

    var a = new Array();
a[0]="Meuh"; 
a["Plop"]="Pika";
alert(a.length);

    Cela donne 1;

    Et oui, le javascript n'a pas de tableaux associatifs. En fait a["plop"] c'est comme a.plop et en fait on est en train de faire référence à l'attribut plop de l'objet a.

    Donc en fait il faut mieux initialiser ainsi var a=new Object(); ou var a={};

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

    • [^] # Re: Tableaux associatifs

      Posté par  (site web personnel) . Évalué à 2.

      Donc en fait il faut mieux initialiser ainsi var a=new Object(); ou var a={};

      En général (faudrait que je retrouve exactement pourquoi, mais mon souvenir me dit que c'est une histoire de perf) on privilégie la deuxième notation. De la même manière on écrira var b = []; et non var b = new Array();

      Maintenant sur ton exemple j'ai pas bien compris le problème…
      En gros tu veux un tableau mais pas un tableau ?
      Si le problème c'est que length te renvois le nombre de cases du tableau, ben c'est normal (tu en utilises qu'une, celle référencée par 0). Après on peut chercher à argumenter sur le fait que length ne te retourne pas l'ensemble des propriétés mais c'est un peu normal, même sur un tableau ce serait déconnant (d'ailleurs length est une propriété et devrait donc être comptée. Bonjour le bordel)

      Donc oui, lorsque tu veux utiliser un tableau, ben tu fais un tableau. Et lorsque tu veux utiliser une map tu utilise un objet.

      • [^] # Re: Tableaux associatifs

        Posté par  (site web personnel) . Évalué à 2.

        Ce que je soulevais c'est qu'il ne faut pas croire qu'il y a des tableaux associatifs "clé -> valeur" en Javascript. Quand on associe une valeur à une clé on associe en fait une valeur à un attribut de l'objet. Et même si l'objet est un Array, il accepte tout de même d'autres attributs sans bronché (comme tout objet en Javascript, ce qui devient vite la fête du slip).

        Ce qui est aussi trompeur c'est la notation possible de la forme a["clé"]=valeur qui laisse à pense que les tableaux associatifs sont supportés.

        Émuler des tableaux associatifs avec des objets est aussi très mauvais niveau performance si on vaut parcourir les éléments rapidement et/ou régulièrement.

        L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

        • [^] # Re: Tableaux associatifs

          Posté par  . Évalué à 2.

          D'ailleurs que doit-on utiliser comme arrays associatifs ? Je ne trouve rien de tres probant sur internet…

        • [^] # Re: Tableaux associatifs

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 29 mai 2012 à 16:52.

          Mouais, tu joues sur les mots non ?
          A part les histoires de mauvaises performances pour les parcours d'éléments (si tu as des liens, ça m'intéresse), je ne vois pas pourquoi on ne pourrait pas considérer que JavaScript offre une structure de donnée de type tableau associatif (certes limité à un système de clefs sous forme de chaîne) par le biais des objets !

          • [^] # Re: Tableaux associatifs

            Posté par  . Évalué à 2.

            Le problème de performances vient du fait que pour accédé à une propriété tu peux te retrouve a cherché dans toute la chaine des prototypes.
            http://bonsaiden.github.com/JavaScript-Garden/#object.prototype

            • [^] # Re: Tableaux associatifs

              Posté par  (site web personnel) . Évalué à 4.

              Je sous-entendais "lorsqu'on utilise les objets comme des tableaux associatifs", c'est-à-dire qu'on part de var o = {}; et qu'on peuple cet objet avec des clefs/valeurs, comme on le ferait avec un map, un QMap etc.
              Je suis d'accord pour dire qu'il faut se prémunir de certains pièges, mais pour le gros du besoin, l'objet JavaScript répond assez bien, il me semble.

              • [^] # Re: Tableaux associatifs

                Posté par  . Évalué à 0.

                Ben il a raison : globalement ça va marcher, tu vas juste perdre l'intérêt de la table de hash pour finalement te (enfin, l'interprêteur js) palucher un truc qui ressemblera d'un point de vue algorithmique à une liste chaînée.

                • [^] # Re: Tableaux associatifs

                  Posté par  (site web personnel) . Évalué à 2.

                  Dans quels cas l'utilisation d'un objet js comme table de hash commence à poser problème ? je veux dire, je me sers de JavaScript pour faire des IHM web et j'utilise au grand max quelques centaines d'éléments de cette façon, si j'avais à gérer une grosse table de hachage pour une application qui doit gérer des dizaines de milliers, des millions d'éléments, effectivement, je commencerais à m'intéresser à l'implémentation en interne des propriétés des objets (qui doit dépendre des moteurs JavaScript) pour me tourner vers un outil plus approprié…

                • [^] # Re: Tableaux associatifs

                  Posté par  . Évalué à 2.

                  Pourquoi l'accès à une propriété d'un objet serait en O(n) ? D'ailleurs un test rapide avec une implémentation "récente" montre que le temps d'accès à une propriété dans un objet ne dépend pas du nombre de propriétés dans cet objet.

        • [^] # Re: Tableaux associatifs

          Posté par  . Évalué à 3.

          Et même si l'objet est un Array, il accepte tout de même d'autres attributs sans bronché (comme tout objet en Javascript, ce qui devient vite la fête du slip).

          C'est kiff kiff en python. Si tu veux être dans le vent tu dis que c'est un langage dynamique.

          Ce qui est aussi trompeur c'est la notation possible de la forme a["clé"]=valeur qui laisse à pense que les tableaux associatifs sont supportés.

          C'est il me semble le point le plus critiquable.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: undefined

      Posté par  (site web personnel) . Évalué à 5.

      En python, avant, on pouvait changer les valeurs de None, True, False. Ca permet de faire des trucs vraiment con du genre :

      False=1
      True=0
      None=42
      bool(True)
      0
      bool(False)
      1

      Je vous laisse imaginer le bordel qu'on pourrait mettre dans des programmes en jouant la-dessus.

      • [^] # Re: undefined

        Posté par  . Évalué à 4.

        En python, avant, on pouvait changer les valeurs de None, True, False.

        Quel pouvait bien être l'argument invoqué par celui qui a eu l'idée de proposer cela et/ou de l'implémenter ?!? O_o

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: undefined

            Posté par  . Évalué à 4.

            Ca n'explique pas cependant pourquoi ces variables sont modifiables ! En faire des constantes, c'était trop dur ?!?

          • [^] # Re: undefined

            Posté par  . Évalué à 5. Dernière modification le 30 mai 2012 à 18:38.

            En Python 2.7 :

            In [1]: None=42
  File "<ipython-input-1-6f95c4bd0942>", line 1
SyntaxError: cannot assign to None (<ipython-input-1-6f95c4bd0942>, line 1)


In [2]: del True
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
/Users/v/<ipython-input-2-01748e45753a> in <module>()
----> 1 del True

NameError: name 'True' is not defined

In [3]: True=42

In [4]: bool(True)==True
Out[4]: False

In [5]: del True

In [6]: bool(True)==True
Out[6]: True

            Édition : le True par défaut est dans __builtin__.True.

          • [^] # Re: undefined

            Posté par  . Évalué à 2.

            D'ailleurs en perl, il n'y a pas de mots clés "true" ou "false" et on survit très bien.

            Justement, il n'y a donc pas de piège. Tu sais que 1 est toujours vrai. Là le langage te donnait des éléments qui ne sont pas si fiables que ça.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Eloquent JavaScript

    Posté par  . Évalué à 5.

    Le livre libre et interactif "Eloquent JavaScript" de Marijn Haverbeke pourrait t'intéresser.

    S'il s'agit avant tout d'une introduction "généraliste" à la programmation, des aspects relativement pointus du langage y sont présentés. L'auteur est un inconditionnel de la programmation fonctionnelle et d'Haskell, cela devrait donc plaire à un développeur OCaml. De plus, les exemples de code sont faciles à tester grâce à un éditeur JavaScript intégré.

    Sa traduction en français est presque terminée.

  • # CoffeeScript

    Posté par  . Évalué à 4.

    Je te conseille fortement de regarder CoffeeScript.

    Il s'agit d'une très légère couche syntaxique au dessus de Javascript qui :

    • génère du Javascript lisible par l'être humain, à part deux trois constructions, tu as quasiment une correspondance 1 à 1 entre le Coffee et le JS
    • apporte les compréhensions de liste comme en python
    • supprime complètement les lourdeurs syntaxiques inhérentes au Javascript

    Et surtout :

    • Te protège des différents pièges du js, notamment les comparaisons avec les types qui font n'importe quoi.

    • [^] # Re: CoffeeScript

      Posté par  (site web personnel) . Évalué à 4.

      As-tu essayé les sources map de coffeescript ?
      Le problème de coffescript (ou tout équivalent qui compile en js) est encore et toujours le debug.
      Alors pour faire un petit script ça marche toujours, mais lorsqu'on parle d'applications de plusieurs dizaines de millier de lignes de code, c'est beaucoup beaucoup moins marrant.

      Maintenant il est vrai que les derniers tests que j'ai effectué avec coffeescript montrent un certain confort, par exemple ?.

      • [^] # Re: CoffeeScript

        Posté par  . Évalué à 3.

        Je retrouve souvent cet argument en discutant de Coffee. S'il est valide pour quasiment tout ce qui compile en js, ce n'est pas le cas pour Coffee. Je t'invite vraiment à regarder plus en détail ce qui est compilé. Tu découvriras que c'est quasiment le js que tu aurais écris toi même à la main en étant rigoureux.

        Pour faire un retour d'expérience, j'ai deux applications qui tournent avec des milliers de ligne de CoffeeScript et je n'ai jamais rencontré de problème au débug. Quand j'ai un truc qui foire, dans la console de chrome, je regarde la ligne, et je sais exactement en un coup d'oeil où c'est dans mon CoffeeScript. Nous sommes 4 à travailler sur cette base de code, dont un stagiaire et personne ne rencontre ce genre de problème. Il s'agit juste d'un tout petit effort mental, qui s'acquiert rapidement. La correspondance est, j'insiste, triviale à établir.

        Par contre, les gains sont énormes, tellement ça évite les pièges habituels :) sans même parler du confort de coder avec.

        • [^] # Re: CoffeeScript

          Posté par  (site web personnel) . Évalué à 2.

          Je comprend bien, mais c'est quand même quelque chose que je trouve vraiment important. Et le vrai problème est toujours dans le quasiment. Oui, dans quasiment tous les cas ça se passe bien. Mais il reste toujours des cas où c'est surement plus complexe.
          Je sais que les sourcesmap ont étés ajoutées, d'où la question.

          Question subsidiaire : tu compiles / minifie le code ? Si oui avec quoi ?
          Je rêve de pouvoir utiliser un closure compiler avec coffee, mais si certaines expérimentations ont étés faites je crois que c'est pas encore au niveau (ni peut-être même actif). Faut bien voir que le closure compiler est un monstre par rapport aux minifiers classiques) (dans le cas présent j'ai 710ko de sources - lib comprises - qui sont compilées en 83ko et 29ko une fois gzipé soit mine de rien un facteur 8 par la compilation et 24 avec gzip)

          • [^] # Re: CoffeeScript

            Posté par  . Évalué à 2.

            En effet, je n'ai pas détaillé le quasiment. Le cas le plus complexe que tu peux avoir c'est les => qui sont transformés en apply. Le switch case peut potentiellement devenir dégeulasse de mémoire. Mais rien qui s'approche de la soupe que tu peux obtenir avec Pyjama.

            Conclusion, c'est quasiment tout le temps nickel, sauf parfois où c'est juste un peu moche mais jamais trop complexe à gérer.

            Quand je debug, c'est généralement tout connement un truc à telle ligne, je regarde, je reconnais direct le bout de coffee en question, à la ligne près ou au pire, à la fonction vu que ça c'est pas transformé. Cela ne m'a jamais posé de problèmes.

            Mes assets passe à travers https://github.com/sstephenson/sprockets ça concatène juste bêtement vu que j'ai pas besoin d'obfu en soit.

            Pour Closure Compiler, j'ai googlé vite fait et effectivement cela ne semble pas parfait, mais ça marche vu que dans l'absolu du coffee c'est juste du JS. Après, je ne m'en sers pas donc je peux pas trop t'aider là dessus.

            Le seul truc qui peut s'avérer chiant c'est d'incorporer Coffee dans le workflow de ton projet si ton framework le gère pas nativement. Rails c'est transparent, je suis certain que pour Django on doit trouver la même chose.

            HS : C'est bien la première fois que je me fais moinsser sur Linuxfr (ok je poste peu), à part un désaccord (ce pour quoi moinsser n'est pas la réponse appropriée), j'ai du mal à voir ce qui peut expliquer ça. L'auteur peut il se manifester, que je comprenne ?

            • [^] # Re: CoffeeScript

              Posté par  (site web personnel) . Évalué à 2.

              ça concatène juste bêtement vu que j'ai pas besoin d'obfu en soit.

              Ha mais en fait la problématique n'est pas au niveau obfuscation mais réellement performances.
              Si je reprend mon exemple précédent :

              • Sources concaténées avec suppression des commentaires et lignes vides : 710ko
              • La même chose mais avec suppression des retours chariots (donc pas de pretty print) : 630ko
              • Compilation simple (minification en gros) : 340ko
              • Compilation avancée (beaucoup plus poussée, suppression de code mort, inlining, donc également des améliorations de performances) : 83ko
              • La même chose minifiée : 29ko

              Le gain est vraiment important à plusieurs niveaux :

              • gain évident en bande passante, aussi bien côté serveur (ça coûte cher la bande passante) que côté client (ça rame)
              • chargement plus rapide (il est plus rapide de décompresser et lire 29ko que 700ko)
              • exécution plus rapide (inlining entre autre)

              Mais c'est loin d'une concaténation. Et pour faire tout ceci, notamment l'inlining, il faut tout typer, même ce qui ne l'est pas en javascript de base. https://developers.google.com/closure/compiler/docs/js-for-compiler donne une idée, mon code contient pas mal de cast sous forme de commentaires, par exemple :

              /**
 * Click item.
 * @param {goog.events.Event} e Click event.
 * @private
 */
plop.onClick_ = function(e) {
  var el = /** @type {Element} */ (e.target);
  // ....
};

/**
 * @typedef {{id: number, name: string, description: ?string}}
 */
plop.myStruct;

/**
 * Print names.
 * @param {Array.<plop.myStruct>} elts Elements.
 * @private
 */
plop.printNames_ = function(elts) {
  goog.array.forEach(elts, function(/** @type plop.myStruct */ elt) {
    this.log(elt.name);
  }, this);
};

              Le truc c'est donc surtout que ça utilise intensivement les tags jsdoc pour le faire. Et ça me semble peut faisable malheureusement…

              Mais par contre, une fois qu'on code de cette manière, on arrive à avoir un code beaucoup plus proche d'un code classique tel qu'on aurait en java ou autre puisqu'on rajoute les problèmes de typage entre autre. Et le gain, la qualité et la fiabilité s'en ressent réellement.

              Et d'ailleurs je conseil à quiconque faisant du dev web de tenter de faire passer leur code dans closure compiler et le linter. En général ça rigole beaucoup moins. Par contre une fois l'habitude prise la programmation javascript devient beaucoup plus agréable.

              Quand je debug, c'est généralement tout connement un truc à telle ligne, je regarde, je reconnais direct le bout de coffee en question, à la ligne près ou au pire, à la fonction vu que ça c'est pas transformé. Cela ne m'a jamais posé de problèmes.

              Et be, je dois pas avoir de chance alors. Car j'ai quand même régulièrement des problèmes bien plus complexes en JS (et je parle pas du mauvais typage qui renomme différemment mes objets à deux endroits différents…)

              HS :

              Tout ça pour qu'on te plusse… :-) (nan mais le truc c'est qu'il faut pas (peu) y faire attention)

              • [^] # Re: CoffeeScript

                Posté par  . Évalué à 2.

                Effectivement si typer tes fonctions et des paramètres est faisable coté Coffee avec les mêmes commentaires, tu pourras pas typer toutes les vars intérmédiaires de coffee ( genre les splats ou ranges par exemple ).

                Plus je comprends ton cas de figure, plus je pense que Coffee est pas adapté. Ca fait peut être trop de "bruit" par rapport à du js sur autant de code d'un coup.

                Pour ce qui est des bugs potentiels et du debug, tu dois en effet avoir probablement une base de code bien plus complexe que nous, surtout si tu as autant de JS. Dans ce contexte là, je n'ai pas d'avis du coup.

                Tu pourrais décrire un exemple de bug que tu rencontres ? Je suis curieux de voir si vraiment Coffee complexifierait le truc ou pas. C'est sûr dans tous les cas que ça décalerait énormément les numéros de lignes mais de toute façon tu t'en sers peu vu que tu te repères à la fonction plutôt qu'à la ligne, ce qui est beaucoup plus simple.

                PS : thanks pour l'exemple sur le closure compiler, c'est plus intéressant que ce que je pensais :)

                HS : je vais avoir l'air naif, mais j'y avais même pas pensé :) j'étais juste un peu surpris de voir mon comment plié comme un vulgaire spam sur reddit :) Thanks du coup :)

                • [^] # Re: CoffeeScript

                  Posté par  (site web personnel) . Évalué à 2.

                  Effectivement si typer tes fonctions et des paramètres est faisable coté Coffee avec les mêmes commentaires, tu pourras pas typer toutes les vars intérmédiaires de coffee ( genre les splats ou ranges par exemple ).

                  En fait, rajouter ça dans coffee serait à mon avis plutôt sympa :)

                  PS : thanks pour l'exemple sur le closure compiler, c'est plus intéressant que ce que je pensais :)

                  De rien :) En fait c'est beaucoup plus intéressant que ce que la majorité des gens pensent. Mais il est plutôt méconnu donc les gens ne savent pas.

                  tu dois en effet avoir probablement une base de code bien plus complexe que nous

                  Ca j'en sais trop rien. L'un des projets sur lequel je bosse fait (sans compter les libs mais en prenant les sources commentées) de l'ordre de 40 000 loc.

                  Tu pourrais décrire un exemple de bug que tu rencontres ? Je suis curieux de voir si vraiment Coffee complexifierait le truc ou pas.

                  En fait le problème est justement lorsque tu ne sais pas exactement où est le problème.
                  Imaginons simplement qu'un template est mal rendu (mauvaise valeur).
                  Mais le serveur a bien répondu.
                  Hors entre les deux, il y a pas mal de bordel, du parse, de la transformation, etc.
                  Ha oui, et avec des évènements au milieu donc tu peux difficilement remonter la stack trace. Donc en général tu vas lire le code que tu as écris pour comprendre d'où vient le problème. Et dans ce cas il faut alors lire la "traduction" coffee en js pour trouver l'équivalent js. Là où un sourcemap permettrait, je suppose, de faire le lien plus facilement.
                  Bon, je sais pas si c'est assez clair, tu me dira ;)

                  • [^] # Re: CoffeeScript

                    Posté par  . Évalué à 1.

                    Oui c'est clair :)

                    • la stacktrace est la même quoi qu'il arrive avec Coffee, donc aucune difficulté supplémentaire
                    • lire la traduction de Coffee :

                    Si on regarde les traductions : 

                    eat food for food in ['toast', 'cheese', 'wine']

                    Devient :

                    var courses, dish, food, foods, i, _i, _j, _k, _len, _len1, _len2, _ref;

_ref = ['toast', 'cheese', 'wine'];
for (_i = 0, _len = _ref.length; _i < _len; _i++) {
  food = _ref[_i];
  eat(food);
}

                    Pour les trucs simples, c'est juste trivial : 

                    if this.studyingEconomics
  buy()  while supply > demand
  sell() until supply > demand

                    Devient : 

                    var lyrics, num;

if (this.studyingEconomics) {
  while (supply > demand) {
    buy();
  }
  while (!(supply > demand)) {
    sell();
  }
}

                    Mais cela ne va pas plus loin en terme de complexité. Peut importe ce que tu écris, ce n'est jamais à un ordre de complexité supérieur à celui-ci.

                    Bref j'en arrive à me dire que c'est une question subjective, je pensais que tes problèmes étaient plus complexe que cela, du genre de ce que tu peux trouver dans Jquery (encore que si j'avais à choisir, j'implémenterais en Coffee plutôt qu'en JS).

                    Pour ma part, en toute honnêteté je dois pas mettre plus de 5 secondes à trouver le coffee correspondant. Après, mon code ressemble pour deux gouttes d'eau à du Ruby, au sens où je découpe bien plus que du code JS habituel où c'est généralement la fête des callbacks dans tous les sens, cela doit peser dans la balance.

                    Après clairement, avec une source map, ce sera juste transparent et rendra l'adoption plus aisée.

        • [^] # Re: CoffeeScript

          Posté par  . Évalué à 2.

          Je retrouve souvent cet argument en discutant de Coffee. S'il est valide pour quasiment tout ce qui compile en js, ce n'est pas le cas pour Coffee. Je t'invite vraiment à regarder plus en détail ce qui est compilé. Tu découvriras que c'est quasiment le js que tu aurais écris toi même à la main en étant rigoureux.

          Donc il faut déjà bien connaître le JS pour toucher à ces langages ? Ça limite beaucoup leur intérêt.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: CoffeeScript

            Posté par  . Évalué à 2.

            Un minimum oui. Après tu n'as pas du tout besoin d'être un expert pour être à l'aise. C'est juste du javascript élégant et moderne. C'est sur qu'après si tu ne piges pas le javascript au point de paniquer devant une closure, c'est pas fait pour toi. Mais bon si tu en es là, c'est que tu es un débutant auquel cas autant éviter de rajouter une couche.

            L'intérêt est justement d'avoir quelque chose de facile d'accès pour quelqu'un qui connait le js, pas d'apprendre quelque chose de nouveau et donc pas forcément évident à appréhender ( cf Clojure-script ).

            Prenons le problème dans l'autre sens. Si pour coder en Coffee tu n'as pas besoin de connaitre JS, ça sous entend que tu n'utiliseras pas de librairies en Javascript. Adieu JQuery, Backbone et autres consorts. Tu n'utiliseras que des trucs en Coffe ou rewrappant du Js en coffee. Donc ça limite énormément l'écosystème tout comme l'adoption. Finalement, tu désignes avec ton affirmation que Clojure script a plus d'intérêt que Coffee.
            Au sens théorique peut être, dans la pratique tu vois bien pourtant que c'est limité comme intérêt à l'heure actuelle. Oui tu peux faire du JS avec du clojure script sans piger une seule ligne de js. Mais niveau productivité tu es dans la merde et tu es dans une niche : l'intérêt est bien plus limité encore.

            En gros, si tu connais js, tu peux pondre du Coffee. C'est un outil destiné aux devs web qui ont une base suffisante de js, il est là pour résoudre un problème simple, écrire du Javascript c'est chiant au point d'avoir besoin d'outils externes, genre JSLint. Là du coup, tu écris dans un truc simple à comprendre pour un dev web compétent et un minimum expérimenté. L'intérêt pour cette population à la taille conséquente est très net.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.