JavaScript est partout et à mon esprit gagne constamment de l'importance. La plupart des programmeurs conviendront que pendant que JavaScript est laid, son "territoire" sûr est impressionnant. Avec les capacités de HTML5 et la vitesse des navigateurs modernes Le déploiement d'une application via JavaScript est une option intéressante: elle est probablement aussi transversale que possible.
Le résultat naturel sont des compilateurs croisés. Le prédominant est probablement GWT, mais il existe plusieurs autres options là-bas. Mon préféré est Coffeescript puisqu'il ajoute une couche mince sur JavaScript et est beaucoup plus "légère" que par exemple GWT.
Il n'y a qu'une chose qui me dérangeait: bien que mon projet soit plutôt faible performance a toujours été un sujet important. Voici une citation
Le SDK GWT fournit un ensemble d'API et de widgets Core Java. Ceux-ci permettent Écrire des applications Ajax en Java, puis compiler la source à JavaScript très optimisé
CoffeScript optimisé aussi? Puisque CoffeScript semble faire de lourdes fonctionnalités javascript non communes, je crains de la comparaison de leurs performances.
Avez-vous de l'expérience avec des problèmes de vitesse liés au CoffeScript? Connaissez-vous une bonne comparaison de référence?
5 Réponses :
Cofféscript compile directement à JavaScript, ce qui signifie qu'il y a toujours un à un équivalent dans JS pour toute source de Cuffscript. Il n'y a rien de commun à ce sujet. Un gain de performance peut provoquer des choses optimisées par ex. Le fait que Coffescript stocke la longueur de la matrice dans une variable distincte dans A pour une boucle au lieu de la demander à chaque itération. Mais cela devrait également être une pratique courante dans JavaScript, elle n'est tout simplement pas appliquée par la langue elle-même.
Bonne réponse. Je suppose qu'il pourrait y avoir un gain de perfugé si le JS Coffeescript génère est plus intelligent que ce que le développeur aurait autrement ... ce que je devine n'est pas rare
Créer une nouvelle langue intégrant les meilleures pratiques est une bonne idée. Le problème que je vois, c'est quand il essaie de devenir trop fantaisie. Et il est logique que tout le monde sache pourquoi Coffescript génère le JS.
@Adamrakis Coffeescript en moyenne génère un pire JavaScript que les développeurs moyens peuvent écrire. Vous pouvez avoir de la chance et trouver CS génère un meilleur javascript pour les développeurs de merde, mais si vous avez des développeurs de merde, vous avez de plus gros problèmes.
@Raynos, pouvez-vous offrir un exemple? Peut-être que je suis un "développeur de merde", mais je trouve personnellement que le JS que CS génère d'être presque idéal. Des choses comme obtenir la longueur de la matrice une fois peuvent accélérer une performance minimale. Une compréhension de liste convertie en une boucle plutôt que d'un style fonctionnel de style fonctionne va être légèrement plus rapide et utilise moins de mémoire.
@LarrryMaccherone ne me trompe pas. Il a des macros utiles. Cependant, les gens devraient faire les mêmes optimisations et beaucoup plus comme Coffescript. Il se peut que ma norme pour "moyenne" soit trop élevée
@Raynos, je serais enclin à être d'accord avec vous. CS Mieux vaut bien mieux que de stocker des longueurs de réseau dans des variables plutôt que de les ré-accéder à chaque fois. C'est l'une des optimisations les plus élémentaires (comme allusion de Daft à)
@ Raynos / @ Adamrakis, je questionne la déclaration selon laquelle CS "génère pire JavaScript". J'aimerais voir un exemple où il génère pire. Une partie de l'époque, vous semblez dire que JS codé à la main peut être aussi bon si vous faites attention et que je suis d'accord avec. Ce que je ne vois pas de preuves pour cependant, est votre déclaration que le code généré par CS est pire.
@LarrryMaccherone Le système de classe est un bon exemple. La chaudière qu'il génère pourrait être mieux faite. Il génère généralement pire javascript car la lisibilité est médiocre. Cependant, il est difficile de dire qu'il génère un javascript moins efficace.
@RAYNOS La différence entre Coffeescript et JavaScript est que si vous avez écrit à Coffeescript, une nouvelle version de Coffescript pourrait réellement optimiser la manière dont il génère JavaScript. Si vous avez écrit directement dans JavaScript. Ensuite, vous êtes foutu de toute façon. Sans le code de réécriture, vous pouvez remettre un code plus rapide.
Cela est vrai pour JavaScript aussi. Googles V8 était une énorme amélioration des performances sur de nombreux autres moteurs JavaScript et continuera à s'améliorer. Mais vous n'avez pas eu à réécrire votre JavaScript pour travailler avec Google Chrome.
@DAFF n'est pas exactement vrai, à moins que le moteur JIT n'offre une meilleure optimisation des choses qu'il n'a pas été capable d'optimiser auparavant. Coffeescript pourrait reconstruire différemment pour créer du code qui sera optimisé efficacement par le moteur JIT. La différence est que Coffescript ne doit être dit que pour être reconstruit. Le JS doit être réécrit à la main pour faciliter la possibilité de l'optimiser le JIT.
Réponse courte: NO .
Coffeescript génère JavaScript, sa vitesse maximale éventuelle est donc égale à la vitesse de JavaScript. Mais pendant que vous pouvez optimiser le code JS à bas niveau (oui, il sonne ironique) et gagnez une certaine performance Boost - avec CoffeScript, vous ne pouvez pas faire cela.
Mais la vitesse du code ne devrait pas être votre préoccupation, lors du choix de CS sur JS, la différence est négligeable pour la plupart des tâches.
Toutes mes excuses pour ressusciter un vieil sujet, mais c'était me concernant aussi. J'ai décidé d'effectuer un petit test et l'un des tests de performance les plus simples que je connaisse est d'écrire des valeurs consécutives à une matrice, la mémoire est consommée de manière familière, car la matrice se développe et "pour" Les boucles "pour" sont assez courantes dans la vie réelle à considérer Pertinent.
Après quelques harengs rouges, je trouve la méthode la plus simple de Coffescript est la suivante: P>
badway = ->
a = []
for i in [1..1000000]
a[i] = i
return a
Pourquoi s'excuser pour une réponse intéressante. Je n'aurais pas attendu des différences qui grandissent. Bien sûr, on pourrait affirmer que l'ajout de tous les nombres de 0 à 1000000 à un tableau n'est pas un cas d'utilisation normal et que vous venez d'examiner un navigateur. Mais 78%!? C'est dur +1
Cela devrait être la réponse puisque l'auteur prend du temps pour mesurer et signaler le problème dans les JS générés du café. La seule raison d'utiliser le café est tout au sujet de la productivité.
Les fermetures sont souvent signalées comme un drain de performance en JavaScript. Coffeescript les utilise de manière approfondie, même là où ils ne seraient pas absolument nécessaires.
+1 Et la façon dont il gère les cours et le héritage dans les coulisses est assez horrible de la même manière que «indéfini» et non définie, la seconde non définie est convertie en 0 et comparé à NULL. Si quelqu'un a lu un livre JS, ils ne sont pas tous deux mauvais
Tout cela est tout à fait intervoyant et il y a une vérité, le script de café ne peut pas fonctionner plus rapidement que le javascript entièrement optimisé.
qui dit, puisque le script de café génère JavaScript. Il y a des moyens de le faire valoir la peine. Malheureusement, cela ne semble pas être le cas encore. P>
Permet de prendre l'exemple: p> Il compile à ceci avec un script de café 1.6.2 p> et le code fourni par clockworkeek est p> mais puisque le script de café cache la fonction dans une portée, nous devrait aussi faire cela pour JavaScript aussi. Nous ne voulons pas poluter la fenêtre droite? P> donc nous avons donc un code qui fait la même chose. Et puis nous aimerions réellement tester les deux versions quelques temps. p> script de café p> JS généré et que vous pouvez vous demander ce qui se passe là-bas ??? Il crée alors nous allons maintenant mettre à jour notre JavaScript. P> i code> et _i code> pour une raison quelconque. C'est clair pour moi de ces deux, un seul n'est nécessaire. P> time node test.js
real 0m5.363s
user 0m0.015s
sys 0m0.000s
Quel changement avez-vous apporté au code CoffeScript qui a généré le dernier bloc?
J'ai supprimé le i . Je n'ai pas changé le code CoffeScript. J'ai édité le code généré.
Bien. Au début, je pensais que vous présentaiez une solution pratique pour la fabrication de la puissance de CoffeScript Better Code. Je vois maintenant que vous avez changé cela, seulement pour faire valoir que le transpilateur CoffeScript est une couche qui peut toujours être toujours améliorée pour donner de plus en plus de code optimisé.
Oui, c'est le point, sauf que si le JIT était assez intelligent, cela ne devrait pas faire la différence. Ce qui signifie qu'il y a un lieu d'amélioration là-bas et là-bas.
C'est vrai. Votre réponse devrait être acceptée, car elle présente une conclusion beaucoup plus forte ainsi que la voie à y arriver. Bien fait.
Je veux ajouter quelque chose à la réponse de Lo'¯c Faure-Lacroix ...
Il semble que vous n'ayez imprimé que les temps d'un navigateur. Et btw "x.push (i)" n'est pas plus rapide que "x [i] = i" selon JSperf: https://jsperf.com/array-direct-asignment-vs-push/130
Quelle fonctionnalité non courante utilise-t-elle?
"Javascript lui-même est laid" -> faux.
Je suis d'accord avec Raynos: Le mauvais code est un mauvais code et peut être écrit dans n'importe quelle langue.