Discussion :

[frfancha]

...permettant aux développeurs de s'affranchir de connaitre les inepties du JavaScript...

Quelles sont pour toi les 3 "inepties" principales de javascript?

[Kaamo]

+1 Lutarez

Quand je dis "inepties", je pense à petites bizarreries qui n'en sont pas vraiment tant que le langage est bien assimilé et qu'elles sont connues du développeur. Mais il faut en avoir conscience.

Selon moi, les 3 principales sont :
1 - mauvaise gestion du this dans ce cas :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Foo.method = function() {
  function bar() {
    // this ici est l'objet global
  }
  test();
}

C'est pour ça qu'il faut utiliser un "that" pour sauvegarder le this :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Foo.method = function() {
  var that = this;
  function bar() {
    // utiliser that ici
  }
  test();
}

2 - eval et là où il est utilisé implicitement (setTimeout, etc)
3 - typeof null === "object", instanceof buggué, gestion des types en général.
3 bis - les array-like, appeler un objet natif sans new crée une primitive, pouvoir modifier certains éléments natifs du langage

[Invité]

eval et là où il est utilisé implicitement (setTimeout, etc)

il n'y a rien a evaluer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

setTimeout(mafunction,1000,param1,param2)

[Watilin]

il n'y a rien a evaluer

Ce dont Kaamo parlait, je pense, c'est quand on appelle setTimeout avec une chaîne :

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

setTimeout("maFonction(unArgument, unAutreArgument)", 500);

Dans ce cas-là, la chaîne est implicitement passée à eval. Du coup on perd le contexte (this se ramène à window), et on s'expose à un risque éventuel si eval a été redéfini.

[sekaijin]

Ce dont Kaamo parlait, je pense, c'est quand on appelle setTimeout avec une chaîne :

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

setTimeout("maFonction(unArgument, unAutreArgument)", 500);

Dans ce cas-là, la chaîne est implicitement passée à eval. Du coup on perd le contexte (this se ramène à window), et on s'expose à un risque éventuel si eval a été redéfini.

pas vraiment dans ce cas c'est une définition de fonction implicite
c'est equivalent à

Code JavaScript :

Sélectionner tout - Visualiser dans une fenêtre à part

setTimeout(function(){maFonction(unArgument, unAutreArgument)}, 500);

il ne passe pas dans un éval la chaine passe dans le parseur pour la création d'un fonction anonyme. f'il y avais éval il faudrait que maFonction(unArgument, unAutreArgument)retourne une fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
maFonction = function (a, b) {
   ...
   return function() {....}
}
JavaScript]setTimeout(eval("maFonction(unArgument, unAutreArgument)"), 500);

leval de l'appel à maFonction retourne une fonction qui sera utilisé par le timeout

on a le même phénomène dans html lorsqu'on met une string sur onclick lors de la construction du DOM le navigateur défini un fonction anony associé à l'événement click dont le corps est le résultat du parsing de la chaine.

setTimeout est vieux dans JS et à l'époque exiger de passer une fonction anonyme n'est pas clair du tout pour le commun des mortels le choix de la chaine répondait à un besoin de randre le langage accessible à tous (mêm non developpeurs)

A+JYT

[Kaamo]

Oui voilà je faisais allusion à ce fonctionnement caché de setTimeout, setInterval et également au "built-in" Function qui permet de créer une fonction :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

var direCoucou = new Function("nom", "console.log('coucou ' + nom);"); // le corps de la fonction est implicitement évalué

A ne surtout pas utiliser !! Préférer sa forme littérale bien connue :

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
function direCoucou(nom) {
  console.log('coucou ' + nom);
}

[didiergm]

quand tu dis

A ne surtout pas utiliser !! Préférer sa forme littérale bien connue :

Pas tout à fait d'accord. La première forme a son utilité pour des cas "bizarres" : par ex quand tu veux transmettre du code attaché à une zone de saisie.

