Dart : l'alternative de Google à JavaScript est prête à l'action

Le 17/10/2012, par Hinault Romaric, Responsable Actualités
Mise à jour du 17/10/2012

Google vient de sortir la première version du SDK de Dart, son langage de programmation structuré pour le Web, basé sur les classes et optionnellement typé.

Cette publication marque le premier anniversaire du langage. Dévoilé en technology preview il y a de cela un an, le projet Dart propose un langage de programmation moderne, des bibliothèques et des outils pour construire des applications Web complexes.

La nouvelle version du SDK de Dart apporte plusieurs améliorations et nouvelles fonctionnalités dont une machine virtuelle plus rapide pouvant même surpasser le compilateur JavaScript V8 sur le Benchmark Octane pour certains tests. Un nouveau traducteur JavaScript Dart permet une génération plus rapide et compacte.

L’outil embarque également un éditeur de code (Dart Editor), un nouveau gestionnaire de packages (Pub), un langage de spécification, ainsi que Dartium, un navigateur fondé sur Chrome qui dispose du support natif de Dart.

Cette version dispose d’une bibliothèque pour interagir avec le code JavaScript, une bibliothèque E/S serveur et une bibliothèque HTML pouvant s’exécuter de manière transparente sur les navigateurs modernes.

Dart 0.1 gagne en robustesse et en fiabilité, et peut désormais être utilisé dans un environnement de production.

Le langage sera amené à évoluer dans les mois à venir, selon Google, mais la compatibilité ascendante sera maintenue.


L’objectif de Google avec Dart est de proposer une alternative au langage JavaScript, qui offre la même flexibilité que celui-ci, mais qui se distingue par son typage fort et optionnel. Il est vu comme un JavaScript-killer. Microsoft, pour sa part, a adopté un chemin différent avec TypeScript, qui est un sur-ensemble de JavaScript.

Télécharger le SDK de Dart

Source : Google

Et vous ?

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


 Poster une réponse

Avatar de Flyers Flyers
Invité de passage
le 17/10/2012 14:04
Dart à l'air sympa comme langage avec pas mal de features intéressantes.

Le problème c'est qu'il faut le Dart Editor, Dartium et DartXXX pour vraiment pouvoir profiter du langage.

Bref, ça fait très Microsoft ActiveX je trouve avec un produit créer par une entité pour cette même unique entité.

Personnellement, je préfère une surcouche à la TypeScript pour réaliser mon code et pouvoir le customiser après si nécessaire.

Donc Dart, non merci, trop Google Fanboy pour moi. En plus, on commence à se rendre compte que Google est une entreprise et que de plus en plus de leurs produits soit disant gratuits deviennent payants. Rien à voir avec la philosophie du libre...
Avatar de Code62 Code62
Membre émérite
le 17/10/2012 14:35
Citation:
Envoyé par Flyers Voir le message
Le problème c'est qu'il faut le Dart Editor, Dartium et DartXXX pour vraiment pouvoir profiter du langage.
- il ne faut pas plus le dart editor pour écrire du dart qu'il ne faut eclipse pour écrire du java: tu peux écrire du code dart dans notepad si tu veux
- il faut dartium (pour le moment) pour executer nativement le dart dans un navigateur, mais il est aussi possible de "traduire" le code dart en javascript pour l'utiliser dans tous les autres navigateurs, en attendant qu'ils adoptent dart
- il faut dans ce cas effectivement un outil pour transformer le code, tout comme il faut un compilateur si on veut faire du C ou du Java, ce n'est pas vraiment un argument "contre" le langage

Citation:
Envoyé par Flyers Voir le message
Bref, ça fait très Microsoft ActiveX je trouve avec un produit créer par une entité pour cette même unique entité.
sauf que dart fonctionnera aussi sous linux ou mac, alors qu'activeX n'a jamais fonctionné que sous windows; que dart est libre et open source, confié à une communauté avec pour but de le faire adopter aussi largement que possible

Citation:
Envoyé par Flyers Voir le message
Personnellement, je préfère une surcouche à la TypeScript pour réaliser mon code et pouvoir le customiser après si nécessaire.
mouais, mais une surcouche ne corrige pas réellement les problèmes de la sous-couche (qu'on ne vas pas énumérer ici, c'pas le sujet), au mieux ça les masque... avec dart, un départ "from scratch" permet simplement de ne pas avoir ces problèmes, ni visibles ni cachés

Citation:
Envoyé par Flyers Voir le message
En plus, on commence à se rendre compte que Google est une entreprise et que de plus en plus de leurs produits soit disant gratuits deviennent payants. Rien à voir avec la philosophie du libre...
faut pas tout mélanger: oui évidemment google est une entreprise qui fait payer ses services... mais c'est aussi une entreprise dont la très grande majorité des services sont sur le web, et qui perd de l'argent quand ses développeurs perdent leur temps à travailler avec javascript... si dart est largement adopté et supporté par tous les navigateurs, google est gagnant de facto... ils n'ont aucun intérêt à monnayer Dart

In Dart I Trust, et je me réjouis de son démarrage ^^
Avatar de yann2 yann2
Membre Expert
le 17/10/2012 16:04
Bonjour

Citation:
Envoyé par Flyers Voir le message
Dart à l'air sympa comme langage avec pas mal de features intéressantes.

Le problème c'est qu'il faut le Dart Editor, Dartium et DartXXX pour vraiment pouvoir profiter du langage.

Bref, ça fait très Microsoft ActiveX je trouve avec un produit créer par une entité pour cette même unique entité.

