Discussion :

[camus3]

En PHP aussi la portée des variables est une portée de fonction et non une portée de bloc ! Même si PHP n'est pas une référence

ECMAscript.Next introduit un mot clef let qui permet une portée "lexicale" d'une variable. Le problème est toujours le même, impossible d'utiliser un nouveau mot clef javascript avant que la majorité des utilisateurs ne soient équipés de navigateurs supportant la nouvelle fonctionnalité...

Bref dans 5 ans on risque d'être encore limité au javascript actuel. Et la politique de MS concernant la mise à jour des browsers ( genre une nouvelle version par Os , n'arrange rien à l'affaire ).

[_skip]

En fait si tu lances windows update, il te propose de mettre à jour jusqu'à la 9.
Le problème c'est surtout que peu d'entreprise de taille mettent à jour les navigateurs toutes les 25 minutes, surtout quand tout a été testé sur les versions courantes. Et il y a même des gros produits (Cognos) où le support ne te garantit le bon fonctionnement que sur certaines versions de navigateurs.

Enfin non content d'être un langage moisi, javascript oblige en plus à être extrêmement prudent que tout se comporte bien de la même manière sur les différents navigateurs. Et justement utiliser une surcouche comme Dart pourra peut être bien permettre d'encapsuler certaines différences afin d'économiser quelques cheveux gris.

[Invité]

Enfin non content d'être un langage moisi

pourquoi tant de haine ?

c'est peut etre nettoyable avec skip

[_skip]

pourquoi tant de haine ?

c'est peut etre nettoyable avec skip

Ce n'est pas de la haine en soi. Il se trouve juste qu'on est proche d'une situation où le choix de javascript, malgré que ce soit fragile et intestable est en passe d'être incontournable.

Son avantage par rapport aux autres (silverlight par exemple)? Juste qu'un consortium est venu avec une pile de paperasse et un drapeau "Hey guys it's a standard, like it or not". C'est pas propre à javascript, j'ai déjà sacrément trollé sur ce forum à propos de SUN et sa manie de standardiser tout et n'importe quoi dans java, en débarquant des années après avec des specs nazes qui étaient loin derrière tout ce qui se faisait déjà en non-standard sans être en plus forcément plus portable.

