IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Dart : l'alternatif à JavaScript de Google prêt pour la conquête du Web
Dart 1.0 serait de 130 % plus rapide que du JavaScript idiomatique sur V8

Le , par Hinault Romaric
167 commentaires

208PARTAGES

11  0 
Dart : l’alternative de Google à JavaScript prête pour la conquête du Web
Dart 1.0 serait 130 % plus rapide que du JavaScript idiomatique sur V8

Dart est prêt à entrer en production pour les développeurs Web.

Près de deux ans après avoir devoilé Dart, le langage alternatif de Google à JavaScript, le géant de la recherche publie la version 1.0 de Dart et de son SDK.

Pour rappel, Dart est un langage de programmation structuré pour le Web. L’objectif inavoué de Google avec ce langage est de mettre JavaScript à la retraite, en proposant un langage qui offre la même flexibilité, mais qui se distingue par son typage fort et optionnel.

Le SDK 1.0 de Dart inclut tout ce dont les développeurs ont besoin pour écrire des applications Web structurées : un langage de programmation simple et puissant, des outils robustes et des bibliothèques complètes.

Dart SDK intègre Dart Editor, un environnement de développement pour Dart, présenté comme « léger, mais puissant », par Google. Il dispose de la complétion de code, du refactoring, d'un débogueur, de conseils et avertissements, etc.

Dart s'exécute soit sur une machine virtuelle native du côté serveur, soit sur un moteur JavaScript classique à l'aide du compilateur dart2js, qui convertit le code en JavaScript compatible. Google met à la disposition des utilisateurs Dartium, une version personnalisée de Chrome disposant de la machine virtuelle Dart.

Selon Google, les performances du JavaScript généré ont été considérablement améliorées, fournissant même des résultats meilleurs que ceux du JavaScript idiomatique. Les performances de la VM seraient désormais de 42 % à 130 % meilleures que du JavaScript idiomatique sur le moteur V8.


Le SDK de Dart dispose également d’un gestionnaire de packages baptisé « Pub », qui intègre déjà plus de 500 packages. Les développeurs Dart peuvent utiliser leurs bibliothèques JavaScript préférées grâce à la fonctionnalité de compatibilité « Dart-JavaScript interop ».

D’après Google, les entreprises comme Adobe, drone.io et JetBrains ont déjà commencé à ajouter le support de Dart à leurs outils de développement.

Télécharger le SDK Dart

Télécharger Chrome avec la VM Dart

Source : Google

Et vous ?

Que pensez-vous du langage Dart ? Allez-vous l'utiliser ?

Dart représente-t-il une menace sérieuse pour JavaScript ?

Y'a-t-il encore une place pour un nouveau langage de programmation pour le Web ?

Dans quels domaines et pour quelles applications ?
Vous avez lu gratuitement 610 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

