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 !

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

Le , par Idelways

61PARTAGES

2  0 
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 doit être open source et soutenu afin qu’il soit adopté par les autres éditeurs de 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 des plug-ins pour les autres navigateurs. Il n'est en effet pas à sa première intervention comme en témoigne l'épisode « Chrome Frame », pour Internet Explorer.

Dash pourrait donc être utilisée à la façon du 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 plateforme alternative impérieuse, 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 supposé Mark S. Miller, qu'il est réellement beaucoup trop difficile à coder des applications Web complexes en JavaScript ?
Êtes-vous prêt à développer en Dart ? Sous quelles conditions ?

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

Avatar de Freem
Membre émérite https://www.developpez.com
Le 16/09/2011 à 11:05
Au sujet du troll aux langages:
Les langages C et C++ ont une quantité impressionnantes de librairies existantes.

Si elles ne sont pas intégrées au langage lui-même, c'est pour une raison simple:
Ce sont des langages sujets à des normes, pas des conventions qui deviennent normes de fait, mais bien des normes reconnues par des organismes internationaux.
De plus, leur objectif n'a jamais été de faire le café par défaut, parce qu'une telle fonction, si elle peut être utile, ne l'est pas à tous les utilisateurs du langage, elle est trop précise.
Contrairement aux fonctions/classes qui font partie de la librairie standard du langage.
--> simplicité & légèreté (pas besoin d'apprendre maintes fonctions pour prétendre utiliser la bête, pas de dépendances inutiles non plus)

Un autre point qui est extrêmement important dans ces DEUX langages, car il faut arrêter de dire que ce sont les mêmes, c'est qu'un code aux normes peut compiler sur n'importe quelle machine qui aie un compilateur aux normes. Et un tel compilateur peut exister sur n'importe quelle machine, car ces normes ne définissent pas l'implémentation.
--> portabilité & efficacité (selon les compilos, bien sûr)

Moi je parle français. Quand j'ai besoin d'une phrase toute faite, je vais chercher dans un livre qui en recense. Je n'ai pas besoin de l'avoir intégrée dans ma langue, qui es déjà suffisamment riche comme ça.
Tous les langages font la même chose, avec plus ou moins de bonheur.
Le C et le C++ ne font pas exception à la règle.
--> extensibilité (encore que savoir le français ne veut pas dire que j'en connaisse toutes les subtilités)

La productivité viens du langage?
Je suis d'accord, mais pas à cause du nombre de lignes de code, qui dépend uniquement de la bibliothèque utilisée pour écrire le programme.
Un programme qui utilise l'API win32 dans le langage de votre choix sera bien plus long, moins efficace et moins portable, qu'un truc écrit en C++ avec les bibliothèques Qt ou WxWidgets. Et il sera aussi probablement plus performant sous windows, même si c'est un langage non compilé.

Je pense qu'elle viens de la quantité de paradigmes utilisables dans le langage, ainsi que de la rapidité d'apprentissage de celui-ci.
Un expert en C++ est probablement plus productif qu'un expert d'un langage qui gère moins de paradigmes. (rappel: C++ => programmation procédurale, la POO et la programmation générique. Certaines libs permettent d'utiliser la prog par contrat, mais je ne sais même pas ce que c'est :S )
Par exemple, si on ne peux pas écrire de template en php (je sais pas si on peut, hein, si ça se trouve il y a un équivalent, c'est un EXEMPLE), je ne vois pas comment un type qui exploite ce langage a fond peut être plus productif que quelqu'un qui maîtrise a fond le C++. Idem, les classes ne sont pas adaptées à tout: elles engendrent un surcoût mémoire et processeur.

La différence, c'est que pour maîtriser C++ il faut beaucoup plus de temps.
C'est pour ça qu'on le dit moins productif, pas pour son manque de fonctions/framework.

Un autre point souvent reproché au C++ c'est l'obligation de la gestion de la mémoire.
C'est le cas en C, mais pas en C++, justement grâce à ces fameux templates, l'introduction des références, les vector<T>, etc.

Chaque langage a ses spécificités, c'est sûr.
Et le 1er effet de ces spécificités, c'est le temps qu'il faut avant d'être productif avec le langage.

J'en ai vraiment marre d'entendre les gens dire "Je programme en .NET" par exemple, mais c'est vraiment représentatif de ce qui a été dit:
L'important, c'est de moins en moins le langage, pour ceux qui ne le maîtrisent pas à fond (et ne le veulent pas) mais le framework, qui est, lui, fait par des gens qui le maîtrisent.

PS: je suis pas un expert du C++, mais j'en voit les possibilités quand j'utilise la STL, écrite dans ce langage. Combien de langages peuvent se vanter d'être écrits en eux-même?

Bon, fin du troll sur ce sujet.

L'intérêt, ici, ce n'est pas la guégerre des langages, mais la naissance d'un nouveau.

Je m'y mettrais bien, personnellement. Google n'est pas fiable? Faut arrêter de déconner, je pense que nombreux sont ceux qui utilisent son moteur et son navigateur au quotidien ici, sans parler des mails.
Et idem les entreprises.

Et puis, ils veulent en faire un langage open source, alors on s'en fiche que google risque de le lâcher, tant qu'une communauté se crée derrière.
Et sur ce point, qui mieux que google peut la faire partir? ([joke]Bon, ok, y'a bien Linus Torvald qui a un gros pouvoir de ce côté mais il à d'autres fenêtres à fouetter [/joke])
Les communautés autour d'un produit ont déjà réussi des tours de force extraordinaires, comme racheter un logiciel propriétaire (inkscape par exemple).
D'autres langages open sources sont aujourd'hui des grands de ce monde:
Perl, Python, C, C++, JAVA, ... Pourquoi pas Dart, puisque tant de gens semblent dénigrer le Javascript?
10  0 
Avatar de Priato
Membre habitué https://www.developpez.com
Le 16/09/2011 à 11:46
Citation Envoyé par psykokarl Voir le message
Juste pour dire que le qualificatif "robuste" s'applique difficilement à une langage. Robuste se comprend par résistant au aléas (erreur humaine ou des valeurs en entrée). La robustesse qualifie le code et non le langage.
Bien en contraire j'attends d'un interpréteur ou d'un compilateur qu'il me pète à la figure dès que je fais quelque chose qui ne va pas.
Les qualités intrinsèque d'un langage selon moi sont
- la souplesse (façon d'écrire la même chose)
- la puissance (ce que je peux faire avec. Comprendre faire de la prog bas niveau si besoin)
- la lisibilité. (comprendre facilement et rapidement de quoi il retourne)
- la cohérence. (un système de nomenclature efficace qui me permet presque de deviner en grande partie la syntaxe et les mots clefs attendu)
- qu'il soit complet. (N'importe quel langage de prog digne de ce nom l'est)
Je te conseille grandement le langage Ada(si tu ne le pratiques pas encore...)

En C/C++ : On est parti du principe qu'un développeur sait ce qu'il fait et c'est à lui d'être robuste.
En Ada: On est parti du principe que le développeur est humain et donc qu'il fait beaucoup d'erreur. C'est le compilateur qui est robuste. Quand tu compiles... ça marche!
J'aime bien les 2 philosophies et entre ces 2 concepts mon coeur balance

Je n'ai pas vraiment pratiqué de développement javascript, mais si celui-ci possède des défauts gênants pour certains projets, je comprends que l'on cherche à créer un nouveau langage prenant en compte ces défauts. Du coup mes questions seraient: N'a t on pas déjà crée un autre langage résolvant ces problématiques javascript? Si c'est le cas, pourquoi n' a-t-il pas été démocratisé? Faut il qu'un géant l'impose?

Perso, je vois mal une startup créer un langage, le rendre populaire et qu'il soit adopté par tout le monde...
10  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 19/09/2011 à 11:40
Citation Envoyé par GanYoshi Voir le message
C'est discutable en effet, mais chacune des raisons que j'ai annoncé se suffi à elle-même,et la remise en cause de l'une d'elle n'entraine donc pas la remise en cause des autres.
Ah bon ? Allons-y dans le détail alors !

Citation Envoyé par GanYoshi Voir le message
Qui a envie d'investir dans une technologie naissante de Google ?

Quand on voit le non-respect de la compatibilité ascendante de Google (cf android)
On peut savoir à quoi tu fais allusion, exactement ?
Citation Envoyé par GanYoshi Voir le message

Quand on voit l'échec de leur précédente tentative d'imposer un langage (Go)
Ah bon, Go est un échec ? Je n'étais pas au courant. Qu'est-ce qui te permet de dire ça, exactement ?
Citation Envoyé par GanYoshi Voir le message

Quand on voit la monétisation frénétique de toutes leurs technologies (App Engine)
Même remarque que Mako 5013. J'ajouterais que Google fournit également énormément de technologies en open-source, sans les monétiser du tout. Comme Go, que tu citais plus haut...
Citation Envoyé par GanYoshi Voir le message

Quand on voit le nombre de projet Google qui ferme au bout de deux ans.
Toutes les entreprises subissent des échecs. Google comme les autres. Il n'y a que ceux qui ne font rien qui n'échouent jamais.
Citation Envoyé par GanYoshi Voir le message

Quand on voit que ce langage n'est même pas encore sorti, et quand on connaît le temps qu'il faut pour éventuellement voir apparaitre un nombre satisfaisant de librairie tierces.
Tous les projets ont débutés un jour. En raisonnant comme ça, on ne ferait jamais rien ! Il n'y a pas encore de jQuery pour Dart ? Et bien ça viendra si le langage est bon et s'il y a besoin. Chaque chose en son temps.
Citation Envoyé par GanYoshi Voir le message

Quand on voit l'offre disponible et déjà développée : PlayFramework, SpringMVC, grails etc
Je pense que tu n'as pas compris le but du projet. Il ne s'agit pas d'une librairie web pour Java, mais d'un langage de script destiné à être embarqué dans les navigateurs, le but étant de remplacer Javascript.

Je trouve que ton commentaire montre un conservatisme assez affligeant dans notre domaine...
10  0 
Avatar de Cyrano
Membre régulier https://www.developpez.com
Le 19/09/2011 à 15:33
Citation Envoyé par Rocket06 Voir le message
Les langages fonctionnels c'est pour les profs ringards de l'université ^^ A l'université ils ne connaissent même pas le c++ ^^ Sinon ils connaissent le java qui est juste un langage mal conçu...
Autant d'avis aussi péremptoires et tranchés ajouté au dénigrement de l'université de la part d'un étudiant, donc par définition manquant encore des années d'expériences qui donneraient l'autorité appropriée, il me semble que c'est assez arrogant...

Et c'est sans compter que c'est une fois de plus hors-sujet, au même titre que la comparaison entre deux choses qui n'ont de commun que le fait d'être des langages informatiques : ils ne sont en l'occurrence pas destinés aux mêmes fins il me semble, donc les comparer n'a pas vraiment de sens.

Enfin bon, pour ce que j'en dis hein... .
9  0 
Avatar de ptah35
Membre éclairé https://www.developpez.com
Le 26/05/2013 à 22:07
Citation Envoyé par ugo-sans-h Voir le message
[...] je trouve simplement que Javascript n'évolue pas assez avec sont temps et l'utilisation que l'on en fait aujourd'hui. Sont approche n'a pas changé depuis des années, hors, notre approche du web elle a beaucoup évoluée. Hier javascript servait à gérer trois onclick, aujourd'hui on développe des Web App qui concurrencent directement les applications lourdes.
Il existe aujourd'hui un nombre incalculable de langages de programmation, mais les paradigmes et les concepts qui sont mis en œuvre dans ces langages sont en nombre limités et la plupart ont été inventés entre la fin des années 50 et le début des années 70. Le fait de "ne pas évoluer avec son temps" est donc une critique que l'on pourrait adresser à n'importe quel langage.

Le fait que JavaScript ait été utilisé pour gérer "trois onclick" n'implique pas qu'il ait été développé avec cette seule ambition. En effet, JavaScript, qui devait à l'origine s'appeler LiveScript, était destiné à devenir un langage de script pour le serveur http "Netscape Entreprise Server" et si son nom contient le terme "script", ce n'est pas parce qu'il s'agit d'un langage de programmation au rabais, mais parce qu'il est destiné un environnement d'exécution particulier (en l'occurrence un navigateur). Le fait que des applications concurrençant des « applications lourdes » aient pu être réalisées, montre d’une part les progrès qu’ont fait le html et les navigateurs et, d’autre part, que JavaScript est un vrai langage de programmation.

Tous les langages de programmation ont été développés pour permettre la création d'abstractions pour que les programmeurs puissent plus facilement gérer la complexité des programmes. Les variables, les procédures, les fonctions, les modules, les classes sont autant de moyens permettant la création d'abstractions. JavaScript n'utilise ni classe ni module, mais cela ne signifie pas qu'il ne dispose pas de moyens puissant pour créer des abstraction. En JavaScript, le principal moyen d'abstraction est la fonction qui est, dans ce langage, un objet de première classe (first-class citizen) et une fermeture (closure).

Si l'on aborde JavaScript en espérant y trouver les même concepts qu'en Java ou qu'en C#, il est évident que l'on risque d'être déçu, et je pense que si ce langage a une si mauvaise réputation, ce n'est pas tant à cause de ses défauts bien connus, mais plutôt à cause de programmeurs déçus de ne pas trouver dans ce langage ce qu'ils espéraient y trouver et qui n'ont pas voulu ou pas pu faire l'effort de regarder ce qu'il avait à offrir.

Même si un autre langage remplace un jour JavaScript dans les navigateurs, il reste pour l’heure le lingua franca des navigateurs et en tant que tel, le seul langage utilisable pour réaliser la partie cliente d’une application Web, il convient donc de l’apprendre lorsque l’on se considère comme un professionnel du Web. Cela étant dit, puisque tous les langages de programmation Turin-complet sont équivalents, il es possible de compiler n’importe quel langage en JavaScript et c’est une très bonne chose que de tels compilateurs existent. Si donc vous êtes plus à l’aise avec un autre langage, utilisez-le, mais ne dénigrez pas JavaScript parce qu’il ne correspond pas à vos attentes.

« Tout le monde est un génie. Mais si vous jugez un poisson sur ses capacités à grimper à un arbre, il passera sa vie à croire qu’il est stupide » (Albert Einstein)
9  0 
Avatar de Robin56
Responsable Java https://www.developpez.com
Le 15/09/2011 à 0:56
Citation Envoyé par Traroth2 Voir le message
Si le but de Dart est la disparition de l'infâme Javascript, Google a toute ma reconnaissance !
Ouep .. quoiqu'on sait pas la gueule de Dart
8  0 
Avatar de Mako 5013
Membre éprouvé https://www.developpez.com
Le 15/09/2011 à 14:43
Citation Envoyé par GanYoshi Voir le message

Quand on voit la monétisation frénétique de toutes leurs technologies (App Engine)
Je sens une pointe de mauvaise foi...

Le modèle économique adopté par Google fait qu'une très grande majorité de leur produit sont disponibles gratuitement pour tous. On peut leur reprocher beaucoup de choses, mais la "monétisation frénétique de toutes leurs technologies", cela me semble quelque peu exagéré.

Mako.
8  0 
Avatar de Fanvan
Membre actif https://www.developpez.com
Le 10/10/2011 à 14:40
Citation Envoyé par tomlev Voir le message
Bah jusqu'ici on peut pas dire que le langage brille par son originalité
Qui aurait envie d'utiliser un langage à la syntaxe originale ? ou d'un langage dont les mots réservés seraient exprimés en hongrois ?

Même si j'ai des doutes sur l'avenir de dart, je trouve que l'idée de définir un langage pour le web côté client qui corrigerait les originalités de JavaScript est une joyeuse idée. JavaScript est aujourd'hui la référence parce qu'on n'a aucune autre véritable alternative. Si une alternative crédible parvenait à s'imposer, certainement qu'on y gagnerait au change.

C'est vrai que go est un échec certain, mais la situation n'est pas du tout la même pour dart. Quel était le besoin de créer go alors qu'on avait déjà pléthore de langages qui faisaient tous très bien le boulot pour lesquels ils avaient été pensés ? Y a-t-il besoin d'un autre langage qui ferait le même boulot que JavaScript ? Je crois que oui, et j'espère que google mettra toutes ses forces pour faire de ce nouveau projet une alternative crédible.
9  1 
Avatar de TropMDR
Membre éprouvé https://www.developpez.com
Le 10/10/2011 à 18:26
Je ne suis pas sûr que le but soit de "tuer javascript", ce qui me semblerait un poil trop ambitieux, vu la quantité de code existant dans ce langage. C'est plus d'apporter une alternative crédible et mieux pensé à ce langage, mais aussi je pense de fournir un laboratoire d'idées qui pourront, si elles s'avèrent bonnes à l'usage, éventuellement être intégrées dans les futures évolution de js.

La question qui se pose maintenant est de savoir si Dart offre suffisamment d'avantage comparé à js pour ne serait-ce qu'intéresser les programmeurs (avoir le tampon Google ne suffit pas forcément à rendre un langage intéressant, voir Go).

Le peu que j'ai vu ne m'a pas vraiment fait l'effet d'un truc révolutionnaire. Effectivement, le scoping est lexicale et non dynamique, mais la nouvelle version de javascript en mode strict le permet déjà.

Peut être que le modèle objet aura l'air plus familier aux habitués de Java et confrères. En revanche je n'ai pas eu l'impression que le langage vienne directement avec des capacités d'exploration du DOM supérieur à celles de JS, qui auraient pu rendre des bibliothèque tels que jquery plus ou moins inutiles, et entrainer de gros gains de performances. Bien sûr, il y a des sucres syntaxiques "amusant" comme les seteurs et geteurs.

Enfin, le système de type optionnel me parait assez peu intéressant. Dans l'idée, ça me semble bien de laisser les gens qui le veulent hacker en dynamique (même si je reste personnellement convaincu qu'un langage fortement typé n'est pas un problème pour le prototypage, ce n'est pas l'avis de la majorité, et la majorité a, dans une certaine mesure, forcément raison). Mais je n'arrive pour l'instant pas à percevoir l'intérêt d'ajouter des types. De ce que j'ai lu, ça rajoute l'emmerdement du typage explicite, à savoir la verbosité (qui, faut-il le rappeler, n'est pas un mal obligatoire des systèmes de types, l'inférence, ça existe), sans apporter masse des avantages, à savoir une capture statiques d'un certaine classe d'erreurs, des gains de performances et la "documentation" nécessairement à jour. Ici, les types ne sont "vérifiés" qu'à run time, et rien n'empêche moralement d'écrire n'importe quoi (donc exit la "doc à jour". En plus ils expliquent que les vérifications de type en question sont trop lourdes pour être effectuées à runtime, donc il faut le faire uniquement en mode développement, et les désactiver en prod.

En gros, leur système de type optionnel me semble être tout au plus un forme très pauvre de contrat dynamique (je rappelle que les contrats permettent d'exprimer des propriétés nettement plus intéressantes, telle que "un entier pair" ou "une fonction qui attend un flottant x et retourne un flottant y telle que y * y ~ x". Peut être que de "vrais" typeurs feront leur apparition, mais j'ai la triste impression qu'ils ont fait le design du "système de type optionnel" sans vraiment regardé ce qui se faisait ailleurs (les travaux sur le typage de scheme, les liketypes, etc etc). Tout cela m'a l'air très très "naïf".

Toujours dans le domaine du système de type, je n'ai (pour l'instant) rien vu sur les "types natifs", un peu comme ce qui apparait en javascript, qui permet d'allouer des tableaux de données consécutives. Il semblerait donc que Dart se retrouve être encore moins adapté que js comme cible pour un backend de compilateur.

Mais bon, je n'ai pas encore eu le temps de lire toute la spec du langage, donc tout ce que je dis là est sur mes premières impressions, pas sur une étude profonde de la bête !
8  0 
Avatar de rt15
Membre éclairé https://www.developpez.com
Le 11/10/2011 à 16:22
Citation Envoyé par tomlev Voir le message
Ca me fait penser à l'article de Scott Hanselman selon lequel Javascript serait en train de devenir l'assembleur du web...
Alors ça c'est vraiment pas bête.

On a pas vraiment besoin d'un remplaçant de javascript (Dans le sens langage supporté par la plupart des navigateurs) avec des avantages et inconvénients par rapport au javascript actuel. Ce nouveau langage ne pourrait pas faire que des heureux : certains le voudraient facile, d'autre strictement typé, d'autres voudraient un langage fonctionnel, d'autres voudraient les templates...

Pourquoi les développeurs devraient-ils se limiter à un langage pour le développement côté client ? Pourquoi les navigateurs devraient perdre du temps à exécuter un langage de haut niveau, objet, plus ou moins rigoureusement typé ?

Ce qu'il faudrait c'est que les navigateurs exécutent un langage de bas niveau, genre assembleur, ou même un byte code.

Les développeurs auraient ensuite tout un tas de langages existant et futurs compilant vers ce langage.

Comme l'explique l'article, cette théorie est déjà pas mal appliquée en se servant du javascript comme langage intermédiaire. Les défauts de celui-ci ne sont alors plus que ses piètres performances.

Dart a peut être un avenir comme langage compilé vers javascript. Mais dans les navigateurs, il risque de se retrouver dans la situation de flash/applet java/silverlight : un support plus ou moins répandu.

Le remplaçant de javascript ne devrait donc pas être un langage "trop cool" à développer, mais un truc bas niveau, simple (Peu d'instructions), performant à l'exécution et facile à implémenter dans les navigateurs.
8  0