Discussion :

[LSMetag]

Dart 1.1 : jusqu'à 25% plus performant que la version 1.0

De meilleures performances, plus de fonctionnalités, et des outils améliorés caractérisent la version 1.1 de Dart sortie il y a quelques jours. 2 mois seulement après la sortie de la version 1.0, cette nouvelle version offre un ensemble de mises à jour rendant le développement d'applications plus facile et rapide pour ses utilisateurs.



Le JavaScript généré par Dart continue de briller. Les performances sur le benchmark "Richard" (simulation d'un noyau d'OS, se focalisant sur la rapidité d'accès aux propriétés et méthodes/fonctions d'objets) sont 25% supérieures à la version 1.0, rendant la vitesse d'exécution comparable à celle du JavaScript.
Les performances sur le BenchMark FluidMotion (solveur d'équations de Navier-Stokes, utilisées pour la simulation des fluides) ont doublé depuis Novembre dernier.
Dart2JS génère maintenant du JavaScript aussi performant (sinon plus) que son équivalent idiomatique, compatible tous navigateurs (sauf IE 8 et inférieurs).

Alors que Dart retient beaucoup l'attention pour des applications sur navigateurs Web, il commence à susciter l'intérêt également du côté des solutions serveur. Cette nouvelle version offre un certain nombre d'améliorations à la partie serveur du langage, comme le support des gros fichiers, de la copie de fichiers, du traitement du signal ou encore l'information pour terminaux (aéroports par exemple). En guise de nouveautés, le support de l'UDP, pour par exemple permettre le développement d'applications streaming plus performantes.

Quand à l'éditeur (Dart Editor), des améliorations diverses sont là pour améliorer la productivité (débuggage amélioré, meilleure auto-complétion, plus d'infobulles) et ses performances globales ainsi que celles du compilateur ont été améliorées.

Pour plus d'informations, vous pouvez consulter les spécifications du langage mises à jours.

Télécharger Dart

Source : http://dartosphere.org/

Et vous ?

Que pensez-vous du langage Dart ?
L'utilisez-vous ? Dans quels domaines et pour quelles applications ?

[Invité]

Dart2JS génère maintenant du JavaScript aussi performant (sinon plus) que son équivalent idiomatique

c'est comme comparer deux voiture de meme type meme moteur meme poid ....etc et l'une serait plus rapide que l'autre ?

[Bovino]

