Google publie une pré-version de Chrome avec la machine virtuelle Dart

Le 17/02/2012, par Idelways, Coordinateur publications
Mise à jour du 17/02/2012, par Hinault Romaric

Google vient de publier une préversion ( technical preview) pour les développeurs de Dartium, un navigateur à base de Chrome qui introduit la machine virtuelle Dart.

Dart est présenté par Google comme un langage de programmation structuré pour le Web, basé sur les classes et optionnellement typé.

L’objectif inavoué de Google est de mettre JavaScript à la retraite en proposant un langage qui offre la même flexibilité que celui-ci, mais qui se distingue par son typage fort et optionnel.

Dart s'exécute soit sur une machine virtuelle native du côté serveur ou sur un moteur JavaScript classique à l'aide d'un compilateur qui convertit le code en JavaScript compatible avec Chrome, Safari 5+ et Firefox 4+, etc.

Cette préversion permettra d’exécuter des programmes Dart directement sur la machine virtuelle Dart incluse dans le navigateur Chrome, en évitant une étape de compilation séparée pour convertir le code.

Google a l’intention, après plusieurs tests de la VM Dart, de l’inclure dans les futures versions de son navigateur Chrome.

Pour l’instant, le langage bénéficie uniquement du support de Google, et aucun constructeur de navigateur n’a encore indiqué son intention de supporter Dart. La firme espère néanmoins atteindre un certain stade de maturité avec Dart avant de le soumettre à un processus de normalisation.

Dartium est disponible pour les ordinateurs Mac et Linux. Une version pour Windows sera disponible dans les jours à venir.

Télécharger Dartium

Source : Google

Dart : Google dévoile la nature de son JavaScript-killer
Un langage flexible et optionnellement typé, conçu pour les hautes performances

Mise à jour du 10 octobre 2011 par Idelways

Les rumeurs viennent d'être confirmées au sujet du nouveau langage de programmation de Google. L'entreprise a officiellement dévoilé la nature et les ambitions de son langage Dart à la conférence Goto qui se déroule au Danemark.

Les spéculations autour du « langage de programmation structurée pour le Web » ont été déclenchées par une discrète annonce sur le planning de cette conférence. Puis, elles ont été confortées par la fuite d'un email interne de Google (lire ci-devant)

Une première Preview sur le site officiel du langage met à disposition des développeurs des outils open source de création d'applications, des exemples de code, la documentation de sa bibliothèque standard et un brouillon des spécifications du langage.

Dart est défini en tant que « langage basé sur classes et optionnellement typé », sur l'annonce officielle par Lars Bak, le créateur du moteur JavaScript V8 et membre de l'équipe Dart.

Logo de Dart


Les objectifs de la conception du langage visent à créer un langage « structuré, mais flexible », qui semble « familier et naturel pour les développeurs, et faciliter ainsi son apprentissage ».
Enfin (et surtout), Dart est amené à afficher de hautes performances sur tous les navigateurs et environnements modernes, « à partir des périphériques portables jusqu’à l'exécution du côté serveur », confirme l'ingénieur émérite de Google.

Dart se distingue du JavaScript, dont il a l'ambition de supplanter, par son typage fort, mais optionnel. Les développeurs peuvent donc coder avec la même flexibilité qu'en JavaScript et ajouter le typage par la suite, voir se faciliter cette tâche à l'aide d'outils d'analyse et d'inférence de types.
Dart suit un modèle objet assez complet et plus classique que celui du JavaScript (qui est basé sur le prototypage). Il supporte notamment les concepts d'implémentation d'interfaces et d'héritage simple.

Dart s'exécute soit une machine virtuelle native du côté serveur ou sur un moteur JavaScript classique à l'aide d'un compilateur qui convertit le code en JavaScript compatible avec Chrome, Safari 5+ et Firefox 4+ (d'autres navigateurs suivront).