Je ne vois pas pourquoi ce serait particulièrement mauvais. ou très différent d'un loadscript jquery exécuté à la volée Mais peut être me trompès-je

Didier

[SylvainPV]

La vrai question c'est : Pourquoi aller vers une VM Dart (JavaScript killer/challenger) alors qu'on pourrait améliorer JavaScript ?

On peut améliorer JavaScript, mais il faudra toujours faire avec la rétrocompatibilité. Et on sait tous les deux que le JavaScript a son lot de pots cassés. Surtout que beaucoup de développeurs adorent copier-coller des codes datant d'avant 2005. Je ne serais pas contre le fait de faire table rase, même si tout ne me plaît pas dans Dart.

[Kaamo]

Je ne vois pas pourquoi ce serait particulièrement mauvais.

Quand tu connais eval et ses faiblesses et que tu sais ce que tu fais, alors non ce n'est pas particulièrement mauvais

[sekaijin]

comme toujours quand on utilise mal un outil on l'accuse d'être mauvais. c'est bien plus simple que de se remettre en question.

A+JYT

[Logan Mauzaize]

Si l'outil introduit clairement une complexité inutile alors on peut supposer qu'il est mauvais. Bien sûr il faut relativiser "complexité", "utilité" et "qualité".
Mais c'est justement la notation (ou le poids dans la notation) que l'on accorde à ces relativités qui en feront un mauvais outils pour le besoin.

Un peu comme ma réponse en fait