167 commentaires
Commenter Signaler un problème
stailer
Avatar de stailer
Membre chevronné https://www.developpez.com
Le 15/11/2013 à 11:22
Je suis désolé mais document.getElementById() c'est quand-même plus compréhensible que $("#";
Quand tu t'en seras tapé 50 dans la journée de : document.getElementById("mid" tu vois vite l'intérêt de $("#mid".
13  3 
LSMetag
Avatar de LSMetag
Expert confirmé https://www.developpez.com
Le 18/11/2013 à 16:18
Citation Envoyé par rebolon Voir le message
On peut ne pas aimer js, mais on peut aussi éviter d'écrire des bêtises. Son implémentation repose sur Ecmascript. Ecmascript n'est pas là pour faire du remplissage de papier, c'est une norme, versionnée, sur laquelle repose les différentes versions de Javascript. Combien de langage peuvent se pré-valoir d'être normé ? Le problème de JS vient des interpréteurs intégrés dans les navigateurs, et surtout de l'historique lié à IE6 (merci Microsoft, au moins vouis avez retenu la leçon avec IE10/11)
Jquery n'est pas du js non plus et si les gens se formaient correctement au JS on aurait moins de soucis. Ca ne sert à rien d'utiliser systématiquement $() alors que document.querySelector/All fait pareil (à condition que sa cible d'utilisateur repose sur des navigateurs récents, mais pas tant que ça)

Typescript n'est pas un langage, mais tout comme coffeescript, une surcouche permettant d'écrire du code à compiler en js avant la mep (de manière manuelle ou auto). Ils ont leur propre implémentation d'un modèle objet sous Javascript, à chacun ses particularités.

Je ne suis pas contre Dart, j'aime ce qui est nouveau, mais quid de Dart sous FF, Opera, IE, ou du mobile ? Comme le dit Ugo-sansH il faut que la VM soit développée pour chaque navigateur dans chaque version d'OS. C'est pas gagné et du coup en attendant il faut dans tous les cas compiler en js pour être sur que ça marche partout, c'est dommage. On se retrouve alors avec une énième surcouche comme type/coffee script
On est d'accord sur le fait que JS soit normé. Et encore, Microsoft a créé son JScript avec sa propre norme.
Le problème, c'est qu'on se retrouve avec les mêmes soucis que ce qu'on peut constater avec le W3C. 10 ans pour chaque version de la norme (je ne parle pas des sous-version qui n'ajoutent presque rien), donc quelque chose qui quelque part n'est pas très propice à l'innovation ou la mode du moment.
Un autre problème dont vous avez parlé, le non respect des normes par chaque navigateur pendant un certain nombre d'années, qui en ont dégouté pas mal du JS.

Les Fans du paradigme objet et du compilé dont je fais partie n'apprécient pas la plupart du temps Javascript. Car contrairement aux langages compilés, on a rien qui nous dit avant l'exécution qu'il y a une erreur. On n'a aucun garde fou qui nous dit "ça va donner ça si vous le mettez dans cette variable" dont le type et la conversion sont implicites. Et à l'exécution, souvent l'erreur est représentée par la non exécution de la totalité (ou d'une partie quand on est chanceux) du script, avec juste un point d'exclamation dans la console et un message d'erreur ne correspondant souvent pas du tout au problème. Difficile également de parcourir le code Javascript pas à pas pour trouver l'erreur, sauf avec des "Alert". Ajoutez à ça les différentes interprétations des navigateurs...

Donc je maintiens qu'il faut être pratiquement expert en JS pour maîtriser et vraiment l'apprécier à sa juste valeur. On n'a pas d'IDE pour nous aider (ou si peu). Les problèmes rencontrés ne sont jamais typiques et résolvables facilement à l'aide de forums. A l'aide de Frameworks comme JQuery, on obtient au final une syntaxe moins verbeuse, un même résultat quel que soit le navigateur, et certaines briques déjà toutes faites.
Les experts en Javascript ça ne court pas les rues, surtout quand on leur demande d'être en même temps experts en J2EE ou .NET.

Ces Framework et le Dart2JS sont moins performants que du natif, mais ils permettent aux développeurs de niveau au moins intermédiaire d'être productifs et de ne pas plancher une demi-journée pour débugguer le moindre petit script. Et je ne parle même pas de la maintenabilité.

Quelque part ça m'est égal qu'on doive compiler Dart en JS. Au contraire, si ça permet de valoriser JS. Ce qui compte c'est que la conversion soit vraiment fiable. Les performances de Dart2JS sont tout à fait honorables d'ailleurs.
Donc la VM pour moi, c'est la cerise sur le gâteau.

Citation Envoyé par Driktheviking Voir le message
Ce que je trouve étrange c'est qu'il n'y est aucun plugin navigateur permettant de disposer de la Machine Virtuelle sous FF ou Chrome. A moins que je ne l'ai tout simplement pas trouvé ?
Je suis prêt à parier que c'est purement commercial.

Vous avez vu comment Google abuse pour imposer Chrome ? Il est souvent installé avec d'autres logiciels si on ne prend pas soin de décocher la petite case peu visible, on a des pubs à la TV, dans la rue,...

J'ai vu aussi que la VM était toujours en développement.

Firefox est open source et ne va pas facilement faire confiance à un big brother comme Google. On voit ce qui s'est passé avec le h264. Au mieux, la VM, créée par Google ou par un développeur lambda en licence open source, sera téléchargeable et traitée comme le plugin Flash ou Java.

Microsoft est, tout comme Google, une société à but lucratif. Et ce n'est pas du tout le grand amour entre les 2.

Même chose pour Apple avec Safari. Apple étant encore plus fermé et big brother que Microsoft ou Google.
8  0 
sekaijin
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 24/11/2013 à 12:43
J'avoue ne pas comprendre pas mal de réflexion

Tout se passe comme si on utilisait C++ en écrivant encore du C des années 70.
Et, on trouverait C++ vieillot.

JS est fait de deux choses.
la première c'est le langage, la deuxième c'est l'interaction avec le DOM

La première est une implémentation de EcmaScript et n'a rien à envier à d'autres langages. On peut toujours discuter des avantages du fortement type face au faiblement typé. Du typage statique face au typage dynamique. Les deux ont leurs avantages. EcmaScript est un langage à Objet (pas un langage à Classe)
Et toutes les notions d'héritage et polymorphismes sont présentes. Ce n'est pas parce que les développeurs écrivent du JS purement fonctionnel et avec des variables globales que le langage n'a pas ces capacités.

La deuxième relève du W3C l'api DOM est le standard pour les interactions entre le DOM et le langage. Là encore l'API peut être critiquable, mais elle a le mérite d'exister. Alors oui on voit des Lib comme JQuery qui propose une autre API avec le DOM. Et là encore, on voit bien trop souvent un mauvais usage de l'API. Qui est en fait une approche historique. On peut continuer à passer son temps à rechercher dans le DOM des éléments à manipuler ou utiliser pleinement les capacités de l'API DOM et du langage. Je constate que l’on continue à privilégier l'approche d'y a 10 ans, époque ou le moteur HTML était beaucoup plus performant que JS/DOM. Or aujourd'hui, ce n'est plus le cas. Là encore, on fait du C avec C++.

Je comprends tout de même l'arrivée de Dart. Le couple EcmaScript/DOM est né pour faire du Script sur le web (côté serveur). Tout comme on a le Bash et autre Shell script. Aujourd'hui lorsqu'on fait un Shell script on est bien content d'avoir un interprète, un langage dynamiquement typé, et possédant quelque structure de base. Mais on ne développe pas d'appli lourde avec. Pour ça on passe à C++, Java, etc. ce qui se passe aujourd'hui avec JS c'est qu'on veut continuer à faire du Scripting, mais aussi développer des applis avec. Lorsqu'on fait un script, on a besoin de quelques objets créés à la volée, détruits de même et rarement des structures très complexes. Alors que lorsqu'on développe une appli lourde c'est plutôt le contraire. Dart est pour moi un peu comme python ou Perl. Il tente de se situer entre le scripting type Bash et le codding genre C++. et s'il apparait aujourd'hui c'est qu'il y a un réel besoin.

Quant à remplacer le JS, je n'y crois pas du tout. Tout comme avec le Shell, on aura toujours besoin d'écrire un petit script pour ceci ou cela et on ne voudra pas mettre l'artillerie lourde pour ça.

La question, que l'on peut se poser, c'est : que manque-t-il à EcmaScript aujourd'hui ? Pour moi la réponse est simple. EcmaScript c'est comme C++ sans Standard Lib. Java sans Standard Lib. On a les types de base et il faut tout construire. D'où la multiplication des librairies sur le net.
Il y a bien quelques efforts de fait comme CommonJS, mais on ne peut que constater qu'il n'y a pas de standard.

Quant au DOM et au W3C, le virage a été pris depuis quelque temps. Pour (X)HTML jusqu'à 4 le W3C a normalisé le langage HTML et ajouté le DOM et l'API DOM. Avec (X)HTML5 ce qui est normalisé c'est le DOM et son API le langage HTML5 n'est qu'une forme sérialisée du DOM.
Cette norme permet donc d'être conforme même si on utilise d'autres formes sérialisées du DOM.
Je constate qu'on trouve une multitude de représentations textuelles du DOM, dans les Lib JS. Ce qui montre un besoin. Mais là encore rien de normalisé.

J'en conclus que plus qu'un nouveau langage JS soufre d'un manque de Standard. Lib Standard pour le langage, Représentation sérielle standard autre que HTML pour le DOM, ET probablement aussi une API moins lourde pour le DOM.

Et pour finir, je dirais qu'il faut arrêter d'enseigner dans les écoles que POO = Classes. C’est archifaux et contre productif.

A+JYT
7  0 
Grom61736
Avatar de Grom61736
Membre éprouvé https://www.developpez.com
Le 15/11/2013 à 9:28
Il est temps de remplacer le Javascript par un langage qui n'a pas été écrit en quelques heures"
Je suis dev plutôt back-end donc pendant longtemps le JS m'a rebuté. Ce n'est que depuis quelques mois que je m'y réinteresse et j'aime bien.

Cependant, ce n'est pas parce que tu ne l'apprécie pas que tu peux le dénigrer (et par cette voie les dev JS) de la sorte...

Je testerais Dart pour voir les possibilités. Un truc de plus à tester.
4  0 
DonQuiche
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 15/11/2013 à 17:43
A mon sens le web n'a pas besoin d'un nouveau langage pour remplacer JS, il a besoin d'un mécanisme permettant aux développeurs d'utiliser efficacement le langage de leur choix.

Pour l'heure NaCL et asm.js semblent être les meilleurs candidats. Pour ma part je prône le premier.
4  0 
Zefling
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 15/11/2013 à 20:52
Citation Envoyé par CapFlow Voir le message
Et puis, si j'interprète ton message, jQuery serait à moitié une librairie.
S'il se débarrassait de tout ses sélecteurs et autre qui changent le langage en ne gardant que des éléments clés (ajax, animate et autre), je dis pourquoi pas !
Jquery est un framework, le plus populaire, mais il y en a d'autre.

Je remarque beaucoup l'utilisent pour sa gestion par sélecteur... Du coup, beaucoup ne savent même pas que querySelector("selector" existe qui fait grosso modo la même chose que $("selector" avec sa couche Jquery par dessus.

Code : Sélectionner tout 
1
2
3
$ = function (selector) {
  return document.querySelectorAll(selector);
};
Citation Envoyé par LSMetag Voir le message
Car il faut une certaine expertise à mon avis pour bien gérer du JS de base.
Ce qui est valable pour tous les langages ou frameworks. J'ai vu de belles horreurs en Java. En partie parce que le langage est très strict, un mauvais développeur pour arriver à ses fins fait des trucs d'une débilité ahurissante. Des types qui venaient du développement d'application lourde, qui n'avaient jamais fait de web et qu'on a foutus sur la création d'un site web. Le type n'avait aucune expertise pour ça... et là ce n’est pas la faute du langage, c'est qu'ils ne sont pas formés. Mais quand tu les écoutes, ils accusent le langage d'être merdique.
4  0 
sekaijin
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 24/11/2013 à 18:07
Citation Envoyé par LSMetag Voir le message
...
Tu dis qu'on utilise une approche d'il y a 10 ans avec JS. J'aimerais connaître l'actuelle.
...

Mais j'ai vu par exemple un Diablo-Like entièrement développé en Javascript. On met maintenant Office ou Visual Studio sur Internet (sans parler de Google Doc), et donc là l'utilisation de Javascript est intensive. L'utilisation de JQuery ou Dart devient justifiée.
....

ECMascript est normé W3C et c'est un autre problème. Ca évolue beaucoup trop lentement par rapport au besoin.
Lorsqu'on fait une appli java ou c++ on ne dessine pas des rectangles pour afficher un menu. il y a bien longtemps qu'on a abandonné l'idée de mettre du code dans l'IHM. on crée un objet menu qui lui va dessiner le menu, et on utilise le patern observable
On peut très bien faire la même chose pour les appli riche. Utiliser un objet menu qui va générer le DOM adéquat.

Je suis d'accord que lorsqu'on fais des appli comme Office 360 avoir des outils comme Dart SproutCore etc. ne sont pas dépourvus de sens. et je comprends qu'après GWT Google ait sentit le besoin d'un langage plus adapté.

Pour Info Ecmascript est normé par l'IEEE norme Ecma-262 Ecma-327 Ecma-357 Ecma-402
Le W3C normalise le DOM
L'API DOM vers divers langages et donc le binding EcmaScript
C'est pour ça qu'on retrouve JavaScript (on devrait dire EcmaScript) dans actionScript, node.js Jscript etc.
C'est une confusion courante qui et souvent source d'erreur.

A+JYT
4  0 
Lutarez
Avatar de Lutarez
Membre chevronné https://www.developpez.com
Le 27/02/2014 à 14:03
Citation Envoyé par sekaijin Voir le message
le boulot est le même. au détail près que je peux dynamiquement ajouter la dite méthode à un objet alors qu'il faut redéfinir la classe et réinstancier les objets pour faire la même chose.
Justement, à titre personnel, c'est la raison majeure qui me fait détester le Javascript.

Quand je développe une application, je réfléchis en amont à l'architecture de mon code : les différentes entités, comment chaque composant va interagir, les fonctionnalités que je dois implémenter, etc. De là, et de là seulement, je serai en mesure d'écrire mon application. Ce n'est que très rarement que j'aurai besoin de modifier mon architecture. Avec du prototypage, toute cette réflexion en amont peut être réduite à néant car n'importe quoi peut s'amuser à redéfinir le comportement d'une méthode.

Pour la petite histoire, dans le cadre d'un ancien travail, j'avais réussi à détourner une IHM Siebel pour mon usage (automatisation de la saisie d'informations) en redéfinissant une fonction Javascript, juste en utilisant IE7... Je pouvais même modifier des valeurs en lecture seule !
6  2 
pmithrandir
Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 15/11/2013 à 11:43
L'utiliser, non... enfin, non tant qu'il ne fonctionne pas sur tous les navigateurs.
Si au moins Firefox l'utilisait, voir Safari, on aurait un débouché sympa. Mais Chrome n'est pas suffisant selon moi.
En plus, ce navigateur n'est pas accepté dans ma boite pour des raisons de sécurité. (mais je suppose que Chromium embarque DART non ?)

Au final, plus qu'un bon travail, je pense que google doit mettre en place un très fort lobbying pour intégrer DART au moins dans firefox(quitte a payer le développement du module) Ca amènerai a une couverture d’environ 50% des utilisateurs, ce qui est pas trop mal(et surtout, ca amène a 95% d'un type d'utilisateurs que je qualifierai d'avertis et pointilleux)
3  0 
rebolon
Avatar de rebolon
Membre habitué https://www.developpez.com
Le 18/11/2013 à 14:19
On peut ne pas aimer js, mais on peut aussi éviter d'écrire des bêtises. Son implémentation repose sur Ecmascript. Ecmascript n'est pas là pour faire du remplissage de papier, c'est une norme, versionnée, sur laquelle repose les différentes versions de Javascript. Combien de langage peuvent se pré-valoir d'être normé ? Le problème de JS vient des interpréteurs intégrés dans les navigateurs, et surtout de l'historique lié à IE6 (merci Microsoft, au moins vouis avez retenu la leçon avec IE10/11)
Jquery n'est pas du js non plus et si les gens se formaient correctement au JS on aurait moins de soucis. Ca ne sert à rien d'utiliser systématiquement $() alors que document.querySelector/All fait pareil (à condition que sa cible d'utilisateur repose sur des navigateurs récents, mais pas tant que ça)

Typescript n'est pas un langage, mais tout comme coffeescript, une surcouche permettant d'écrire du code à compiler en js avant la mep (de manière manuelle ou auto). Ils ont leur propre implémentation d'un modèle objet sous Javascript, à chacun ses particularités.

Je ne suis pas contre Dart, j'aime ce qui est nouveau, mais quid de Dart sous FF, Opera, IE, ou du mobile ? Comme le dit Ugo-sansH il faut que la VM soit développée pour chaque navigateur dans chaque version d'OS. C'est pas gagné et du coup en attendant il faut dans tous les cas compiler en js pour être sur que ça marche partout, c'est dommage. On se retrouve alors avec une énième surcouche comme type/coffee script
3  0 
Commenter Signaler un problème