ç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 :
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 CrEv (site web personnel) . En réponse au journal Javascript Garden. Évalué à 2.
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 :
Le gain est vraiment important à plusieurs niveaux :
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 :
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.
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…)
Tout ça pour qu'on te plusse… :-) (nan mais le truc c'est qu'il faut pas (peu) y faire attention)