Pour faire simple, un langage peut être considéré comme moins bon s'il définit une méthode "toString" qui renvoie en réalité un entier qui est l'adresse en mémoire de l'objet.
Dans le cadre de JavaScript, on peut considérer que eval et les Strings implicitement évaluées en font un langage moins bon car elles introduisent une ambiguïté (à la lecture mais pas à l'interprétation) et donc une complexité qui dessert le langage.
Ce qui en fait un langage moins bon.

J'ai tendance à penser (à tord ?) que les éléments de base doivent pouvoir être assimilé facilement et sans ambiguïté quelque soit le niveau de celui qui le pratique. Et je ne trouve pas que les scopes de JavaScript correspondent à ce critère.

[Hinault Romaric]

Dart 1.2 améliore l’expérience du développeur
Google publie une nouvelle itération de son alternatif à JavaScript

À la suite de Microsoft qui a publié la Release Candidate de TypeScript 1.0, Google a dévoilé une nouvelle itération de son langage Dart.

TypeScript et Dart ont en commun de vouloir corriger les faiblesses de JavaScript. Alors que TypeScript est une sorte de « super JavaScript » entièrement compatible avec celui-ci, Dart est un langage alternatif proposé par Google, avec pour objectif inavoué la mise à la retraite du langage de Script.

La nouvelle version du langage de programmation structuré pour le Web rend plus facile le débogage des applications. Les points d’arrêt peuvent maintenant être fixés sur des affectations de variables locales. Le débogueur a été optimisé et élimine certains effets secondaires liés à son utilisation.

La bibliothèque de base de Dart continue à évoluer, avec un accent sur les performances. Le débit du module WebSocket a augmenté d’un facteur de quinze depuis la version 1.0. La vitesse des primitives asynchrones de base a également été améliorée de 10 %.

L’environnement de développement Dart Editor introduit un meilleur support d’Angular (navigation, recherche et ré-factorisation). Dart 1.2 apporte également des correctifs de bugs, des améliorations de performances et des améliorations pour la machine virtuelle Dart, le compilateur, les bibliothèques et les outils.

Dart a été adopté en décembre dernier par l’Ecma, qui a mis sur pied un comité pour superviser la création d’une norme pour le langage, afin de favoriser son adoption par l’industrie, notamment les éditeurs de navigateur.

Télécharger Dart v1.2

Source : Notes de version


Et vous ?

Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour combler les faiblesses de JavaScript ?

[sekaijin]

Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour combler les faiblesses de JavaScript ?
ni l'un ni l'autre

pour moi vouloir ajouter des cntrainetes fortes sur le typage n'est pas meilleur ou moins bon que le type dynamique de javascript.
je ne vois pas en quoi une classe est plus pertinant qu'un prototype.

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
foreach(Object element in myCollection) {
  if (element instanceOf MyClass) {
     console.log(((MyClass)element).myMethod());
  } else {
     console.log("methode non supportée : " + element.toString() )
  }
}

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
foreach(element in myCollection) {
  if (element.myMethod && "function" == typeof element.myMethod) {
     console.log(element.myMethod());
  } else {
     console.log("methode non supportée : " + element);
  }
}

dans un cas je vérifie que mon objet supporte l'usage d'une méthode en vérifiant qu'il appartient à une classe, dans le l'autre que la méthode existe.
le boulot est le même. au détail près que je peux dynamiquement ajouter la dite méthode à un objet alors qu'il faut redéfinir la classe et réinstancier les objets pour faire la même chose.

C'est quoi la faiblaisse ?
A+JYT

[Lutarez]

le boulot est le même. au détail près que je peux dynamiquement ajouter la dite méthode à un objet alors qu'il faut redéfinir la classe et réinstancier les objets pour faire la même chose.

Justement, à titre personnel, c'est la raison majeure qui me fait détester le Javascript.

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

Pour la petite histoire, dans le cadre d'un ancien travail, j'avais réussi à détourner une IHM Siebel pour mon usage (automatisation de la saisie d'informations) en redéfinissant une fonction Javascript, juste en utilisant IE7... Je pouvais même modifier des valeurs en lecture seule !

[anthyme]

Entre Dart et TypeScript ? Quelle approche vous semble la meilleure pour combler les faiblesses de JavaScript ?
ni l'un ni l'autre

pour moi vouloir ajouter des cntrainetes fortes sur le typage n'est pas meilleur ou moins bon que le type dynamique de javascript.
je ne vois pas en quoi une classe est plus pertinant qu'un prototype.

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
foreach(Object element in myCollection) {
  if (element instanceOf MyClass) {
     console.log(((MyClass)element).myMethod());
  } else {
     console.log("methode non supportée : " + element.toString() )
  }
}

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
foreach(element in myCollection) {
  if (element.myMethod && "function" == typeof element.myMethod) {
     console.log(element.myMethod());
  } else {
     console.log("methode non supportée : " + element);
  }
}

Ton exemple n'est pas bon, justement dans un langage typé avec une architecture correct on nfait pas de test d'instanceOf.
On sait partout où l'on est le type des éléments et on peut donc appeler la méthode car le compilateur nous a assuré qu'on pouvait le faire

Pour ma part je pense que typescript est plus efficace aujourd'hui pour son approche minimaliste et sa compatibilité absolue avec toutes les libs existantes. C'est le gros défaut de dart, quand il serra largement supporté et que les libs seront distribuées tant en js qu'en dart cela sera un choix du même niveau.

Il ne faut pas oublier l'objectif de typescript, être un langage "futur" du javascript, en gros on code en typescript comme on pourrait coder en ecmascript6, une fois l'ecmascript 6 arrivé on garde un code très proche.

[LSMetag]

Pour ma part je pense que typescript est plus efficace aujourd'hui pour son approche minimaliste et sa compatibilité absolue avec toutes les libs existantes. C'est le gros défaut de dart, quand il serra largement supporté et que les libs seront distribuées tant en js qu'en dart cela sera un choix du même niveau.

Il ne faut pas oublier l'objectif de typescript, être un langage "futur" du javascript, en gros on code en typescript comme on pourrait coder en ecmascript6, une fois l'ecmascript 6 arrivé on garde un code très proche.

Je suis d'accord avec ce point de vue. On est en plein dans la norme EcmaScript et on reste 100% compatible avec du Javascript. On peut nuancer en soulignant que Dart a désormais également sa cellule de normalisation (en général les devs sont plus soucieux des normes que les entreprises). TypeScript a plus de chances de percer et tout plugin/framework Javascript est compatible alors qu'il faut en créer pour Dart (Polymer et AngularDart me suffisent en tout cas pour le moment). Le Javascript généré est probablement plus clair et performant que celui de Dart (je n'ai pas testé)

Pour ma part j'ai une préférence pour Dart. D'une part, les performances de Dart natif sont bien supérieures au Javascript natif. D'autre part, parce que c'est simplement un autre langage, une autre syntaxe, qui me permet d'esquiver tout ce qui peut ressembler de près ou de loin à Javascript, et que le Javascript que l'on génère pour un fallback, on s'en bat un peu le coquillage tant qu'il est performant et fiable. On peut penser que j'ai une dent contre le changement. Je ne sais pas. J'ai mes habitudes avec PHP/C#/Java,... et ne me sens pas du tout à l'aise quand je fais du Javascript.

Bref, TypeScript ajoute à Javascript ce qui lui manque et corrige des comportements aberrants, tout en conservant une grande compatibilité avec l'existant Ecmascript. Mais comme la syntaxe et les mécanismes de Javascript me rebutent, alors je préfère me concentrer sur Dart, même si professionnellement TypeScript aurait sans doute été un meilleur choix. De toute façon, si aucune boîte ne veut de moi avec mes choix de compétences, je créerai alors la mienne ^^.

[DonQuiche]

Concernant typescipt, je le trouve intéressant car il ne cherche pas à révolutionner les choses et se contente d'ajouter un typage statique à javascript pour faciliter les gros projets. C'est aujourd'hui le moyen le plus naturel de faire de la programmation web avec un typage statique. C'est déjà prêt, c'est élégant, c'est efficace et ça ne nécessite aucune modification des navigateurs.


Quant à Dart, s'il semble "meilleur" que Javascript (disons qu'il a moins de défauts de jeunesse mais les différences au niveau du système de typage sont une affaire de goûts et de couleurs), sa valeur ajoutée me semble trop faible pour justifier cette couche de plus au sein des navigateurs. Pour moi l'avenir du web ce n'est pas de supporter 22 langages similaires au sein du navigateur et soixante couches d'API, avec une effroyable plomberie derrière pour obtenir des performances dignes de ce nom. Surtout que si on ajoute Dart ensuite on va nous bassiner que ça commence à bien faire et qu'on ne va pas en plus rajouter un pNaCl/asm.js.

La priorité à l'heure actuelle selon moi c'est de rendre la navigateur plus simple et plus neutre : un byte code simple pour autoriser tous les langages, un javascript à peu près figé (compatibilité), un jeu d'API de plus en plus gros, et un html moderne de plus en plus simple et dépouillé, qui sera de moins en moins utilisé au fur et à mesure que des moteurs de rendu tierce-parties écrits en javascript/bytecode avec accélération GPU (à la famo.us) le supplanteront. Grosso modo l'innovation ne viendra plus de ces standards mais de biblios tierce-parties tandis que le navigateur aura vocation à devenir un OS stable et concis à mesure qu'il abandonnera ses racines des 80's, quand html se voulait un langage de pagination et javascript un petit truc pour bricoler.

[LSMetag]

Quant à Dart, s'il semble "meilleur" que Javascript (disons qu'il a moins de défauts de jeunesse mais les différences au niveau du système de typage sont une affaire de goûts et de couleurs), sa valeur ajoutée me semble trop faible pour justifier cette couche de plus au sein des navigateurs. Pour moi l'avenir du web ce n'est pas de supporter 22 langages similaires au sein du navigateur et soixante couches d'API, avec une effroyable plomberie derrière pour obtenir des performances dignes de ce nom. Surtout que si on ajoute Dart ensuite on va nous bassiner que ça commence à bien faire et qu'on ne va pas en plus rajouter un pNaCl/asm.js.

Tout dépend de l'utilisation qu'on veut faire de Dart. Si on veut s'en servir pour du Web, alors il vaut mieux s'en servir comme du Java : c'est à dire un code en Dart, puis un fichier compilé derrière en JS utilisant les standards du Web. Ne considérer alors la VM Dart que comme un bonus optionnel de performances.

Si par contre on s'en sert côté serveur, alors utiliser la VM Dart que l'on peut faire tourner en mode console.

C'est pour ça que je trouve que la valeur ajoutée de ce langage n'est pas si faible, grâce à la compilation en Javascript qui s'avère meilleure que beaucoup d'autres "alternatives". Il permet simplement d'oublier Javascript, tout en continuant de l'utiliser.

[anthyme]

Qu'est ce qui te rebutes dans la syntaxe ?

Si c'est le pattern module pour les namespaces ( (function () { ... })() ), l’écriture de pseudo modèles objets closure et prototype, ou les lambda trop verbeuses (c'est tout ce qui me rebute le plus perso).
Et bien tout ceci n'est plus applicable en typescript, en fait on a l'impression d’écrire sur c#/java