Personnellement, je préfère une surcouche à la TypeScript pour réaliser mon code et pouvoir le customiser après si nécessaire.
Tu peux générer du javascript depuis un programme écrit en Dart. La volonté de google c'est de simplifier le développement et notamment le développement d'applications clientes WEB à l'aide d'un langage mieux spécifié (c'est certainement pour ça que Dart n'est qu'en 0.1). Seulement google sait que firefox et IE et safari et ect. ne supportent pas ce langage donc ils ont simplement proposer une génération de code Javascript (ils ne sont pas débiles). L'information est sur la page d'accueil du site du langage donc il n'y a pas besoin de pousser les recherches très loin

Pour avoir parcouru les spécifications du langage, je trouve ça très prometteur et j'espère que les autres éditeurs de navigateurs changeront d'avis sur ce langage qui est un vrai plus comparé au monstre hybride qu'est javascript (qui a quand même de bons côtés, je ne le nie pas. Seulement, ils sont gâchés par les mauvais côtés ).
Avatar de ugo-sans-h ugo-sans-h
Membre du Club
le 17/10/2012 19:11
Je m'y suis essayé il y a quelques semaines. J'ai développé un player reposant sur la balise <video>.

Le fait de travail en objet déjà, c'est un énorme plus;
La gestion des librairies est pas mal (j'aurais aimé des namespaces ça aurait été parfait);
Très simple est clair de travailler avec le DOM et les évènements;
La fonction "query('mon selector')" Qui est ni plus ni moins l'équivalent de "jQuery('mon selector') avec lequel on peut travailler sur id, class, attribut, etc...);
Les accesseurs qui m'ont rappelé C#, j'ai trouvé ça sympa;
La gestion des socket est clair, simple.

Il manque encore deux trois détails (vraiment de très petites chose notamment pour le DOM), par exemple, j'aurais aimais avoir un méthode .position() retournant une instance Point sur la classe Element.

L'api est pas super super clair, beaucoup de méthodes abstraite, mais sans savoir pourquoi.
J'aurais aimé voir plus d'exemples concrets sur le site officiel, notamment sur les socket, les évènements, et le DOM.

Mon premier retour est très positif, je suis plutôt confiant sur le développement d'application complexe avec ce langage.

Bien sur j'entends déjà : "Oui mais ça on peut déjà le faire avec js, oui mais ça aussi" !! Oui, mais là on peut le faire plus proprement, plus structuré, plus homogène, le travail en équipe devient plus simple et la productivité en bénéficie à coup sur.
Avatar de mekal mekal
Membre chevronné
le 18/10/2012 20:31
et tu a une demo du player ayant moi meme fait un player en js j'aurait voulu comparer le js generé et aussi le dart créé
Avatar de ferber ferber
Membre émérite
le 19/10/2012 8:07
Citation:
Envoyé par mekal Voir le message
et tu a une demo du player ayant moi meme fait un player en js j'aurait voulu comparer le js generé et aussi le dart créé
personnellement je serrais plus intéressé par une comparaison des temps de développement J'ai télécharger le pack Dart, L'auto-complétion marche bien, la recherche de membre aussi, ainsi que l'indispensable bouton "aller a la définition". Au première abord certaine chause sont assez déstabilisante genre
Code :
12345678910
String ToString()
 =>"on dirais pas mais je suis une function";

au lieu de 
toString=function(){ return "on dirais pas mais je suis une function";}

ou de 

public function toString():String{ return "on dirais pas mais je suis une function";}
de plus j'ai trouvé intérréssant de pouvoir définir une implémentation par défaut pour une interface.

J'ai été surpris que la surcharge d'opérateur soit disponible.

Et j'ai aussi été surpris de voir le nombre de class déjà existante.

Ils ont bien bossé.

Le seul point négatif et l'ide basé sur éclipse( que je trouve affreusement lent ).

Sinon je doit avouer que le langage me plait.
Mais sachant que FF MS Apple vont tous faire pour empêcher le développement du projet, ça donne pas envie d'investir même si on peut exporter en js.
Si google et le seul mécènes du projet ça peut vite tourner cour.
Dart risque potentiellement de devenir un flash2 ou silverlight2 dans le sens ou adobe et Ms sont en train de ce désengager de ces projets laissant les utilisateurs du produit le bec dans l'eau a plus ou moins long terme au grand plaisir du W3C.
Et je n'ai pas envie d’apprendre un nouveau langage et un nouveau framework pour le coup en sachant que la communauté open source &W3c vont tout faire pour que le langage finisse à la poubelle sans même se pauser de questions ( voir le wiky anglais de dart ).

Il vaut mieux parier sur des technologies côté serveur indépendante des navigateurs qui produises du code html basique ( paragraphe, link, bold,italic,img ) code simple et donc : multiplate-forme.
Avatar de kimjoa kimjoa
Membre éprouvé
le 20/10/2012 16:52
Citation:
et tu a une demo du player ayant moi meme fait un player en js j'aurait voulu comparer le js generé et aussi le dart créé
J'aime bien dart, le langage est assez séduisant, mais il s'éloigne trop du javascript pour que la compilation soit clean. Il ont fait des progrès depuis novembre dernier, mais c'est pas encore ça. Quelques bench , mais qui date.... Les prochains bench seront sans doute plus satisfaisant. J'ai compilé l'exemple fournit par l'éditeur
Code :
12345678910111213141516
import 'dart:html';

num rotatePos = 0;

void main() {
  query("#text")
    ..text = "Click me!"
    ..on.click.add(rotateText);
}

void rotateText(Event event) {
  rotatePos += 360;
  query("#text").style
    ..transition = "1s"
    ..transform = "rotate(${rotatePos}deg)";
}
A noter les deux points, vraiment pratique !

Le résultat est un fichier de 127 ko ....
Mais c'est pas vraiment le poids qui pose problème, la base du code js servant au binding sera dilué par la taille du projet.
En examinant vite fait le code produit, je me suis rendu compte qu'un appel de fonction en dart, pouvait correspondre en javascript à 4 ou 5 appels voir plus.
De ce point de vue typescript s'en sort bien mieux avec une génération vraiment très propre.
Avatar de PasteFinger PasteFinger
Nouveau Membre du Club
le 20/10/2012 23:04
Pour que Dart soit adopté, il faudrait qu'il offre des performances très supérieures à Javascript !
Avatar de _skip _skip
Expert Confirmé Sénior
le 21/10/2012 9:22
Ce sera surement possible s'il tourne dans dartvm car dart n'a pas toute une série des biais de javascript qui rendent le "jit" difficile à optimiser.

En revanche, traduit en javascript... Je comprend que ça devra s'améliorer. Même si je pense que la vitesse d'exécution ne repose pas forcément sur le code lui-même, la plupart des manipulations de tous les jours (sauf bien sûr les jeux, les canvas) sont déjà rapides, donc même 2-5 fois plus lentes ce serait encore plus rapide que l'utilisateur. Sans compter que les "opérations lentes" comme les appels ajax iront toujours à la même vitesse.

Je suis pas sûr que ce soit bloquant cette affaire de performance JS moins bonne si de l'autre côté on gagne suffisamment en maintenance et en productivité.
Avatar de pierre-y pierre-y
Membre du Club
le 23/10/2012 16:38
Bonsoir,

En lisant la discussion j'ai deux questions qui me tique :

premièrement : Est ce qu'une modification en profondeur de javascript est réellement nécessaire?

Deuxièmement : si oui, pourra t'elle voir le jour autrement que par un pluging (un peut comme unity3d ou adobe player mais libre) par exemple étant sonné la concurrence que les firme se livre entre elle pour imposer leur programme? Je vois mal Dart par exemple être accepté sans bronché par microsoft et apple et ceci même dans l'hypothèse ou il serait parfait.

Bonne soirée,
Avatar de rt15 rt15
Membre éprouvé
le 23/10/2012 17:42
Citation:
Envoyé par pierre-y Voir le message
premièrement : Est ce qu'une modification en profondeur de javascript est réellement nécessaire?
Le javascript a été conçût pour ajouter un soupçon de dynamicité au HTML. Le problème est qu'il est utilisé de façon intensive de nos jours, dans des applications de plus en plus complexes et sur des appareils plus ou moins puissants comme les smartphones. Il s'agit d'un langage de script et de haut niveau donc ses performances à l'exécution ne pourraient pas être pires, malgré les efforts des navigateurs. Côté développement, son modèle objet original déroute certains développeurs, et il n'est pas du tout rigoureux.

Cela dit l'approche de google et M$ ne me paraissent pas optimale, que ce soit à ajouter un autre moteur de script au navigateur (Pour exécuter directement du dart), ou pour générer du javascript à partir d'un autre langage.

Côté navigateur, il serait bien plus efficace et optimisé qu'ils exécutent un langage intermédiaire type byte code, facilement compilable en langage machine du processeur de la machine.

Côté développeur, on devrait pouvoir utiliser le javascript, pourquoi pas... Mais pas seulement. Tout autre langage, par exemple plus stricte, devrait pouvoir être utilisé aussi. Et tout ces autres langages pourraient se compiler vers un byte code au final envoyé au navigateur.

En fin de compte cela revient au modèle java, compile once, run everywhere. Et ce modèle à justement beaucoup plus de sens dans un navigateur que pour des logiciels desktop, où il est souvent intéressant voir obligatoire d'intégrer le logiciel à l'OS.

Citation:
Envoyé par pierre-y Voir le message
Deuxièmement : si oui, pourra t'elle voir le jour autrement que par un pluging (un peut comme unity3d ou adobe player mais libre) par exemple étant sonné la concurrence que les firme se livre entre elle pour imposer leur programme? Je vois mal Dart par exemple être accepté sans bronché par microsoft et apple et ceci même dans l'hypothèse ou il serait parfait.
Évidement, pour remplacer le javascript dans tous les navigateurs, ou du moins apporter une nouvelle toute nouvelle version de javascript, il faut que rapidement, les principaux navigateurs (Chrome, Firefox, Internet Explorer, Opera, Safari) supporte cette nouvelle fonctionnalité.

Ce qui pourrait aider, bien sûr, c'est que cette nouvelle technologie soit poussée par le w3c... On voit ce que ça donne avec le HTML5.

Mais il ne faut pas être négatif : si la techno commence à devenir à la mode (Ce qui veut pas dire qu'elle est bonne), elle peut tout à fait être prise en charge relativement rapidement. Prenons le cas de javascript lui même qui vient de netscape ou de XMLHttpRequest et donc AJAX qui vient de internet explorer.
Avatar de Uther Uther
Expert Confirmé Sénior
le 23/10/2012 18:43
Citation:
Envoyé par pierre-y
premièrement : Est ce qu'une modification en profondeur de javascript est réellement nécessaire?
Tout dépend ce que l'on veut en faire :
- Pour continuer a faire de simple manipulation du DOM : probablement pas.
- Pour faire des applications complexes en offrant un minimum de cadrage aux programmeurs : oui, mais les surcouches déjà existantes comme GWT, Coffescript, Typescript, ... permettent déjà de le faire.
- Pour faire des applications avec des performances comparables au natif : oui.

Citation:
Envoyé par pierre-y
Deuxièmement : si oui, pourra t'elle voir le jour autrement que par un pluging (comme adobe player mais libre) par exemple étant sonné la concurrence que les firme se livre entre elle pour imposer leur programme? Je vois mal Dart par exemple être accepté sans bronché par microsoft et apple et ceci même dans l'hypothèse ou il serait parfait.
C'est en effet là tout le problème. Google avec son travail solitaire va avoir du mal à convaincre les autres acteurs du web d'y adhérer.

Quant au plug-in je pense que ça serait difficilement défendable car c'est contraire à la tendance actuelle qui est au contraire de se débarasser des plugins pour se contenter du standard.
Avatar de Cyrano Cyrano
Membre du Club
le 23/10/2012 19:23
Citation:
Envoyé par pierre-y Voir le message
premièrement : Est ce qu'une modification en profondeur de javascript est réellement nécessaire?
J'avais déjà donné un élément de réponse sur ce point l'an dernier :
Citation:
Envoyé par Cyrano Voir le message
...Le grand truc actuellement, c'est le SaaS et Google n'est pas en reste à ce chapitre avec entre autres choses les Google Docs. Mais ce sont des application qui font appel à du JavaScript et les projets d'évolution des applications chez Google doivent commencer à titiller les limites du JavaScript. Donc l'idée d'un nouveau langage, outre des performances meilleures, présentera à n'en pas douter des possibilités inenvisageables en JavaScript.
Et comme vient de le souligner également Uther, pour de simples manipulations de base, c'est un peu sans intérêt, donc ça ne concernera pratiquement aucun petit site perso.

Citation:
Envoyé par pierre-y Voir le message
Deuxièmement : si oui, pourra t'elle voir le jour autrement que par un pluging (un peut comme unity3d ou adobe player mais libre) par exemple étant sonné la concurrence que les firme se livre entre elle pour imposer leur programme? Je vois mal Dart par exemple être accepté sans bronché par microsoft et apple et ceci même dans l'hypothèse ou il serait parfait.
Là, ça va dépendre des éditeurs de navigateurs. Il y a fort à parier que ni Microsoft ni Apple ne vont se précipiter dans la voie ouverte par Google. Par ailleurs, j'ai cru comprendre que Microsoft travaillerait actuellement sur un système similaire, mais bien entendu propre à Microsoft. Donc ça risque d'être une nouvelle compétition.
Ça risque aussi de dépendre pas mal des éditeurs de solutions en ligne et des besoins techniques que ça représente. Si les applications proposées présentent des fonctionnalités qui ne peuvent fonctionner qu'avec un langage comme Dart, on peut penser qu'ils pousseront à la roue pour que les navigateurs intègrent Dart, à moins que les versions générée en JavaScript soient vraiment encore assez efficaces, mais ça j'y crois moins. Ce qui décidera donc les uns et les autres à se tourner vers une solution commune, ce seront à mon avis d'abord les utilisateurs qui demanderont de plus en plus de fonctionnalités dans les applications en ligne, fonctionnalités qu'il sera difficile de construire en JavaScript sans créer des usines à gaz invraisemblables.

Le succès de Dart pourrait passer par Mozilla pour déclencher le mouvement : c'est aussi une question de popularité des navigateurs utilisés sur le marché et ce qu'en font les utilisateurs. Or avec Chrome et Firefox en locomotive, si Dart fonctionne vraiment bien, ça pourrait inciter les autres à suivre et à implémenter Dart dans leur propre navigateur, donc en fin de compte, Internet Explorer, Opera et Safari pourraient un jour intégrer Dart... on peut rêver
Avatar de Uther Uther
Expert Confirmé Sénior
le 23/10/2012 21:30
Citation:
Envoyé par Cyrano Voir le message
Le succès de Dart pourrait passer par Mozilla pour déclencher le mouvement
N'y compte pas trop.
Mozilla a clairement indiqué qu'il ne prévoyait pas de supporter Dart. Ils comptent se limiter à améliorer les performances de Javascript.
Avatar de ugo-sans-h ugo-sans-h
Membre du Club
le 24/10/2012 23:14
Citation:
Envoyé par mekal Voir le message
et tu a une demo du player ayant moi meme fait un player en js j'aurait voulu comparer le js generé et aussi le dart créé
Je n'est pas vraiment de version stable, c'était surtout un "test".
j'essai actuellement de coder un projet perso avec Symfony et utiliser Dart en remplacement de Js afin de vraiment comparer la différence en mode projet.

Citation:
Envoyé par rt15 Voir le message
[...]
Tout autre langage, par exemple plus stricte, devrait pouvoir être utilisé aussi. Et tout ces autres langages pourraient se compiler vers un byte code au final envoyé au navigateur. [...]
J'aime beaucoup cette idée, c'est vraiment très pertinent.

Pour ma part, ce que j' apprécie dans le projet Dart en lui même, c'est la question de fond qu'il soulève. D'un côté dart, de l'autre TypeScript, ainsi que toutes les librairies JS (jQuery, YUI...), révèle que JavaScript atteint ses limites.

Javascript n'est pas un langage conçu pour le développement de Wep App. Donc soit celui-ci reste dans sa trame actuelle (petite manipulation de DOM, Ajax, deux trois autres interactions), soit il est amené à évoluer en profondeur.

Je ne pense pas que celui-ci soit amené à beaucoup évolué, et si c'est le cas, j’espère vraiment que ça ne prendra pas 7 ans comme pour l'HTML5....

Les point positif de Dart, pour ma part, et sa modernité, certes une nouvelle Api est à apprendre, mais un langage objet, c'est un langage objet, ils ont tous les mêmes bases, la même approche, c'est un réel confort pour le développeur.
Gagner en homogénéité c'est gagner en maintenabilité et productivité, aujourd'hui je fais encore beaucoup de JavaScript, mais plus le temps passe et plus j'ai l'impression de le subir. Je conçois difficilement l'idée de développer des milliers de lignes pour une application avec un langage aussi permissif, je ne parviens pas à faire suffisamment confiance à ce langage.
Avatar de LLB LLB
Membre Expert
le 25/10/2012 0:12
Citation:
Envoyé par rt15 Voir le message
Côté navigateur, il serait bien plus efficace et optimisé qu'ils exécutent un langage intermédiaire type byte code, facilement compilable en langage machine du processeur de la machine
En vrai, ça n'apporte pas grand-chose. Si tu veux, tu peux aussi considérer Dart comme un bytecode et avoir ton langage préféré qui compile vers Dart. Les raisons détaillées se trouvent là : http://www.dartlang.org/articles/why-not-bytecode/
(si besoin, je peux expliquer davantage)
Avatar de Uther Uther
Expert Confirmé Sénior
le 25/10/2012 8:54
J'ai lu cet article mais il se base principalement sa critique sur le bytecode Java, qui même s'il est actuellement utilisé par plusieurs langages, a clairement été conçu a l'origine dans l'optique de supporter seulement Java.
Si on compare a un bytecode conçu pour être utilisé par de multiples langages, par exemple le LLVM IR, la majorité des problèmes avancés disparaissent.

Si on considère Dart comme un bytecode (d'ailleurs autant le faire avec Javascript), on tombe justement en plein dans les problèmes mentionnés dans l'article, et en plus on oblige l'interpréteur a se farcir une analyse lexicale/syntaxique supplémentaire ainsi qu'une bonne partie des optimisations.
Avatar de LLB LLB
Membre Expert
le 25/10/2012 14:18
Citation:
Envoyé par Uther Voir le message
Si on compare a un bytecode conçu pour être utilisé par de multiples langages, par exemple le LLVM IR, la majorité des problèmes avancés disparaissent.
Mais d'autres apparaissent.

On a un choix à faire : veut-on un bytecode bas-niveau (LLVM) ou plus haut-niveau (.NET, JVM) ?

Si on part sur du bas-niveau, on a un système de typage très simple, pas d'orienté-objet, pas de convention d'appel définie (chaque compilo peut choisir la sienne), etc. C'est très flexible et on peut avoir beaucoup de langages qui compilent vers ce byte-code. Chaque langage construit son système de typage par dessus, etc. J'aime beaucoup LLVM, mais ça détruit quasiment toute interopérabilité entre les langages. Si j'écris une bibliothèque dans un langage, comment fera quelqu'un d'autre pour l'utiliser dans un autre langage ? Ce n'est pas possible si les deux langages ont des conventions d'appel différentes. Comment passer un argument à une fonction, si les deux langages n'ont pas le même système de typage, si chaque langage doit définir ses vtables pour implémenter l'objet, etc. ? Même les types de base peuvent être implémentés différemment, les entiers (natifs, 64 bits, bigints ?), les strings (utf-8, utf-16, terminés par un 0 ?), les flottants (simple, double, decimal 128 bits ?). Et qu'en est-il du format des exceptions ?
Mais en fait, si on veut interagir avec le navigateur, le dom, les fonctions prédéfinies, il faut un truc un peu plus haut-niveau que LLVM.

Prenons .NET (j'ai travaillé sur plusieurs compilos .NET) : ça a été conçu pour être multi-langage. Oui, c'était un objectif depuis le tout début. Ils ont plutôt bien réussi en faisant du bytecode orienté-objet d'assez haut-niveau : avec le système de type commun, on peut passer des objets d'un langage à l'autre (bon, ça dépend aussi du langage, certains ajoutent une trop grosse surcouche), hériter d'une classe définie dans un autre langage, récupérer une exception lancée dans un autre langage, etc. C'est en quelque sorte ce qu'il faudrait pour un bytecode commun dans un navigateur. Mais ce n'est pas parfait, certains langages sont difficiles à implémenter (Haskell, etc.), et on retrouve les arguments contre le bytecode Java.

Citation:
Envoyé par Uther Voir le message
Si on considère Dart comme un bytecode (d'ailleurs autant le faire avec Javascript), on tombe justement en plein dans les problèmes mentionnés dans l'article, et en plus on oblige l'interpréteur a se farcir une analyse lexicale/syntaxique supplémentaire ainsi qu'une bonne partie des optimisations.
L'analyse syntaxique est rapide. La majorité des optimisations sont faites dans la VM de toute façon. Par exemple, les compilos pour .NET (C#, F# et et probablement les autres aussi) n'optimisent quasiment rien en pratique, c'est le JIT qui s'occupe de l'inlining, de dérouler les boucles, etc. Pour LLVM, c'est pareil : les développeurs de compilo utilisent LLVM en bonne partie pour ne pas avoir à faire toutes ces optimisations classiques et indépendantes du langage.
Le gain de temps me semble donc assez négligeable.

Ah, et puis : débugguer du code dans le navigateur est beaucoup plus simple quand le navigateur a accès au code, qu'il comprend le code et les types utilisés, et peut proposer une console pour exécuter du code. Note aussi que la fonction eval est difficile à offrir quand le navigateur ne connait que le bytecode.
Avatar de rt15 rt15
Membre éprouvé
le 25/10/2012 16:46
Avoir des librairies avec une interface de bas niveau, c'est au contraire un avantage fondamental quand on souhaite pouvoir les attaquer facilement depuis n'importe quel langage.
Faisons le parallèle avec le desktop. Si M$ avait choisit que les API de Windows soient uniquement en .NET... La JVM serait par exemple assise au dessus d'une autre VM ! Les objets java devraient être traduis vers des objets .NET au sein de la JVM... Ça ferait un de ces boxons. Et imaginez les perfs... D'ailleurs on y arrive presque avec WinRT qui veut imposer du COM v2.0.

Autre exemple : combien d'appli C, C++ ou java appel des librairies .NET ?? Ça se voit jamais. Le plus simple dans ces cas là est bien souvent de passer par des sockets, et là on parle plus vraiment de librairie... Mais combien d'appli .NET appellent des librairies en C ? Des tas. Certaines appli .NET sont bourrées de PInvoke. Pour le java c'est globalement la même chose. On a parfois besoins de faire des dll et de les appelées par JNI quand la JVM ne propose pas ce qui est souhaité. Mais créé des objets java depuis le C se fait aussi très rarement quoique ce soit possible, mais lourd. Bilan, les librairies avec une ABI de bas niveau sont largement utilisées, celle avec un ABI de haut niveau le sont nettement moins.

Alors oui, le DOM devrait à mon sens être proposé sous formes de fonctions très bas niveau. Libre à chacun de construire tout ce qu'il veut par dessus. C'est le rôle d'une librairie de haut niveau de cacher ces détails. Libre à chacun d'utiliser ou d'écrire une surcouche adaptée au langage. Combien de wrappers vers des librairies bas niveau C sont dans la nature ? Combien de sandwichs à n'en plus finir dans les logiciels actuel ? Combien y a-t-il de couche dans une techno comme XNA ? Et généralement les couches bas niveau sont en bas, les couches haut niveau sont en haut. Le navigateur est supposé être la base, il doit proposer une couche bas niveau.

Bien sûr resterait le problème qu'une librairie écrite en "Java pour browser" ne serait pas utilisable depuis du "javascript pour browser" à l'opposé du .NET ou une librairie écrite en VB.NET est utilisable depuis du C#... Alors, oui, là il faut que les concepteurs de ses langages se mettent d'accord sur une ABI. Mais ils sont libres de le faire comme il le souhaite, ce n'est pas le byte code qui va les limiter avec un entier signé sur 32 bits et pas autre chose.

Ensuite, concernant l'analyse syntaxique rapide...

En règle générale, une compilation complète se fait en une série d'étape :
Le source code en lui même est "lu" par un analyseur lexical. Cet analyseur ne fait que transformer le texte en "tokens" qu'il envoie ce qu'il lit à un parser. Cette partie là est facilement implémentable à l'aide d'équivalent de lex et yacc. Ce qui ne veut pas dire que c'est rapide à l'exécution. En effet, il peut y avoir tout bêtement des commentaires, des noms de variables à rallonges, les instructions sont désordonnées, les données tel que le texte sont mélangées aux instructions d'exécutions, il y a des tas de fichiers... Bref, un code source, c'est pas déjà pas très facile à lire.

Ensuite, le boulot du parser va généralement être de construire un arbre lexical. Cet arbre représente le déroulement des instructions.

Toute cette première partie du compilo est dans le cas de gcc, ce qu'on appelle un front-end. Et dans le cas de gcc, il y a différents front-end pour différents langages, avec au final souvent production d'une forme intermédiaire : un arbre lexical ou d'un genre de graph.

Ça pas ce qu'il y a de plus rapide... Car un arbre pleins de feuilles c'est assez lourd à créer et à manipuler. En général, c'est à cet étape qu'une première passe d’optimisation est fait. Par exemple, c'est là que si à un endroit il y a 3 feuilles : "2" "+" "2", il va remplacer le tout par une feuille "4". Il va aussi chercher les valeurs utilisées de manière redondante pour ne les avoir qu'une seule fois au final. C'est généralement là aussi qu'il y a détection du code mort. Bref, la plupart des optimisations sont réalisées à cette étape et elles sont tout à fait indépendante de la plateforme cible. Et je serais surpris que le compilo C# ne fasse rien de similaire avant de produire le byte code...

L'étape finale consiste souvent à générer directement le code cible à partir de l'arbre. C'est le rôle du back-end. Et là aussi, pour gcc, il y a différents back-end pour différentes plateformes.

Dans le cas ou le code cible est en fait lui aussi un code intermédiaire, à l'exécution, c'est généralement un nouveau compilo JIT qui va prendre le relais. Mais ce qu'il a à manger, c'est un byte code bien aligné, pas du source, et sur lequel les optimisations indépendantes de la plateforme ont déjà été faites.

Alors pourquoi ne pas envoyer au navigateur directement le byte code, ou au moins l'arbre de la représentation intermédiaire, déjà optimisé de manière indépendante de la plateforme ?

Les temps d'analyse du source et d'optimisation génériques ne sont dans certains cas pas du tout négligeable. Suffit de comparer les temps de compilation de X lignes de C++ avec la compilation de X lignes de C. Le back-end du compilo est probablement le même, pourtant le "haut niveau" du C++, on le sent passer.

Concernant le dernier argument sur le débogage... Pour les langage compilés, on a des débogueurs qui marche pas trop mal me semble. Pas souvent que l'on ait à déboguer du MSIL ou du byte code java. Suffit que les navigateurs permettent à un débogueur de se connecter.
Avatar de LLB LLB
Membre Expert
le 26/10/2012 12:57
Citation:
Envoyé par rt15 Voir le message
Faisons le parallèle avec le desktop. Si M$ avait choisit que les API de Windows soient uniquement en .NET... La JVM serait par exemple assise au dessus d'une autre VM ! Les objets java devraient être traduis vers des objets .NET au sein de la JVM... Ça ferait un de ces boxons. Et imaginés les perfs...
Ça ferait un boxon et ce serait lent si Windows utilisait du bytecode pour son API... donc, tu proposes d'utiliser du bytecode dans le navigateur à la place de Dart. OK.
Cela dit, la comparaison ne tient pas : dans Windows, ils ont optimisé pour les performances (dont les binaires natifs), tandis que dans un navigateur on veut de la portabilité et de la sécurité. Les perfs ne viennent qu'après. On ne veut pas envoyer de code natif au navigateur.

Citation:
Envoyé par rt15 Voir le message
En règle générale, une compilation complète se fait en une série d'étape :
Le source code en lui même est "lu" par un analyseur lexical. Cet analyseur ne fait que transformer le texte en "tokens" qu'il envoie ce qu'il lit à un parser. Cette partie là est facilement implémentable à l'aide d'équivalent de lex et yacc. Ce qui ne veut pas dire que c'est rapide à l'exécution. En effet, il peut y avoir tout bêtement des commentaires, des noms de variables à rallonges, les instructions sont désordonnées, les données tel que le texte sont mélangées aux instructions d'exécutions, il y a des tas de fichiers...
C'est une blague ?
Écris un hello world en C, compile-le. Ajoute 2000 lignes de commentaires, compile à nouveau. Tu as remarqué une différence de temps de compilation ? À moins d'être resté bloqué en 1970 ou d'avoir un problème de disque, non. Recommence ce test en ajoutant des variables à ralonge. Recommence encore en ajoutant des espaces, etc. Non, ignorer des commentaires ne prend pas de temps significatif...
D'ailleurs, les commentaires sont rarement vus, puisque les développeurs Javascript aiment minifier leur code. Et les commentaires sont supprimés non pas pour le compilateur, mais pour réduire la taille du fichier (pour le réseau).
En passant : avoir les noms de variable dans le bytecode serait utile pour le débogage.

Citation:
Envoyé par rt15 Voir le message
Toute cette première partie du compilo est dans le cas de gcc, ce qu'on appelle un front-end. Et dans le cas de gcc, il y a différents front-end pour différents langages, avec au final souvent production d'une forme intermédiaire : un arbre lexical ou d'un genre de graph.

Ça pas ce qu'il y a de plus rapide... Car un arbre pleins de feuilles c'est assez lourd à créer et à manipuler.
La construction de l'AST est triviale, et le coût est faible par rapport à tout ce que le compilo fait par la suite, qui nécessite également des graphes à construire et à manipuler.

Citation:
Envoyé par rt15 Voir le message
Il va aussi chercher les valeurs utilisées de manière redondante dans pour ne les avoir qu'une seule fois au final. C'est généralement là aussi qu'il y a détection du code mort. Bref, la plupart des optimisations sont réalisées à cette étape et elles sont tout à fait indépendante de la plateforme cible.
C'est faux. Enfin, c'est vrai pour les compilos traditionnels, mais ce n'est plus tout à fait le cas depuis les JIT.

Citation:
Envoyé par rt15 Voir le message
Et je serais surpris que le compilo C# ne fasse rien de similaire avant de produire le byte code...
Il fait quelques optimisations simplistes. C'est vrai, il simplifie les expressions triviales à ce moment là (ton 2+2=4). Cette simplification n'est pas vraiment là pour optimiser, mais parce que c'est obligatoire d'après les specs : c'est nécessaire pour afficher certains warnings et messages d'erreur. Le compilo détecte aussi le code mort, mais le but est de réduire la taille du binaire généré. D'ailleurs le JIT supprime lui aussi le code mort. Les optimisations du compilo C# restent des optimisations triviales et (à ma connaissance) ne fait pas d'optimisation cross-module.
Le compilo F# fait encore moins d'optimisations (sauf que lui sait faire de l'inlining de lambdas d'un fichier à l'autre, mais c'est vraiment une spécificité de F#).

90% des optimisations sont faites dans le JIT. Par exemple, l'inlining de fonctions se fait dans le JIT parce que 1) l'inlining se fait ou non suivant la taille des instructions générées (le compilo C# ne peut pas deviner) et 2) ça dépend de la machine cible (on inline pas la même chose en 32 bits ou en 64 bits par exemple). C'est le JIT qui déroule les boucles. C'est le JIT qui choisit s'il faut vérifier l'indice avant un accès dans un tableau (ou qui prouve que l'indice est forcément valide). C'est le JIT encore qui fait l'expansion et la spécialisation des generics.

Citation:
Envoyé par rt15 Voir le message
L'étape finale consiste souvent à générer directement le code cible à partir de l'arbre. C'est le rôle du back-end.
Oui, et c'est autrement plus coûteux que d'ignorer les commentaires ou de traiter des noms de variables à rallonge. Transformation du code en forme SSA, propagation des constantes, optimisations des boucles (fusionner deux boucles ou au contraire couper une boucle en deux), allocation des registres avec coloriage de graphe, choisir les instructions en fonction de l'architecture cible, réordonner les instructions pour améliorer le parallélisme, etc.

Si tu veux avoir un aperçu de ce que fait LLVM, voici une liste des passes : http://llvm.org/docs/Passes.html

Citation:
Envoyé par rt15 Voir le message
Alors pourquoi ne pas envoyer au navigateur directement le byte code, ou au moins l'arbre de la représentation intermédiaire, déjà optimisé de manière indépendante de la plateforme ?
Soit tu as un bytecode spécialisé, et dans ce cas ça revient presque au même que de travailler sur le langage source.
Soit tu veux un bytecode générique qui convienne à tous les langages (en vrai, ça n'existe pas) et dans ce cas tu n'as pas autant de performance qu'une VM spécialisée pour un langage.
Par exemple, LLVM est mal adapté aux langages dynamiques, d'où l'intérêt d'avoir Parrot.

Citation:
Envoyé par rt15 Voir le message
Les temps d'analyse du source et d'optimisation génériques ne sont dans certains cas pas du tout négligeable. Suffit de comparer les temps de compilation de X lignes de C++ avec la compilation de X lignes de C.
C'est un cas extrême, puisque les templates sont exécutés à la compilation et génèrent du code. Dans les autres langages, les génériques n'ont pas ce souci. Ce serait donc idiot de mettre les templates de C++ dans Dart et de les implémenter comme en C++ (c'est le boulot du JIT, ça). C# et Go sont bien plus rapides à compiler que C++.

Citation:
Envoyé par rt15 Voir le message
Concernant le dernier argument sur le débogage... Pour les langage compilés, on a des débogueurs qui marche pas trop mal me semble. Pas souvent que l'on ait à déboguer du MSIL ou du byte code java. Suffit que les navigateurs permettent à un débogueur de se connecter.
Si on résume, tu proposes qu'ils codent une VM performante et générique (ce qui n'existe pas actuellement). Ensuite, pour chaque langage, il faudrait faire un compilo qui fasse une tonne d'optimisations, une bibliothèque standard (c'est beaucoup de boulot ça) et un débogueur qui s'attache sur chaque navigateur. Tu n'as pas l'impression que ça représente 10 fois plus de boulot, pour un résultat très incertain ?
Avatar de Uther Uther
Expert Confirmé Sénior
le 22/03/2013 18:10
Je me permet de remonter le sujet, vu que l'on discutait de l’intérêt d'un bytecode commun, et que ça rentre dans le sujet.

Il semble maintenant se dégager une nouvelle voie qui semble réunir pas mal d'avantage : asm.js.

asm.js est un sous ensemble restreint du Javascript qui écarte tous les éléments complexes qui limitent les possibilités d'optimisation, comme le recours au typage dynamique.
Les interpréteurs adaptés à traiter ce type de code seront ainsi capable, de compiler de manière optimale comme un vrai bytecode. Ceux qui ne le sont pas l’exécuteront normalement.
L'idée est de permettre de faire un programme dans le langage que l'on souhaite et le compiler ça avec un compilateur de type emscriptem qui saura produire du javascript compatible asm.js.

Au final on reviens a l'idée du bytecode commun, mais on garde la compatibilité. La branche nightly de Firefox, commence déjà a supporter asm.js et les performances semblent selon, les premiers test seulement 2 fois inférieures au C. Ça parait assez encourageant.
Avatar de Cedric Chevalier Cedric Chevalier
Chroniqueur Actualités
le 11/04/2013 13:25
dart2js traduit du code Dart en JavaScript
qui serait plus performant que son équivalent idiomatique, le langage de Google évolue

Une nouvelle version du compilateur dart2js est disponible. Pour rappel, ce dernier permet de convertir en JavaScript du code Dart.

Le nouveau dart2js permet de produire du code JavaScript plus compact et rapide grâce notamment à une innovation inédite appelée « global type inferencing ». Avec cette dernière, le compilateur en analysant entièrement du code Dart, produit un équivalent JavaScript plus compact et performant, dans lequel sont éliminées les lignes contenant les mots clés « Bailout », « typeof » ajoutées par l’ancien compilateur. De plus, ce nouveau compilateur change les boucles While en boucles For et les appels de fonctions sont remplacés par les champs d’accès.

Par ailleurs, on note également que dart2js gère mieux les dépassements de capacité de liste. En effet, là où JavaScript retourne une valeur indéfinie, Dart lève une exception qui sera utilisée par le compilateur pour générer un code qui avertirait le programmeur si celui-ci voulait avoir accès à un élément d’une liste de rang supérieur à sa taille totale.

En outre, des bancs d’essai ont été réalisés avec du code JavaScript généré par ce nouveau compilateur et leur équivalent idiomatique dans le moteur JavaScript V8 de Google. Il en ressort que le code généré par le compilateur est un poil plus performant que son équivalent idiomatique.


Nicolas Geoffray, contributeur du projet dart2js montre dans une vidéo de nombreux exemples de code Dart traduit en JavaScript par l’ancien compilateur et le nouveau avec son innovation inédite.


L’objectif de Google avec Dart est de proposer une alternative au langage JavaScript, qui offre la même flexibilité que celui-ci, mais qui se distingue par son typage fort et optionnel. Il est vu comme un JavaScript-killer. Mozilla propose également asm.js, un sous-ensemble restreint du JavaScript qui écarte tous les éléments complexes qui limitent les possibilités d'optimisation. Quant à Microsoft, TypeScript a été développé comme un sur-ensemble de JavaScript pour l’optimiser.

Preuve que JavaScript a de gros manquements, mais demeure cependant un langage clé ?

Le projet Dart sur GitHub

Source : Google
Avatar de jmnicolas jmnicolas
Membre chevronné
le 11/04/2013 16:41
Citation:
Envoyé par Cedric Chevalier Voir le message
De plus, ce nouveau compilateur change les boucles While en boucles For
Je saisis pas en quoi une boucle for serait plus performante qu'une boucle while c'est pas du tout le même usage

Si quelqu'un veut bien m'expliquer.
Avatar de _skip _skip
Expert Confirmé Sénior
le 11/04/2013 16:59
En fait, je ne sais pas si ce point précis est une question de performance. Je pense surtout au fait qu'avant une boucle for en dart était réécrite sous forme de while avec la syntaxe :

Code :
1
2
3
4
5
6
while(true) {

  if( [conditionSortie] ) {
     break;
  }
}
Ca pouvait être assez peu lisible, maintenant est-ce que question performance ça change réellement? Je sais pas, cela dépendrait surtout de l'intelligence de l'interpréteur / Jitter...

EDIT: Je viens de voir qu'il y a un exemple précis sur le site de dart où on voit une transformation selon le nouveau modèle comparé à l'ancien, et c'est formulé de manière plus performante.
Avatar de LSMetag LSMetag
Membre régulier
le 11/04/2013 21:04
Enfin une version comparable à du natif !
Je vais de ce pas m'y mettre !
Avatar de Uther Uther
Expert Confirmé Sénior
le 12/04/2013 0:54
Justement non, on voit bien que le dart compilé en javascript a des performances inférieures au Dart classique, qui est lui même inférieur à du C/C++
Avatar de LSMetag LSMetag
Membre régulier
le 12/04/2013 7:56
Je voulais dire "comparable à du Javascript natif".

Car mon but, c'est clairement de ne plus développer en Javascript.
Avatar de Hinault Romaric Hinault Romaric
Responsable Actualités
le 15/04/2013 15:21
Dart : Google sort une nouvelle version de Dart Editor
l’outil de développement pour son « JavaScript-killer » introduit une bibliothèque WebGL dédiée

Mise à jour du 15/04/2013

Google vient de publier une nouvelle version de Dart Editor.

À titre de rappel, Dart Editor est un environnement de développement open source léger, pour l’édition de code, le débogage et l’exécution d’applications Dart.

Il comprend un éditeur de code pour Dart avec coloration syntaxique, autocomplétion, etc. le SDK (kit de développement) Dart et Dartium (une version modifiée de Chrome qui dispose d’une machine virtuelle Dart pour le test des applications).

La nouvelle version de Dart Editor introduit comme fonctionnalité phare une bibliothèque dédiée pour WebGL, la technologie d’affichage 3D pour les navigateurs Web.


L’EDI propose désormais une nouvelle option pour désactiver l’activation automatique de la complétion de code. L’aperçu de l’application fonctionne dorénavant avec le nouveau moteur d’analyse. Ce nouveau moteur d’analyse apporte plusieurs améliorations de performances et une meilleure gestion de la mémoire.

En plus de ces nouveautés, des modifications ont été apportées à la plateforme, notamment la suppression de la méthode List.addLast, le déplacement des types WebGL de dart:html vers dart:web_gl, l’ajout d’un argument optionnel pour la méthode StrinkSink.writeAll et bien plus.


Pour rappel, Dart est un langage de programmation structuré pour le Web, basé sur les classes et optionnellement typé. Le langage est proposé comme une alternative à JavaScript.

Le compilateur dart2js serait capable de traduire du code Dart en JavaScript, qui serait plus performant que son équivalent idiomatique.

Télécharger Dart Editor

Source : Le site du projet

Et vous ?

Avez-vous adopté le nouveau langage de Google ?

Pensez-vous qu'il pourra pousser JavaScript vers la sortie ?
Avatar de BPiero BPiero
Membre confirmé
le 17/04/2013 19:11
Avez-vous adopté le nouveau langage de Google ?

non

Pensez-vous qu'il pourra pousser JavaScript vers la sortie ?

non
Avatar de r0d r0d
Expert Confirmé Sénior
le 18/04/2013 14:45
J'ai parcouru cette passionnante discussion, et j'y ai lu beaucoup de mal à propos de javascript. Je ne connais rien à javascript, ni au développement web en fait, mais je suis curieux de savoir pourquoi javascript a si mauvaise réputation chez les développeurs alors qu'il est tant utilisé. Quelqu'un pourrait me faire un briefing?
Avatar de CapFlow CapFlow
Membre régulier
le 18/04/2013 16:39
Citation:
Envoyé par r0d Voir le message
J'ai parcouru cette passionnante discussion, et j'y ai lu beaucoup de mal à propos de javascript. Je ne connais rien à javascript, ni au développement web en fait, mais je suis curieux de savoir pourquoi javascript a si mauvaise réputation chez les développeurs alors qu'il est tant utilisé. Quelqu'un pourrait me faire un briefing?
En faite ça dépend des développeurs, et c'est un peu la même routine ... je pourrais détester Lua et un autre l'adorer par exemple.

Ces développeurs qui n'aiment pas javascript, c'est parce qu'ils lui trouvent des lacunes. Du moins, certaines de ces lacunes n'en sont pas : ces développeurs préfèrent tel ou tel système d'autre(s) langage(s) (exemple : il y en a qui préfèrent les classes au prototypage).
D'autres fois, c'est un défaut un peu "bancal" : le JavaScript ne dispose pas nativement, à proprement parler, d'héritage comme en PHP, il faut le faire autrement (des méthodes sont indiqués en faisant une petite recherche google ...).

D'autres encore n'aiment pas la syntaxe, le typage etc ...

En bref, comme je l'ai dit, c'est plus selon le goût qu'autre chose. Le langage à aussi des vraies lacunes, mais pas autant que ça.

Edit : il faut rajouter que la plupart des développeurs javascript utilisent jQuery, pour aller plus vite, que ce soit plus pratique ... enfin bon, il y a des frameworks/librairies qui peuvent aider à "s'adapter" au langage aussi.
Avatar de Loceka Loceka
Expert Confirmé
le 18/04/2013 17:25
Pour moi javascript a mauvaise presse pour les mêmes raisons que PHP : c'est un langage grand public et permissif, ce qui fait que pas mal de "pages" javascript sont bourrées d'erreur et que ça peut être une horreur à reprendre/maintenir.

Donc ce n'est pas propre au langage (la plupart des langages de scripts sont tout aussi permissifs) mais plutôt à son succès.
Avatar de Uther Uther
Expert Confirmé Sénior
le 18/04/2013 19:00
Citation:
Envoyé par r0d Voir le message
J'ai parcouru cette passionnante discussion, et j'y ai lu beaucoup de mal à propos de javascript. Je ne connais rien à javascript, ni au développement web en fait, mais je suis curieux de savoir pourquoi javascript a si mauvaise réputation chez les développeurs alors qu'il est tant utilisé. Quelqu'un pourrait me faire un briefing?
S'il est si utilisé, même par les gens qui le détestent, comme moi, c'est avant tout parce que c'est le seul langage qui peux être utilisé pour exécuter du code coté client, sur tous les navigateurs, sans avoir recours à un plugin.

Après il a des avantages, comme sa relative simplicité de prise en main, son approche dynamique qui lui permet manipuler facilement le contenu d'une page Web.
Mais si on veut faire une application lourde, je ne le conseillerais vraiment pas. C'est certes faisable en Javascript, mais des langages plus structurants et performants comme le C++, Java, ... me paraissent clairement plus adaptés.
Avatar de BPiero BPiero
Membre confirmé
le 04/05/2013 10:59
Citation:
Envoyé par r0d Voir le message
J'ai parcouru cette passionnante discussion, et j'y ai lu beaucoup de mal à propos de javascript. Je ne connais rien à javascript, ni au développement web en fait, mais je suis curieux de savoir pourquoi javascript a si mauvaise réputation chez les développeurs alors qu'il est tant utilisé. Quelqu'un pourrait me faire un briefing?
JS est très différents des autres langages donc déroutant pour beaucoup. D'une apparente simplicité au départ il se révèle ensuite déroutant, car il ne se comporte pas comme l'a prévu le développeur. Cependant, cette apparente faiblesse (voir complexité inutile) se révélera être d'une puissance redoutable pour le développeur qui est prêt a réapprendre ce qu'il croyait savoir sur la programmation. Bien sûr beaucoup vont me moinser (, mais je m'en fout, ça ne m’empêchera pas de dire la vérité), car ils ne sont pas prêts a admettre qu'un langage de script permissif et simple d'accès au départ puisse être puissant. Malheureusement pour eux, le JS devient de plus en plus omniprésent, donc ils vont être forcés à terme d'évoluer ou d’arrêter le développement (ou c'est peut-être pour ça qu'ils vont me moinser? comme toujours je préfère dire ce que je pense plutôt que d'éviter les moins, question d'intégrité). Pour répondre a ta question, c'est donc à cause d'un orgueil mal placé de certains devs que le JS a si mauvaise réputation alors qu'il est tant utilisé. Si tu t'intéresse à JS, alors j'ai un conseil, fait des tutos jusqu'au bout, pratique un minimum (disons qu'il y a une sorte de cap à franchir), et les joies du JS seront tiennes.
Piero
Avatar de madfu madfu
Membre éclairé
le 04/05/2013 14:45
Citation:
Malheureusement pour eux, le JS devient de plus en plus omniprésent, donc ils vont être forcés à terme d'évoluer ou d’arrêter le développement
C'est vrai que le JS devient omniprésent, c'est vrai que c'est un langage difficile, c'est vrai que c'est un langage puissant permissif et tout ça en même et c'est tellement vrai qu'avec le temps on voit fleurir un peu partout des générateurs de JS (coffeescript, dart etc), des bibliothèques d'abstraction pour simplifier la création de classes, y'a toute une réflexion sur asm.js, je connais même un guru javascript qui m'avoue générer son JS à partir de code coffeescript, tellement plus rapide et optimisé et je le comprend, alors effectivement la mort du JS c'est pas pour demain, mais je pense qu'on écrira de moins en moins de JS directement avec le temps, un peu comme quand l'assembleur a laissé peu à peu la main à des langages haut niveau, en tout ça fait un bail que j'ai pas démarré un projet conséquent directement en JS et...qu'est ce que ça fait du bien
Avatar de Uther Uther
Expert Confirmé Sénior
le 06/05/2013 8:30
Citation:
Envoyé par BPiero Voir le message
Cependant, cette apparente faiblesse (voir complexité inutile) se révélera être d'une puissance redoutable pour le développeur qui est prêt a réapprendre ce qu'il croyait savoir sur la programmation. Bien sûr beaucoup vont me moinser (, mais je m'en fout, ça ne m’empêchera pas de dire la vérité), car ils ne sont pas prêts a admettre qu'un langage de script permissif et simple d'accès au départ puisse être puissant.
Tout dépend la définition que l'on se donne de "puissant", car au premier abord, ça ne veux pas dire grand chose.

Personnellement des que quelqu'un me parle d'un langage en me disant qu'il est puissant, j'ai peur. Car en général, il entend que le langage leurs évite de réfléchir à certains problèmes par magie, ce qui finit généralement par ce traduire par des performance mauvaises, parce que la magie ça a un coût, ou des comportement déroutants, car la magie, ça a ces limites.
Bref si on veux aller dans le complexe on se retrouve a apprendre tout le comportement que la magie essayait de cacher et on fini par ce retrouver avec quelque chose d'encore plus complexe que le problème initial.

Citation:
Envoyé par BPiero Voir le message
Malheureusement pour eux, le JS devient de plus en plus omniprésent, donc ils vont être forcés à terme d'évoluer ou d’arrêter le développement (ou c'est peut-être pour ça qu'ils vont me moinser? comme toujours je préfère dire ce que je pense plutôt que d'éviter les moins, question d'intégrité).
C'est le problème le plus énervant de JS. On est obligé de l'utiliser (du moins dans un navigateur) non pas parce que c'est un bon langage, mais parce que l'on a pas le choix.
Quand je fais une application classique, c'est quand même bien agréable de pouvoir choisir le langage le plus adapté. Heureusement, maintenant, il y a des langages qui compilent vers Javascript, avec même des performances supérieure à du Javascript qui aurait été fait main, ce qui en dit long sur la "puissance" du langage.
Avatar de _skip _skip
Expert Confirmé Sénior
le 06/05/2013 9:29
Citation:
Envoyé par Uther Voir le message
Quand je fais une application classique, c'est quand même bien agréable de pouvoir choisir le langage le plus adapté. Heureusement, maintenant, il y a des langages qui compilent vers Javascript, avec même des performances supérieure à du Javascript qui aurait été fait main, ce qui en dit long sur la "puissance" du langage.
Perso ça me fait penser que dans un monde idéal, le javascript ne serait pas un langage mais un bytecode du style de celui qui est avalé par la JVM. Càd des opérations simples, moins difficiles à implémenter et à optimiser pour les browsers et des langages qui compilent vers ce bytecode commun.

Parce que de fait, c'est à cela qu'on vient avec des dart2js, des asm.js, des coffeescript et autre. Bientôt la seule vraie différence ce sera qu'au lieu de compiler vers du bytecode, on le fera vers un sous-ensemble optimisé de javascript.
Avatar de madfu madfu
Membre éclairé
le 06/05/2013 12:50
Citation:
Parce que de fait, c'est à cela qu'on vient avec des dart2js, des asm.js, des coffeescript et autre. Bientôt la seule vraie différence ce sera qu'au lieu de compiler vers du bytecode, on le fera vers un sous-ensemble optimisé de javascript.
+1000
Avatar de BPiero BPiero
Membre confirmé
le 07/05/2013 12:53
Citation:
Envoyé par Uther Voir le message
Tout dépend la définition que l'on se donne de "puissant", car au premier abord, ça ne veux pas dire grand chose.

Personnellement des que quelqu'un me parle d'un langage en me disant qu'il est puissant, j'ai peur. Car en général, il entend que le langage leurs évite de réfléchir à certains problèmes par magie, ce qui finit généralement par ce traduire par des performance mauvaises, parce que la magie ça a un coût, ou des comportement déroutants, car la magie, ça a ces limites.
Bref si on veux aller dans le complexe on se retrouve a apprendre tout le comportement que la magie essayait de cacher et on fini par ce retrouver avec quelque chose d'encore plus complexe que le problème initial.
Ce que je trouve puissant dans le JS, c'est ce qu'il permet de faire avec des fonctions (callbacks, closures, fonction anonymes, redéfinitions, héritages) de manière simple et nécessitant un minimum de code, le json (on a rien inventé de plus minimaliste et léger pour décrire un objet), mais surtout et c'est à mon avis la "killer feature" le fait qu'il soit event driven. C'est bien sûr super adapté aux interfaces hommes/machines, mais également à internet (Ajax) et ça permet disons de simuler très facilement le multi-threading. Enfin, et la je te rejoint, il y a de nombreuses bibliothèques facilement utilisables et il est très souple, et effectivement cette forme de puissance est dangereuse en de mauvaises mains, surtout pour un langage comme JS quand il est fait une abstraction des principes de bases, ce qui mène à des comportements déroutants. C'est ce qui arrive quand par exemple des débutants qui font 2/3 "trucs de fou" avec JQuery essaient de customiser. Mais ça n'en reste pas moins un gage de puissance si c'est bien utilisé.
Citation:
Envoyé par Uther Voir le message
C'est le problème le plus énervant de JS. On est obligé de l'utiliser (du moins dans un navigateur) non pas parce que c'est un bon langage, mais parce que l'on a pas le choix.
Quand je fais une application classique, c'est quand même bien agréable de pouvoir choisir le langage le plus adapté. Heureusement, maintenant, il y a des langages qui compilent vers Javascript, avec même des performances supérieure à du Javascript qui aurait été fait main, ce qui en dit long sur la "puissance" du langage.
Ouais, ouais, c'est un peu lent, mais bon à quoi servirai la puissance de nos pc sinon? enfin quand c'est bien codé déjà, c'est pas si lent. Pour les langages qui compilent vers JS, excuse moi d'être sceptique, mais je vois pas comment on peut faire plus efficient dans ce sens là (ah si, si on code avec les pieds) sinon c'est comme dire que du C++ peut être plus efficient que de l'assembleur.
BPiero
 Poster une réponse  Retrouvez la suite de la discussion

 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum d'entraide

Blogs

Hébergement

 
Partenaires

Hébergement Web