Sans surprise, les scripts Dart peuvent cohabiter avec le code HTML à travers la balise script qui prend le type « application/dart », qui est par la même occasion le mime-type du langage. La fonction main() du style C est obligatoire.

Bien qu'il soit monothread, la programmation concurrente est dès le départ au centre des préoccupations de l'équipe Dart. Le langage supporte les « isolations » qui ont chacune leurs propres mémoire et thread de contrôle. Aucun état n'est partagé entre les isolations qui sont créées par spawning (des fonctions qui chargent et exécutent des processus fils).

L'équipe de Dart envisage d'intégrer la machine virtuelle de Dart au navigateur Chrome, mais aucune date n'est avancée.

Et en voici le traditionnel Hello World !


Code :



1
2
3
4
main() {
  print('Hello World');
}


Site officiel : dartlang.org
Spécifications du langage

Source : annonce officielle sur le blog Googlecode

Et vous ?

Alors, vous comptez vous y mettre ?
Que pensez-vous du langage Dart ?

Google souhaite-t-il pousser JavaScript vers la sortie avec Dart ?
Son nouveau langage de programmation Web

Mise à jour du 14 septembre 2011

Le langage de programmation Dart sur lequel Google met les dernières retouches avant sa présentation en octobre devrait succéder au langage JavaScript, afin de pallier aux « défauts fondamentaux » qui ne peuvent être corrigés en faisant simplement évoluer le langage.

Des défauts qui ralentissent le développement d'applications Web complexes, devenu « beaucoup trop difficile » et un véritable « labyrinthe déroutant ».

Ce serait en tout cas les ambitions de Google à en croire le contenu fouillé d'un email supposé provenir du chercheur émérite Mark S. Miller et adressé à de nombreux collègues de Google.
Un mail qui remonte au 16 novembre 2010 et dont le texte intégral peut être retrouvé sur Github.

L'auteur de l'email évoque deux stratégies pour pousser JavaScript vers la sortie et le suppléer par le langage « Dash » (qui aurait changé de nom pour devenir Dart). Un langage « destiné à maintenir la nature dynamique de JavaScript, mais avec un meilleur profil de performance et qui se prête mieux au “tooling” sur les grands projets ».

La voie Dash ou Dart, « très risquée, mais d’une grande valeur ajoutée », implique, toujours d'après l'email, que le langage soit open source et soutenu pour qu'il soit supporté sur d'autres navigateurs.

Le langage — dans la vision de Mark S Miller — ne devrait pas (du moins en un premier temps) faire plus que ce que JavaScript permet de réaliser au niveau du navigateur, puisqu'il propose qu'un compilateur de code Dash vers JavaScript soit mis à la disposition des développeurs pour cibler les navigateurs qui ne le prennent pas en charge nativement.

Google pourrait donc tenter d'accélérer l'adoption (non native) de son langage en prenant à sa charge la création de plug-ins pour les autres navigateurs. Il n'en est en effet pas à sa première intervention comme en témoigne l'épisode « Chrome Frame », pour Internet Explorer.

Dash pourrait donc être utilisé comme le langage open source CoffeeScript qui compile en JavaScript, avec le but ultime « de remplacer JavaScript comme une lingua franca pour le développement sur la plateforme Web ouverte »