Sinon la génération de code est très très light et propre, et ça c'est plutôt cool ça si on veut se débarrasser de la techno, on peut et retourner sur du javascript
C'est un point important à prendre en compte pour la pérennité d'un projet.

[sekaijin]

Ton exemple n'est pas bon, justement dans un langage typé avec une architecture correct on nfait pas de test d'instanceOf.
On sait partout où l'on est le type des éléments et on peut donc appeler la méthode car le compilateur nous a assuré qu'on pouvait le faire

Pour ma part je pense que typescript est plus efficace aujourd'hui pour son approche minimaliste et sa compatibilité absolue avec toutes les libs existantes. C'est le gros défaut de dart, quand il serra largement supporté et que les libs seront distribuées tant en js qu'en dart cela sera un choix du même niveau.

Il ne faut pas oublier l'objectif de typescript, être un langage "futur" du javascript, en gros on code en typescript comme on pourrait coder en ecmascript6, une fois l'ecmascript 6 arrivé on garde un code très proche.

je ne suis pas d'accord les languages supprotant l'héritage multiples sont pas légions. et lorsque tu a des objets qui sont issue de lib ou framwork tu ne peux pas les mettre dans une même collection typé c'est ainsi qu'on voit des List<Object> et autre truc car la seul classe commune est alors Object.
et tu n'a pas le choix si tu vérifie pas tu part dans les choux.