Donc voilà, moi et pleins d'autres vont nous retrouver avec un langage de script web dont les défauts sont si reconnus que la raison d'être de pleins de framework basés sur des composants et du ajax (Gwt, Devexpress/Telerik Asp.net, Wicket, IceFaces, Richfaces et j'en passe) est justement d'en faire l'abstraction et d'encapsuler du mieux possible les différences d'implémentation.

En gros oui, je ne pas m'empêcher de dire que lorsque la préoccupation de plein de gens est de trouver la librairie, le framework ou la surcouche quelconque qui va rendre tout ceci utilisable, c'est qu'il y a quelque chose qui n'est pas idéal quelque part. Ma colère n'est pas tant dirigée vers le langage lui-même, qui a été pensé avec un rôle à remplir càd d'amener un peu de dynamisme dans des pages statiques et bricoler un petit peu de DOM, mais plutôt envers des gens qui refusent de voir que ce n'est pas fait pour faire ce qu'on veut en faire aujourd'hui et qui préfèrent bétonner sur du sable mouvant à grand coup de nouvelles specs que plutôt que de venir avec une réponse adaptée.
Pour moi, un truc comme DART, c'est carrément le w3c qui aurait du venir avec, pas google.

[Invité]

en attendant il faut faire avec et il serait dommage que l'on rate le coche des application sur navigateur tout simplement parce que l'on boude le javascript, et que se soit toujours les mêmes(adobe microsoft google...etc)qui empochent le pactole.

[stardeath]

perso je préfère faire sans que avec javascript, j'évite de grosses envies de meurtre, ou mieux, j'utilise de vrais environnements fait pour le dev : flash, silverlight, au pire java ;

dire que google, microsoft ou adobe ramassent le pactol c'est vraiment penser que le js a sa place dans un domaine où il ne devrait pas être.

on ne développe plus standard, certes, mais c'est un faux problème, ces boites fournissent quelque chose d'utilisable, les pseudos inconvénients sont peu cher payé par rapport aux capacités de ces solutions.

je préfère de loin non "standard" et pas prise de tête que le contraire.

[Invité]

dire que google, microsoft ou adobe ramassent le pactol c'est vraiment penser que le js a sa place dans un domaine où il ne devrait pas être.

tu serait pas en pleine période de déprime ? vivement la fin de l'hiver

en tout cas ca changera pas mon avis sur le fait de bouder le javascript pour ce qui me parait etre des convictions pas entièrement justifiable

on peut parler de point faible mais faire un amalgame généraliste en défaveur du javascript sans aucunes concession semble minimaliste et ce sans aucunes argumentations techniques.

[stardeath]

pas justifiable? c'est clair que je ne vais pas réécrire tous les points qui permettent à beaucoup de développeurs de penser que js est une plaie.

et non, il n'y a pas de concession à faire, le monde anti-propriétaire (enfin le monde anti plugins plutôt) veut imposer un js qui n'a pour lui que d'être un langage de script pour faire des applis qui tendent vers des applis lourdes sans avoir pris la moindre considération envers les développeurs qui doivent faire avec la pauvreté des environnements de dév actuels.

la mode tend à nous faire manger du js à toutes les sauces, gardons js pour un domaine dans lequel il a sa place : les scripts et laissons le reste à des langages moins bricoleur du dimanche. ( ça viendrait à l'idée de personne de faire un client mail voir plus gros en bash, pourquoi vouloir le faire en js alors )

[gwinyam]

Pourtant je suis sûr que tu utilises Gmail et que tu en es très content, non ?

[stardeath]

je vois pas le rapport, même si j'en suis content niveau utilisateur, ça n'empêche pas moins qu'en tant que développeur je trouve ça immonde en terme de code, enfin je ne suis pas magicien, ceci explique peut être cela.

ça vaut aussi pour les jeux/applis flash silverlight que j'utilise, j'en suis content, et en plus je trouve ça agréable à développer, pourquoi j'irai m'enterrer avec js?

pour être standard? non merci, je tiens à ma santé, et ce n'est pas pour ce seul "avantage" que je vais faire du js.

[Uther]

Pourtant je suis sûr que tu utilises Gmail et que tu en es très content, non ?

Gmail est justement réalisé avec GWT qui transforme du code Java en Javascript.

Une preuve s'il en fallait que quand on en arrive aux applications lourdes, on peut certes faire en Javascript, mais on préfère souvent trouver une solution même tordue pour s'en passer ou du moins avoir le moins possible à s'en soucier.

[_skip]

Gmail est justement réalisé avec GWT qui transforme du code Java en Javascript.

Une preuve s'il en fallait que quand on en arrive aux applications lourdes, on peut certes faire en Javascript, mais on préfère souvent trouver une solution même tordue pour s'en passer ou du moins avoir le moins possible à s'en soucier.

En fait le cas de Gmail est un poil différent. GWT est sorti bien après Gmail mais il a été pensé justement pour être la réponse aux difficultés qu'ont "subi" les ingénieurs de google lors de cette expérience.
Cela dit ça n'enlève rien à ton propos (qui rejoint d'ailleurs mon post précédent) comme quoi beaucoup de développeurs fuient le contact direct avec JS.

[Invité]

je jette l’éponge

[gwinyam]

C'est marrant que les gens s'acharnent parfois à vouloir chercher une alternative non standarde et donc nécessitant de faire le boulot plusieurs fois parce que ce n'est justement pas un standard. Plutôt que de chercher à faire en sorte que les derniers dilettants respectent les standards et de les faire progresser tous ensemble.

Au lieu de râler après JS parce qu'ils manquent ceci ou cela, soyez pro-actifs, proposez. Ce n'est pas pour rien que l'équipe de jQuery a créé un groupe nommé jQuery Standards qui vient s'ajouter aux différentes sociétés/associations du W3C. C'est aussi pour que les standards s'enrichissent dans le bon sens.

[camus3]

je jette l’éponge

faut pas
Dart , Haxe , Coffeescript , GWT , etc...
Différentes solutions existent comme dit plus haut , pour ceux qui ne veulent pas toucher à Javascript.
Personne n'ira regarder votre code source pour savoir si vous avez bien tout codé directement en JS avec Emacs Seul le résultat compte.

[stardeath]

...

pourquoi vouloir imposer un javascript dont beaucoup de gens ne veulent pas entendre parler?
pourquoi ne pas vouloir que des alternatives se développent?

il me semble que personne ne râle parce qu'il y a des dizaines de langages de programmation pour le desktop (enfin si, peut être la sur abondance), pourquoi vouloir limiter le web à un trio?

si demain un os imposait UN langage de programmation, on entendrait râler (cf ios, android et windows phone) et ces râleurs auraient raison ; mais là non, sur le web, on veut nous imposer une façon de faire et on aurait juste à se taire? je trouve ça un poil abusif.

l'exemple de jQuery est un mauvais exemple, ça n'enlève en rien les tares de js, ce n'est pas forcément un manque de fonctionnalités, mais plutôt de façon de les ajouter, et ça rajoute une bibliothèque avec tous les avantages/inconvénients que cela apporte.

[Uther]

Au lieu de râler après JS parce qu'ils manquent ceci ou cela, soyez pro-actifs, proposez. Ce n'est pas pour rien que l'équipe de jQuery a créé un groupe nommé jQuery Standards qui vient s'ajouter aux différentes sociétés/associations du W3C. C'est aussi pour que les standards s'enrichissent dans le bon sens.

C'est là ou on ne se comprend pas, le problème n'est pas d'améliorer JavaScript en lui ajoutant de nouvelles API, a ce niveau là il n'a pas de problèmes.

C'est la nature même du langage et tout particulièrement son typage dynamique qui le rend plus difficile à aborder dans le cadre d'applications lourdes ou l'on réclame une certaine robustesse et qui limitera systématiquement ces performances malgré tous les efforts qui sont fait par les interpréteurs, l'inférence de type ayant ces limites.

[gwinyam]

si demain un os imposait UN langage de programmation, on entendrait râler (cf ios, android et windows phone) et ces râleurs auraient raison ; mais là non, sur le web, on veut nous imposer une façon de faire et on aurait juste à se taire? je trouve ça un poil abusif.

Ton argument est juste, le seul souci est que les alternatives proposées sont propriétaires et donc non portables. Même si JavaScript rencontre encore beaucoup de problèmes de ce genre, l'idée est d'avoir une seule appli développée qui tourne sous tous les navigateurs. Si tu me proposes une alternative viable qui fait la même chose sous tous les navigateurs, ok pourquoi pas. Mais pas flash, silverlight, flex. Qui sont juste des immondices bourrées de tout ce qu'il faut pour faire planter nos machines avec le plus grand des plaisirs.

l'exemple de jQuery est un mauvais exemple, ça n'enlève en rien les tares de js, ce n'est pas forcément un manque de fonctionnalités, mais plutôt de façon de les ajouter, et ça rajoute une bibliothèque avec tous les avantages/inconvénients que cela apporte.

Je crois qu'on s'est mal compris. Je te parle d'un groupe de personnes extrait du groupe jQuery qui s'est dédié à intervenir auprès du W3C pour faire évoluer le langage, je ne te parle pas d'ajouter la librairie pour aplanir les différences. D'ailleurs il me semble que des mecs de Mootools se sont joint à eux pour pouvoir avoir plus de poids.

C'est là ou on ne se comprend pas, le problème n'est pas d'améliorer JavaScript en lui ajoutant de nouvelles API, a ce niveau là il n'a pas de problèmes.

Honnêtement ? Si, il y a encore un paquet de supers trucs qu'on pourrait changer/ajouter/retirer.

C'est la nature même du langage et tout particulièrement son typage dynamique qui le rend plus difficile à aborder dans le cadre d'applications lourdes ou l'on réclame une certaine robustesse et qui limitera systématiquement ces performances malgré tous les efforts qui sont fait par les interpréteurs, l'inférence de type ayant ces limites.

Le souci n'est pas dans sa portée mais dans l'éducation des développeurs à son usage. C'est vrai que c'est une méthode peu habituelle. Je le ressens d'autant plus aujourd'hui que je donne ces jours ci des conférences sur JavaScript à la ConFoo à Montréal. Combien de mecs reconnus dans le monde du dev m'ont dit qu'ils ne comprenaient rien au langage, que les statiques marchaient mal ou encore qu'il n'y a pas d'héritage.

C'est un langage complexe, qu'il faut prendre la peine d'apprendre, comme pour tout autre langage. Sinon oui forcément, ça devient le bordel dans vos applis.

[camus3]

Comment ça va à Montréal ? il doit faire froid à cette periode de l'année , mais avec une bonne poutine c'est supportable

que les statiques marchaient mal ou encore qu'il n'y a pas d'héritage

.
Le problème c'est le nombre de lignes à écrire pour déclarer une sous-classe, ça donne pas envie et c'est pas très lisible.
En fait javascript est tout simplement illisible quand on ne comprend pas son fonctionnement dans les moindres détails.

C'est un langage complexe, qu'il faut prendre la peine d'apprendre, comme pour tout autre langage. Sinon oui forcément, ça devient le bordel dans vos applis.

Langage complexe , non pas parce qu'il est utilisé pour développer des applications aux problématiques complexes , mais parce le développement de ce langage et sa standardisation ont été anarchiques et bâclés.
ES5 tente d'ailleurs de donner des outils pour rendre le langage moins dynamique.

Mais pas flash, silverlight, flex. Qui sont juste des immondices bourrées de tout ce qu'il faut pour faire planter nos machines avec le plus grand des plaisirs.

Tu as beau considerer flash/silverlight immonde , ces solutions ont tout ce qu'il faut pour développer de vraies applications client riche. Des outils , un langage robuste avec typage fort , qui n'essaie pas d'être complexe pour rien et surtout qui donne le choix de paradigme de programmation.

Tu peux faire de la programmation par prototypage en AS3 comme en javascript , mais personne ne le fait parce que 1/ c'est lent , 2/ c'est laid.

Bref flash/silverlight , c'est pas standard , mais c'est développeur friendly.

Pourtant je suis sûr que tu utilises Gmail et que tu en es très content, non ?

Gmail a bien été développé directement avec Javascript , mais avec un prototype du closure compiler , c'est à dire utiliser javascript annoté permettant de "typer fictivement" les variables et les objets et de vérifier que les paramètres entrés dans les fonctions sont bien du type fictif déclaré grâce à une pré-compilation.

Soyons honnête , si javascript n'était pas le seul langage de script disponible coté client personne n'en ferait, et dès qu'une alternative viable existera ( ce qui finira par arriver , ce langage étant tellement haï ) il tombera aux oubliettes. Le plus vite sera le mieux.

[Uther]

Je crois qu'on s'est mal compris. Je te parle d'un groupe de personnes extrait du groupe jQuery qui s'est dédié à intervenir auprès du W3C pour faire évoluer le langage, je ne te parle pas d'ajouter la librairie pour aplanir les différences. D'ailleurs il me semble que des mecs de Mootools se sont joint à eux pour pouvoir avoir plus de poids.

A ma connaissance le W3C ne normalise pas le langage, c'est l'ECMA qui s'occupe de ça.

Honnêtement ? Si, il y a encore un paquet de supers trucs qu'on pourrait changer/ajouter/retirer.

Je ne dis pas qu'il n'est pas possible d'améliorer les API mais il ne me semble pas qu'il y ait urgence et ce n'est pas un problème de fond.
On aura beau améliorer les API ça ne changera pas le langage lui même qui restera avec quasiment aucune contraintes, ce qui impacte au niveau des performances et de la robustesse dans une application complexe.

Le souci n'est pas dans sa portée mais dans l'éducation des développeurs à son usage. C'est vrai que c'est une méthode peu habituelle. Je le ressens d'autant plus aujourd'hui que je donne ces jours ci des conférences sur JavaScript à la ConFoo à Montréal. Combien de mecs reconnus dans le monde du dev m'ont dit qu'ils ne comprenaient rien au langage, que les statiques marchaient mal ou encore qu'il n'y a pas d'héritage.
C'est un langage complexe, qu'il faut prendre la peine d'apprendre, comme pour tout autre langage. Sinon oui forcément, ça devient le bordel dans vos applis.

L’intérêt d'un langage dynamique est de l'utiliser comme tel sinon on a les inconvénients sans les avantages.

Si on veut utiliser JavaScript pour faire quelque-chose de structuré avec un semblant de modèle de classe et d'héritage, ça veut dire que c'est les développeurs qui se retrouvent à faire une bonne partie du boulot fait automatiquement dans la plupart des langages statiquement typés.
En plus du code qui devient vite "inbitable" il y a risque d'erreur, et aucune garantie que tous les intervenants sur l’application (parfois d'origine différentes) appliquent les mêmes règles à respecter.
Et malheureusement cette structuration n'aidera ni les performances ni les outils d'assistance au développement(débogage, refactoring, inspection de code, ...) qui seront très limités par la nature dynamique du langage.

Par exemple, en faisant du C bien organisé on peut faire tout ce que permettent des langages orientés objet comme C++, C# ou Java. Mais si on a créé ces langages objet, c'est justement pour poser un cadre qui permette que guider autant que possible vers une bonne utilisation et d'essayer de tirer parti autant que possible de cette structuration.