Entre-temps, Google maintiendra une stratégie que Miller appelle « Harmony », en continuant de travailler conjointement avec le TC39 (le corps de standardisation d'EcmaScript) pour faire évoluer JavaScript.

Mais toute cette initiative, destinée à faciliter le développement Web ouvert et améliorer ses performances, serait surtout motivée par la peur des écosystèmes d'Apple et d’autres plateformes fermées vers lesquels « dérive le cyclone d'innovation ».

« L'émergence de plateformes alternatives impérieuses, comme iOS signifie que la plateforme Web doit se montrer compétitive, non seulement sur le fond, mais aussi sur sa portée », estime Mark S Miller, avant de poursuivre : « JavaScript tel qu'il est aujourd'hui n’est pas une solution viable à long terme et quelque chose doit changer ».

Source : L'email sur Github

Et vous ?

Trouvez-vous, comme le supposait Mark S. Miller, qu'il est réellement beaucoup trop difficile de coder des applications Web complexes en JavaScript ?
Êtes-vous prêt à développer en Dart ? Sous quelles conditions ?

Dart : Google prépare un nouveau langage de programmation structurée pour le Web
Qui sera dévoilé à la conférence Goto

Quelques jours après que l'enregistrement de plusieurs noms de domaines ait vendu la mèche, c'est désormais officiel : Google travaille sur un nouveau « langage de programmation structurée pour le Web ».

« Dart » sera présenté à la keynote d'ouverture de la conférence GOTO Aarhus le 10 octobre prochain, et c'est à-peu-près tout ce que l'on sait d'officiel sur ce mystérieux langage.

Deux célèbres pionniers du développement, qui en seraient les principaux instigateurs, présenteront la nouvelle création du géant américain, présent partout sur le Web, mais beaucoup moins entre les doigts des codeurs Web hormis à travers les API et quelques outils comme l'excellent Google Web Toolkit.

Il s'agit de Gilad Bracha, un vétéran de SAP et Sun, et coauteur des spécifications du langage Java, ainsi que Lars Bak, le créateur de moteur JavaScript V8, entre autres.

Les conférenciers ont tous les deux une expérience conséquente avec le langage Smalltalk et Dart pourrait en être fortement inspiré.
On s'attendra donc a priori à un langage interprété qui piétinera les plates-bandes de Python et JavaScript, deux langages de programmation plébiscités chez Google.

Parmi les autres spéculations qui vont bon train sur le Web, on retiendra que Dart pourrait n'être qu'une extension du V8, ou un nouveau souffle donné au langage Newspeak inventé par Gilad Bracha, qui aurait été amélioré par Google et débarrassé de son nom à connotation négative : la novlangue imposée par le régime totalitaire de l'Océania pour éliminer toute expression subversive dans le roman 1984 de George Orwell.

Mountain View dispose d'un langage de programmation orienté-système appelé Go, qui est considéré, en dépit de la croissance pénible de sa popularité vacillante, comme une alternative crédible au C++ et à Java.

À noter que Google a détenu quelques temps une technologie qui porte le nom DART, issue de l'acquisition de Doubleclick en 2007. « Dynamic Advertising Reporting & Targeting » a été abandonnée l'année passée.

Quoi qu'il en soit, le plus grand défi qui s'opposera à Dart sera d'apporter une véritable valeur ajoutée dans un paysage Web saturé de langages aussi bons que diversifiés.

Source : Site officiel de la conférence Goto Aarhus

Et vous ?

Quel type de langage attendez-vous (ou souhaitez-vous) de Google ?
Y'a-t-il encore une place pour un nouveau langage de programmation pour le Web ?
Dans quels domaines et pour quelles applications ?

Les rubriques (actu, forums, tutos) de Développez
Retrouvez le dossier complet de la rédaction


Poster une réponse Retrouver la discussion sur le forum

Avatar de _skip _skip
Expert Confirmé Sénior
le 02/03/2012

Citation:





Envoyé par Uther
Voir le message

Pour le coup je ne suis pas d'accord : pour moi le plugin ne doit être qu'une solution de contournement provisoire a un problème que ne permet pas de résoudre les technologies standardisées.
Par principe les outils clés du web doivent être ouverts. Avec des plugins comme Silverlight, ou Flash on remet les clés du web dans les mains de sociétés privées.



Ok sur le point que ça devrait être open source afin d'être indépendant de la volonté d'un éditeur spécifique. Cependant je maintiens que le plug in, ça a ses avantages.

Verrais-tu un grave inconvénient à ce qu'un runtime commun soit partagé entre les navigateurs, si ce runtime était open source? Enfin juste histoire d'éviter aux éditeurs de navigateurs de refaire chacun leur implémentation et d'être terriblement lié aux versions de ceux-ci.
L'avantage que j'y vois c'est une restitution fidèle (forcément s'il y a qu'une seule implémentation) et une facilité d'évolution dans le sens ou le plugin pourrait avoir ses propres cycles d'évolution sans exiger à chaque release des MAJ majeurs dans le code des browsers. En plus, il y aurait ainsi la possibilité côté développeur de gérer facilement les versions cibles du runtime comme on le fait avec flash ou même java et .net.
Avatar de camus3 camus3
Membre expérimenté
le 02/03/2012

Citation:




Verrais-tu un grave inconvénient à ce qu'un runtime commun soit partagé entre les navigateurs, si ce runtime était open source?


le problème : le boss de Mozilla = inventeur de javascript , donc il risque de prêcher encore longtemps pour sa paroisse , Adobe avait déja proposé une VM opensource , Tamarin basé sur flash, mais Microsoft n'en voulait pas à cause de Silverlight.
Avatar de stardeath stardeath
Membre Expert
le 02/03/2012
j'y vois un énorme avantage à ces plugins mal aimés : on peut les désactiver si ça nous chante, une pub flash moisi, un site en flash trop lourd et paf on peut ne plus les voir.

de plus en plus on voit fleurir des sites faisant un abus de js qui soit râment soit plantent, mais puisque eux font parti du standards, les désactiver déjà c'est plus chiant, et en plus on perd tout le site.

pour moi c'est : plugin 1 - standard 0

je préfère nettement avoir un site web statique (en terme d'animation) et rapide avec des plugins désactivables pour apporter les anims qu'un site web avec tellement de js qui faut presque une machine de compet' pour pouvoir surfer (et visiblement c'est ce dernier point qui est tendance).

et puis pourquoi le monde du libre/open source ne serait pas proactif et proposerait d'elle même une alternative?
il me semble pourtant que c'est ce que google est en train de faire, non?
Avatar de MiaowZedong MiaowZedong
Membre Expert
le 02/03/2012

Citation:





Envoyé par stardeath
Voir le message

j'y vois un énorme avantage à ces plugins mal aimés : on peut les désactiver si ça nous chante, une pub flash moisi, un site en flash trop lourd et paf on peut ne plus les voir.

de plus en plus on voit fleurir des sites faisant un abus de js qui soit râment soit plantent, mais puisque eux font parti du standards, les désactiver déjà c'est plus chiant, et en plus on perd tout le site.



Loi de Wirth, quand tu nous tiens

Effectivement, le bricolage de RIA cache mal le fait qu'on est en train de faire tourner des applis client/serveur lourdes sur des technos faites pour la transmission de données. À mon avis, les RIA justifieraient une refonte d'Internet.
Avatar de gwinyam gwinyam
Membre Expert
le 02/03/2012

Citation:





Envoyé par _skip
Voir le message

Ok sur le point que ça devrait être open source afin d'être indépendant de la volonté d'un éditeur spécifique. Cependant je maintiens que le plug in, ça a ses avantages.



J'ai expliqué exactement l'inverse hier pendant ma conférence sur jQuery. Le plugin a des avantages, peut-être. Mais il a un désavantage critique, c'est de demander à ton utilisateur de s'adapter au besoin de ton logiciel. Et ça pour moi, c'est déjà la preuve que, en tant que développeur, tu ne fais pas du bon boulot.

J'essaie toujours au maximum d'appliquer une règle simple : un logiciel, que ce soit une application, un site ou un plugin jQuery ne doit jamais nécessiter l'adaptation du client mais doit s'adapter au client.
Avatar de _skip _skip
Expert Confirmé Sénior
le 02/03/2012

Citation:





Envoyé par gwinyam
Voir le message

J'ai expliqué exactement l'inverse hier pendant ma conférence sur jQuery. Le plugin a des avantages, peut-être. Mais il a un désavantage critique, c'est de demander à ton utilisateur de s'adapter au besoin de ton logiciel.



Je parle pour ce cas d'école de quelque chose d'officiel comme plug in, qu'on retrouverait partout mais qui fournirait un environnement d'exécution découplé du navigateur (bien qu'il pourrait s'installer avec de façon transparente sous forme de bibliothèque LGPL ou je ne sais quoi).

Mais soit ça me semble tout à fait juste de dire que faire sans ne pose aucune contrainte, si j'utilise les dernières API javascript, est-ce que je n'oblige pas aussi mon audience à venir avec des navigateurs qui les supportent et de faire des mises à jour si besoin? Mon point était surtout de dire que je trouvais extrêmement regrettable qu'on laisse chaque éditeur faire son implémentation dans son coin car ça multiplie les coûts des tests tout en ne fournissant que peu de garanties sérieuses que tout s'exécute de la même façon partout.

L'un des but d'un standard, c'est censé rendre les choses portables et bien comprises de la même façon par tous. Or je suis persuadé que les applications à base de plugins (flash ou silverlight) sont plus (ou plus facilement) portables que les applications javascript.
Mais c'est pas un truc tout à fait unique à javascript/css/html, à un certain moment en Java, une applic Struts/Spring/Hibernate avait plus de chance d'être portable d'un serveur d'application à un autre qu'une application JSF/EJB standardisée.


Citation:




Et ça pour moi, c'est déjà la preuve que, en tant que développeur, tu ne fais pas du bon boulot.

J'essaie toujours au maximum d'appliquer une règle simple : un logiciel, que ce soit une application, un site ou un plugin jQuery ne doit jamais nécessiter l'adaptation du client mais doit s'adapter au client


Oui et non, ta règle très noble sur le fond a quelques limitations. Tu dois en tant que développeur faire un compromis avec ton audience. Forcer 2 millions d'utilisateurs d'un site web publique d'installer un truc dont ils ne veulent pas exprès pour toi c'est assez inacceptable en effet. Cependant ...

- La donne change si 90% des utilisateurs de ton public cible ont déjà le truc dont tu as besoin.
- Si ton public est plus restreint (style une entreprise) il peut choisir entre installer un runtime (disons java) une fois ou t'obliger à tout programmer en C pour qu'il n'y ait rien à installer quitte à multiplier par 3 ou 4 les coûts.

Donc la règle générale, tu choisis la meilleur solution sous la forme d'un trade-off entre les coûts, l'effort que le client est disposé à faire et la faisabilité du tout.
Avatar de Uther Uther
Expert Confirmé
le 02/03/2012

Citation:





Envoyé par _skip
Voir le message

Ok sur le point que ça devrait être open source afin d'être indépendant de la volonté d'un éditeur spécifique. Cependant je maintiens que le plug in, ça a ses avantages.

Verrais-tu un grave inconvénient à ce qu'un runtime commun soit partagé entre les navigateurs, si ce runtime était open source? Enfin juste histoire d'éviter aux éditeurs de navigateurs de refaire chacun leur implémentation et d'être terriblement lié aux versions de ceux-ci.



Pour moi l’intérêt est d'avoir un standard implémentable par tous sans restriction. S'il y a des implémentations libres c'est encore mieux.

Un runtime commun libre me parait une grosse erreur autant d'un point de vue idéologique que pragmatique:
- par définition le libre est fait pour être forkable par n'importe qui donc un Runtime commun libre serait un vrai contresens, Ce n'est certes pas impossible, mais carrément contre nature quand même, je doute que ça soit viable.
- ça poserait la question de comment gérer ça. Apparement ton idée est d'avoir une seule société qui dirige ça pour aller plus vite, mais je ne donnerais certainement pas les clés du Web à une seule et unique entité même si certaines me semblent aller plutôt dans le bon sens actuellement, les intérêts peuvent changer, surtout quand on est en possession de tout le pouvoir.
- s'il est commun à tous, faire un Runtime n'a juste aucun sens. Autant faire un moteur unique, et le moteur unique ça a quasiment existé : ça s'appelait IE 6 et ça a failli tuer toute évolution du web et consacrer flash et les mauvaises pratiques.

C'est la concurrence qui a fait évoluer le web. Un monopole même s'il est tentant au premier abord constitue toujours un danger à terme.


Citation:





Envoyé par camus3
Voir le message

le problème : le boss de Mozilla = inventeur de javascript , donc il risque de prêcher encore longtemps pour sa paroisse , Adobe avait déja proposé une VM opensource , Tamarin basé sur flash, mais Microsoft n'en voulait pas à cause de Silverlight.



Brendan Eich n'est pas le boss de Mozilla même s'il y occupe il est vrai une place importante.

Quant au projet Tamarin, il n'a jamais ambitionné d'être une moteur commun à tous les navigateurs. Il a été abandonné par tout le monde y compris Mozilla qui avait pas mal travaillé à l'intégrer dans un premier temps. Il s'est révélé qu'il était techniquement pas assez adapté a l'utilisation dans un navigateur.


Citation:





Envoyé par stardeath
Voir le message

j'y vois un énorme avantage à ces plugins mal aimés : on peut les désactiver si ça nous chante, une pub flash moisi, un site en flash trop lourd et paf on peut ne plus les voir.



Une très mauvaise raison.
C'est juste une chance qu'actuellement leur utilisation est ponctuelle pour le multimédia. Si on a des sites s'appuyant lourdement sur des plugins, il devient difficile voire impossible de bloquer sélectivement.
Et rien de plus simple que de faire un addon qui fasse disparaitre les balises <video>, <canvas>, ... d'une page HTML.
Avatar de stardeath stardeath
Membre Expert
le 02/03/2012

Citation:





Envoyé par Uther


Et rien de plus simple que de faire un addon qui fasse disparaitre les balises <video>, <canvas>, ... d'une page HTML.



mais là on ne parle pas d'une balise problématique mais de js, qui dans de plus en plus de site fait absolument tout, désactiver le javascript revient à désactiver le site.


Citation:





Envoyé par Uther


Si on a des sites s'appuyant lourdement sur de plugins



effectivement c'est aussi un problème, c'est pour ça que je précise la partie animée d'un site.

MiaowZedong résume, à mon avis, parfaitement le problème : on veut faire du web un bureau multimédia tel qu'on l'a sur un ordinateur chez soi (j'espère avoir bien paraphrasé l'idée)
Avatar de camus3 camus3
Membre expérimenté
le 02/03/2012

Citation:




J'essaie toujours au maximum d'appliquer une règle simple : un logiciel, que ce soit une application, un site ou un plugin jQuery ne doit jamais nécessiter l'adaptation du client mais doit s'adapter au client.


hmm,Tout dépend de contenu offert. Un client qui veut consommer un certain type de contenu s'adaptera aux exigences du fournisseur si le contenu représente un réel intérêt / plus-value et n'est pas disponible ailleurs sous une forme plus accessible.

Si demain je propose de mettre en ligne les sujets du bac avant les épreuves via un plugin 100% propriétaire , les intéressés téléchargerons mon plugin pour avoir accès au contenu ( c'est juste un exemple ).

Flash ne s'est pas imposé parce qu'on mettait le couteau sous la gorge des gens mais parce qu'il a permis aux utilisateurs d’accéder à certain types de contenu qu'ils désirent ( jeux / video / porno / etc ... )

Les fournisseurs ont eux même certaines contraintes techniques ( "protection"des sources , time to market , streaming , DRM , etc ... ) qui font que les choix d'une solution standard n'est pas "automatique".
Avatar de camus3 camus3
Membre expérimenté
le 02/03/2012
A lire :

http://books.google.fr/books?id=nneB...r+Horwat&hl=fr

une interview de Eich, très intéressante. Il croit lui même à la disparition de Js à moyen terme.
 
 
 
 
Partenaires

Hébergement Web