je ne comptes pas le nombre de CastException que je vois passé sur le SI dans des produit à plusiers centaine de milliers d'euros lorsque ce n'est pas des nombres à plus de 6 chiffre.
Tu peux fermer les yeux mais si tu vérifie pas un jour ça te tombe dessus.

jutilise plusieurs normes qui définissent dans leur dommaine une représentation d'un ensemble d'objets. je fait appel à plusieurs fournisseurs qui propose chacun une implémentation d'une des normes. mais moi je manipule des objets dans l'ensemble de ces normes
une réalié au quotidient pas le choix la seule classe qui est capable de servir de base commune c'est Object.
certaines des lib fournissent la méthode dont j'ai bessoin d'autre pas. les classe sont final impossible de les dérivers. impossible même si on pouvait des dériver de faire en sorte que la lib produise des objets dérivés elle n'est pas là pour ça. impossible donc d'avoir un moyen d'être sur d'avoir la même méthode partout.
impossible de faire un traitement simple en parcourant les objet et en appliquant sur chacun une methode. du coup on caste on fait de s méthode utilitaire etc.
on pisse du code.

avec un typage dynamique on transmute son objet. on lui attache la méthode de son chox à la volée.

Pourquoi tant de language lève les contrainte de classes ? pourquoi tant de language joue avec des mécanisme d'introspection ? pourquoi voit-on fleurir les injection de byteCode ?

Parfoit les classes bien rigides sont des contraintes trop fortes.
Je n'ai pas dit toujours, j'ai dit parfois.