Bah... si tous les utilisateurs de JavaScript connaissaient un minimum le langage, ça se saurait... du coup, oui, je crois que dans beaucoup de cas, un code créé par un développeur non spécialiste de JavaScript (malheureusement, j'ai l'impression que c'est la grande majorité) sera moins performant. Sans parler des snippet que certaines plateformes intègrent pour "faciliter" le développement à l'intention de ceux qui ne connaissent pas JavaScript...

[Invité]

dart n'empechera pas ces soucis c'est une histoire sans fin

[LSMetag]

Disons simplement que Dart génère du Javascript de bonne qualité, notamment grâce à toute une communauté qui conseille les développeurs du langage à ce niveau.

De plus, certaines fonctions "primitives" de Javascript (par exemple un simple getElementById) peuvent être améliorées en utilisant des moyens détournés.

Je pense qu'hormis pour un expert Javascript, le JS généré sera toujours plus performant que celui écrit par un développeur non spécialisé Javascript.

On a des Frameworks comme JQuery qui simplifient grandement la programmation côté client. Par contre, le Javascript généré est moins performant.

Donc je pense que ça peut être une alternative intéressante à ces Frameworks, voire même à Javascript pour beaucoup.

[guillaume07]

Quel intérêt d'utiliser javascript côté serveur plutôt que du c#/java/c++ ?

[Zefling]

On a des Frameworks comme JQuery qui simplifient grandement la programmation côté client. Par contre, le Javascript généré est moins performant.

J'aime même eu des cas où c'était affreusement lent et je me serais bien passé de Jquery.

Je me demande s'il est intéressant d'utiliser Dart pour des petites trucs : genres moins de 10 lignes en JS. Il faudrait que j'essaie, mais comme ça ne fonctionne que sous Chrome ça ne me motive pas trop...

[Mr_Exal]

Quel intérêt d'utiliser javascript côté serveur plutôt que du c#/java/c++ ?

Si chaque équipe qui est spécialisée dans son langage est aussi bonnes l'une que l'autre aucun.

c'est comme comparer deux voiture de meme type meme moteur meme poid ....etc et l'une serait plus rapide que l'autre ?

Sauf que d'un côté tu as une voiture construite à la main par un bricoleur du dimanche en manque de sexe qui fait de la construction pour passer sa frustration et de l'autre une voiture montée de toutes pièces par un automate.

[Uther]

Bah... si tous les utilisateurs de JavaScript connaissaient un minimum le langage, ça se saurait... du coup, oui, je crois que dans beaucoup de cas, un code créé par un développeur non spécialiste de JavaScript (malheureusement, j'ai l'impression que c'est la grande majorité) sera moins performant.

En fait c'est plutôt le contraire.

Le Javascript est surtout lent car c'est un langage de script avec une vision haut niveau. Il est pensé pour la facilité de développement avec des fonctionnalités de haut niveau qui simplifient le développement mais qui ont un cout (typage dynamique, GC, ...) donc un code Javascript bien pensé pour utiliser proprement les fonctionnalités du langage est paradoxalement plus lent.

L'avantage du compilateur c'est qu'il génère un code Javascript sale mais optimisé pour éviter autant que possible le haut niveau(un peu comme ce que fais Mozilla avec emscriptem/asm.js) ce que les VM sauront mieux optimiser.

Quel intérêt d'utiliser javascript côté serveur plutôt que du c#/java/c++ ?

Je dirais clairement la simplicité, surtout par rapport à C++. Je suis personnellement un adepte du typage statique, mais quand on veut aller vite il faut reconnaitre que le Javascript peut être efficace a condition de bien le maitriser.

Je me demande s'il est intéressant d'utiliser Dart pour des petites trucs : genres moins de 10 lignes en JS. Il faudrait que j'essaie, mais comme ça ne fonctionne que sous Chrome ça ne me motive pas trop...

Dart ne fonctionne nativement qu'avec Chrome, mais la compilation en JavaScript permet de le faire fonctionner avec n'importe quel navigateur.

[LSMetag]

J'aime même eu des cas où c'était affreusement lent et je me serais bien passé de Jquery.

Je me demande s'il est intéressant d'utiliser Dart pour des petites trucs : genres moins de 10 lignes en JS. Il faudrait que j'essaie, mais comme ça ne fonctionne que sous Chrome ça ne me motive pas trop...

Dart est utilisable sur TOUT NAVIGATEUR. Mais, mis à part pour Chrome, il faut utiliser un outil du SDK (Dart2JS) pour générer du Javascript assez universel.

Sur cette news, je me suis justement focalisé sur Dart2JS. Et ce qu'on voit, c'est que ce Javascript généré se révèle très performant.

C'est la VM Dart (qui interprète le Dart pur) qui pour le moment ne fonctionne que sous Chrome ou en ligne de commandes. Donc pour le moment, je considère Dart comme un moyen d'obtenir du bon Javascript avec moins de peine, et la VM est surtout valable côté serveur, ou une cerise sur le gâteau pour les utilisateurs de Chrome.

[LSMetag]

En fait c'est plutôt le contraire.

Le Javascript est surtout lent car c'est un langage de script avec une vision haut niveau. Il est pensé pour la facilité de développement avec des fonctionnalités de haut niveau qui simplifient le développement mais qui ont un cout (typage dynamique, GC, ...) donc un code Javascript bien pensé pour utiliser proprement les fonctionnalités du langage est paradoxalement plus lent.

L'avantage du compilateur c'est qu'il génère un code Javascript sale mais optimisé pour éviter autant que possible le haut niveau(un peu comme ce que fais Mozilla avec emscriptem/asm.js) ce que les VM sauront mieux optimiser.

Tu n'as pas forcément tort. Mais ici, ce n'est pas grave puisque le code qui est maintenu, c'est le Dart (qui se doit d'être propre), pas le JS sale généré. Bien sûr, à condition que la génération en JS ne provoque pas de bugs.

Je dirais clairement la simplicité, surtout par rapport à C++. Je suis personnellement un adepte du typage statique, mais quand on veut aller vite il faut reconnaitre que le Javascript peut être efficace a condition de bien le maitriser.

Tout dépend des développeurs en fait. Si tu as une équipe J2EE moyennement compétente et une équipe JS qui déchire, tu auras tendance à vouloir tout uniformiser en JS, si l'équipe JS est assez nombreuse, et à virer l'équipe J2EE.

Après ce sont les qualités des technos qui jouent



Cette image parle d'elle même. Ca date un peu donc l'écart doit s'être creusé, mais par exemple on voit Dart dépasser Java en terme de performances (sur le test DeltaBlue (POO)).

[la.lune]

Je dirais clairement la simplicité, surtout par rapport à C++. Je suis personnellement un adepte du typage statique, mais quand on veut aller vite il faut reconnaitre que le Javascript peut être efficace a condition de bien le maitriser.
.

C'est là, où je vois aussi l’intérêt de Dart, c'est qu'il joue les deux à la fois, un typage fort mais optionnel. Du coup tu peux te retrouver là où tu as besoin de typer statiquement mais parfois ça sert à rien tu va un peu plus vite avec du typage dynamique.

[xelab]

un typage fort mais optionnel.

Suis-je le seul à penser que c'est la porte ouverte au n'importe quoi? Pour moi c'est soit l'un soit l'autre, sinon on a les inconvénients des deux...

[Mr_Exal]

Suis-je le seul à penser que c'est la porte ouverte au n'importe quoi? Pour moi c'est soit l'un soit l'autre, sinon on a les inconvénients des deux...

Je suis aussi de ton avis. De toute façon un typage dynamique + une personne qui s'en fout = catastrophe.

[SylvainPV]

Suis-je le seul à penser que c'est la porte ouverte au n'importe quoi? Pour moi c'est soit l'un soit l'autre, sinon on a les inconvénients des deux...

J'aurais dit l'inverse, on a les avantages des deux: le typage fort est gage de performance et de stabilité, on peut donc l'appliquer sur les parties "critiques" du code, tandis que le non-typage permet de simplifier certaines portions de code avec les cast implicites. Vu que l'on arrivera pas à mettre tous les développeurs d'accord (je suis moi-même partagé sur le sujet), donner le choix me semble être un bon compromis.