et lors on est confromté quotidiennement à ce genre de difficultés où on fini par pondre des centaines de lignes pour 1 appel de méthode ont change de méthode de travail et on prends des outils qui ont d'autres avantages pour d'autres usages avec des façons de travailler différents.

non le typage dynamique n'est pas une faiblaisse c'est une force. tu en as besoin ou pas mais tout comme les classe sont une force pour certains usage le typage dynamique en est une pour d'autres.

Et donc aucun de ces deux language est le mieux placer pour paliser les faiblaisses (force) de JS.
Il ont des caractéristiques différentes qui offre des outils bien adapté à certains usages et moins à d'autres. exactement comme javascript et n'importe quel autre langage.

pas plus tard qu'aujourd"hui une trantaine de classe ou le seul boulot à faire est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

transValue = translate[origValue]

un truc très con. finalement mais voilà les classes d'origines ne permettent pas de récupréer la listes des valeurs des membres et les classe destinatrices ne permettent pas de fournir une liste de valleur de membre. pout trente classes il faut faire pour des centaines de membres

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

out.setChamp1(translate.get(in.getFild1()))

biensur les nom des champs ne sont pas homogènes c'est donc des centaines de lignes à écrire. alors qu'avec un langage plus souple comme js une boucle sur tous les membres de l'objet une map qui traduit le nom du champ une autre les valeur et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

out[translateNom[membre] = translate[origValue]

en 3 ligne et une table de paramètre c'est fini pour toute les classes. les lib évolue de nouvelle classes arrive pas de pb on ajoutes des valeurs dans la table de traduction.

efficacité des classes 30 x 100 lignes de code java face à 3 lignes de js.
au final en java avec un 10aine de lignes de code et en jouant avec l'introspection on passe outre les protect private et autre artifice des classes java et on fait le vrai boulot soit le smême trois lignes qu'en JS. mais pour y arriver il faut casser le principe même des classe.

J'ai vu des truc monstrueux dans ma carrière. des gars qui pour évider des jours de travail ce sont apperçu que des classe d'un fournissuer officiel estait sérialisable en java. ils ont écrit un jeux de classe ayant les mêmes noms. dans un prepier système il utilisaient les classes officielle du fournissuer qu'ils sérialisaient. le deuxième les lisait en utilisant leur propre classes. la sygnature dans la serialisation correspondant. il faut méchamant voir l'esprit tordu pour en arriver là. la raisont était l'impossibilité de faire ce qu'ils avaient besoin de faire avec les classes dorigine et la trop grande quantiter de code à produire pour passer d'une représentation à l'autre.


et il y a des absurdité partout en javascript dans 90% des développements. voici que l'ontrouve.
on a un élément du dom qui possède les méthode onclick onchange etc. et on va créer une fonction globale pour chaqune de ces méthodes puis on va créer autant de fonction annonyme quon va attacher au onclick et autre handler. ces fonction ne feront rien d'autre que d'appeler une fonction globale.
pourtant tout cela est objet ce revient à la chos esuivante.

c'est comme si en java on a la classe Element qui a les méthode onClick onChange chaqu'une de ces méthone ne faire rien d'autre que d'appel Main.uneMethode() et donc on ajoute les méthode qui font le boulot dans la classe Main. ce n'est pas 90 c'est même dans bien plus que ça.
Pourtant javascript permet de faire les choses simples il suffit d'attacher directement les méthode qui font le bouot à l'élément.
Si on réfléchi comme en java i faudrait dériver la classe Element pour cet élément là. pour avoir un élément qui porte CES methode là et pas d'autres.
C'est sur que si on fasait ça en java on aurait plus de 60% des classe qui n'auraient qu'une seul objet.
Il suffit de ne pas penser classe mais prototype et ojet dynamique pour comprendre que l'objet de la classe Element peut recevoir toutes les méthodes tous les attributs dont il a besoin.

A+JYT