Discussion :

[phili_b]

Pourquoi ?
La syntaxe de jQuery est affreuse.
[...]
Je suis désolé mais document.getElementById() c'est quand-même plus compréhensible que $("#");

Je la trouve au contraire bien plus lisible et surtout moins verbeuse tout en n'ayant pas les inconvénients de l'obfuscation de certains langages.

Je trainais les pieds pour me remettre au javascript mais depuis que j'ai appris le JQuery je fais cela avec le sourire.

Les API de Dart sont sans doute d'un apport indéniable, faut voir, mais ça serait encore mieux s'ils acceptaient la syntaxe JQuery. Surtout que ce n'est pas qu'une question de syntaxe, ça simplifie beaucoup les boucles notamment avec .each(), la lecture est plus aisée.

[osallou]

[QUOTE=Jean-Georges;7570417]Pourquoi ?

"Si javascript avait ça avec un vrai support de classes et une interprétation uniforme au sein des navigateurs, "


L'interprétation au sein des navigateurs n'a rien à voir avec Javascript en tant que tel (avec ses + et ses - ). Il s'agit d'un problème avec les navigateurs et ceux qui les créent.
Javasript est basé sur un standard (ECMA), après c'est la réalisation de ce standard qui est plus ou moins bonne ou interprétée.

Ce problème est le même pour beaucoup d'autres langages, par exemple entre compilateurs qui suivent plus ou moins les normes ISO définies pour le langage.

[dragonfire]

Pourquoi ?
La syntaxe de jQuery est affreuse.
Elle oblige de plus à apprendre une syntaxe supplémentaire et à passer de l'une à l'autre, ce qui est ridicule.
Actionscript 3 par exemple qui est très proche de javascript a des méthodes de base qui permettent des animations, transitions etc sans passer par un pseudo-langage différent.
Si javascript avait ça avec un vrai support de classes et une interprétation uniforme au sein des navigateurs, on pourrait l'utiliser sans y coller des librairies de partout qui en font la créature de Frankenstein des navigateurs.
Je suis désolé mais document.getElementById() c'est quand-même plus compréhensible que $("#");

La syntaxe de JQUERY est homogène avec celle de CCS, et pour le programmeur HTML / CSS / Javascript voire XML / XSL cela ne pose aucun souci.

[Zefling]

Sans ces librairies ou frameworks, JS serait vraiment de la préhistoire. Et c'est à partir de ces nouveautés que le développement côté client a repris de l'intérêt chez les développeurs. Mais ces librairies sont pour moi des rustines sur un langage qui a tout de même du plomb dans l'aile.

Je connais pas beaucoup de langage vraiment utilisable sans framework, ou alors c'est juste pour faire des scripts. Presque personne ne fait de C# ou de Java sans utiliser sans utiliser un environnent comme par exemple : Spring pour Java, parce qu'il serait bien trop long de tout refaire à la main. Le problème c'est qu'on compare souvent JS nu (sans framework) avec des langages enrobé de framework. D'ailleurs c'est aussi vrai pour PHP.

[stailer]

@Marco46 et @Plawyx : merci pour le lien comparatif et votre retour d'expérience. Je pense que je vais tester sérieusement.

Notamment, je vais voir si je peux l'intégrer facilement avec KendoUI (qui propose déjà une intrégration de Knockout, comme JQWidgets d'ailleurs).

@Zefling :

. Le problème c'est qu'on compare souvent JS nu (sans framework) avec des langages enrobé de framework. D'ailleurs c'est aussi vrai pour PHP

+10 000, ça aussi je ne compte pas le nombre de fois ou je me suis pris la tête avec des dévs Java ou .Net sur ce forum, qui descendaient PHP en flamme, comparant injustement des fonctionnalités d'ASP.NET MVC avec PHP à nu et sans framework.

[Marco46]

@Marco46 et @Plawyx : merci pour le lien comparatif et votre retour d'expérience. Je pense que je vais tester sérieusement.

Notamment, je vais voir si je peux l'intégrer facilement avec KendoUI (qui propose déjà une intrégration de Knockout, comme JQWidgets d'ailleurs).

Je suis pas sûr d'avoir compris tu veux intégrer AngularJs avec KendoUI ?

[Jean-Georges]

Il ne faut pas confondre framework pour augmenter la productivité / codifier le travail en équipe et framework pansement qui corrige des problèmes.
Php n'a pas besoin d'un framework pour fonctionner partout de la même façon.
Je n'utilise pas de frameworks en php. J'ai développé par contre un tas d'outils qui me simplifient la vie, chose très compliquée en javascript, ne serais-ce qu'à cause du système de prototypage étrange et peu pratique pour les habitués des dérivés du C++.

[Zefling]

Il ne faut pas confondre framework pour augmenter la productivité / codifier le travail en équipe et framework pansement qui corrige des problèmes.
Php n'a pas besoin d'un framework pour fonctionner partout de la même façon.
Je n'utilise pas de frameworks en php. J'ai développé par contre un tas d'outils qui me simplifient la vie, chose très compliquée en javascript, ne serais-ce qu'à cause du système de prototypage étrange et peu pratique pour les habitués des dérivés du C++.

En gros, t'as un mini-framework.

En PHP j'ai fini par me développer un framework pour me simplifier la vie. PHP sans framework, c'est sympa, mais au bout d'un moment on se rend vite compte que si on ne compte que sur le langage sans aucune aide, on prend un temps fou pour faire des choses simple : formulaire, gestion des messages, pagination, xml, ajax, templète, mail, etc. L'intérêt d'un framework est de simplifié le travail. (Bon, faire un framework finit par prendre un temps fou, c'est bien plus simple de s'orienter faire des solutions où les gens se sont cassé la tête à trouver des solutions à tout un semble de problèmes courants.)

Et bien, je fais la même chose en JS et franchement, je vois pas où c'est plus compliqué de monter un framework en JS (ou d'en utiliser un déjà tout fait). Le seul truc, c'est qu'on ne lui demandera pas la même chose, et c'est peut-être la que c'est plus compliqué. J'ai jamais vu le problème du prototypage ou même de l’événementiel en JS.

[Aiekick]

et on peut déboguer sous Windows ou c'est toujours pas prévu.

c'est le seul frein que je rencontre avec dart moi

[Sirus64]

Des remarques sur ce que j'ai lu : JQuery est une bibliothèque pas une nouvelle syntaxe. C'est simplement l'utilisation de manières plus fonctionnelles (dans le sens du contraire d'impératif) de voir les choses. Je trouve ça dommage qu'on confonde ici langage et performance : il y a plutôt des langages et des domaines de prédilection. C'est comme dire que l'assembleur est plus rapide que le C : c'est un non-sens. L'assembleur est écrit spécifiquement pour un processeur, le C est générique et peut-être converti dans un tas d'assembleurs. De plus, le code est souvent mieux optimisé par le compilateur que par les humains : concentrons-nous sur la chose qu'il ne peut pas faire, à savoir écrire de bons algorithmes.

Javascript n'est pas mauvais en soi. Ce qui est mauvais c'est qu'on puisse changer le type des objets en cours de route (difficile d'optimiser le code une fois compilé) ainsi que l'implantation des objets (beaucoup de validation pour remonter à la bonne méthode). Au départ ce langage n'a pas été fait pour faire des applications web, mais il évolue.

Pour le typage des objets, ECMA 7 pourrait apporter une solution avec Guard (http://wiki.ecmascript.org/doku.php?id=strawman:guards).

Sinon Dart à l'air sympa, comme d'autres langages. Le tout est qu'il faudrait que le langage ne soit pas porté par une entreprise, mais par un consortium en vue d'être normalisé. Sinon ça va rester un truc qui va faire chier les gens à devoir installer un plug-in pour que ça fonctionne ou avec un précompilateur qui fera du JS au final pour les navigateurs incompatibles.

[htoukour]

Je vais le tester et voir ce qu'on y trouve sous le capot.

[phili_b]

Il ne faut pas oublier que pour tout ce qui est Front-End, cela est susceptible d'être utilisé par des graphistes qui ne sont pas forcément développeurs même s'ils ne sont pas imperméables à la programmation. D'où l'intérêt d'une syntaxe JQuery. Mais il faut se rappeler que JQuery n'est qu'une extension de javascript et que rien n'empêche de faire aussi du javascript.

Donc je ne demande pas à ce que Dart soit du JQuery, mais que cette syntaxe soit possible pour tout ce qui est modification des propriétés et des événements standardisés. D'ailleurs même pour les développeurs c'est plus lisible quand ce n'est pas nécessaire de réinventer la roue.

[Invité]

Jquery est très pratique, mais il se justifie de moins en moins.
document.querySelector(), document.querySelectorAll(), window.requestAnimationFrame(), les mediaQuery etc..

Pour Dart, je ne pense pas qu'un portage serai réellement pertinent, il possède tout les équivalent cité ci-dessus, et ce en natif.

En profiter pour critiquer javascript, n'apporte rien de constructif. La preuve en est que tant que tout les navigateurs n'implémenterons pas la vm Dart en natif (Ce qui de toute façon à peut de chance d'arriver), tout ce que nous développerons en Dart sera compiler en JS. Preuve que je Javascript est capable d'en faire autant.
Je n'aime pas ce langage personnellement mais ce n'est pas une raison pour se voiler la face et cracher dessus, ce n'est ni justifier ni justifiable.


Dans un langage il y a une chose qui est capitale, ce sont les librairies. Le gestionnaire de dépendances "pub" est déjà très fourni pour un lancement.
Des librairies pour le SQL, Redis, pdf, openGL, test unitaires, polymer et j'en passe.

C'est souvent sur l'api et les librairies qu'un langage est décisif et sur ce point Dart arrive en 1.0 avec déjà un sacrés bagage.

Flash meurt à petit feu et la syntaxe de dart s'inspire pas mal de Flex, cette nouvelle plate-forme pourrait séduire très facilement les Dev Flex.

Aujourd'hui nous concevons de plus en plus de Web autour des api (REST json ou autres) et Dart est capable de travailler côté client comme serveur.

Il se prête donc facilement à cette approche API. Utiliser dart en client/serveur pour développer les front, et faire appel au Api, pour des CRUD et les tâches métiers.

La communauté à bien compris ce qui fait la puissance d'un langage, avoir porté Angular déjà en beta alors que le langage sort à peine en 1.0. Je pense qu'ils marquent des gros points.

Le fait que Dart doit être compilé en JS pour tout les navigateurs, n'est pas bloquant. De plus en plus de développeurs utilisent déjà des alternatives au Javascript (Coffee, TypeScript...), on s'est déjà fait à l'idée de coder dans un langage pour l’exécuter dans un autre.


Une fois de plus, ce sera quitte ou double, tout dépendra de l’intérêt que les développeurs souhaiteront lui consacrer.
Pour ma part, je suis ravis de le voir arriver en 1.0, Je souhaite à présent le voir en natif dans au moins un navigateur (Chromium ?) afin de pouvoir réellement constater la puissance du Dart natif face au dart2js et javascript, et ce en production.

[LSMetag]

Juste un gros + 1 à ugo-sans-h ! J'aurais pas dit mieux !

C'est pour ça que je suis en train d'utiliser Dart pour mon CV, pour le faire découvrir au monde de l'entreprise.

[rebolon]

On peut ne pas aimer js, mais on peut aussi éviter d'écrire des bêtises. Son implémentation repose sur Ecmascript. Ecmascript n'est pas là pour faire du remplissage de papier, c'est une norme, versionnée, sur laquelle repose les différentes versions de Javascript. Combien de langage peuvent se pré-valoir d'être normé ? Le problème de JS vient des interpréteurs intégrés dans les navigateurs, et surtout de l'historique lié à IE6 (merci Microsoft, au moins vouis avez retenu la leçon avec IE10/11)
Jquery n'est pas du js non plus et si les gens se formaient correctement au JS on aurait moins de soucis. Ca ne sert à rien d'utiliser systématiquement $() alors que document.querySelector/All fait pareil (à condition que sa cible d'utilisateur repose sur des navigateurs récents, mais pas tant que ça)

Typescript n'est pas un langage, mais tout comme coffeescript, une surcouche permettant d'écrire du code à compiler en js avant la mep (de manière manuelle ou auto). Ils ont leur propre implémentation d'un modèle objet sous Javascript, à chacun ses particularités.

Je ne suis pas contre Dart, j'aime ce qui est nouveau, mais quid de Dart sous FF, Opera, IE, ou du mobile ? Comme le dit Ugo-sansH il faut que la VM soit développée pour chaque navigateur dans chaque version d'OS. C'est pas gagné et du coup en attendant il faut dans tous les cas compiler en js pour être sur que ça marche partout, c'est dommage. On se retrouve alors avec une énième surcouche comme type/coffee script

[LSMetag]

On peut ne pas aimer js, mais on peut aussi éviter d'écrire des bêtises. Son implémentation repose sur Ecmascript. Ecmascript n'est pas là pour faire du remplissage de papier, c'est une norme, versionnée, sur laquelle repose les différentes versions de Javascript. Combien de langage peuvent se pré-valoir d'être normé ? Le problème de JS vient des interpréteurs intégrés dans les navigateurs, et surtout de l'historique lié à IE6 (merci Microsoft, au moins vouis avez retenu la leçon avec IE10/11)
Jquery n'est pas du js non plus et si les gens se formaient correctement au JS on aurait moins de soucis. Ca ne sert à rien d'utiliser systématiquement $() alors que document.querySelector/All fait pareil (à condition que sa cible d'utilisateur repose sur des navigateurs récents, mais pas tant que ça)

Typescript n'est pas un langage, mais tout comme coffeescript, une surcouche permettant d'écrire du code à compiler en js avant la mep (de manière manuelle ou auto). Ils ont leur propre implémentation d'un modèle objet sous Javascript, à chacun ses particularités.

Je ne suis pas contre Dart, j'aime ce qui est nouveau, mais quid de Dart sous FF, Opera, IE, ou du mobile ? Comme le dit Ugo-sansH il faut que la VM soit développée pour chaque navigateur dans chaque version d'OS. C'est pas gagné et du coup en attendant il faut dans tous les cas compiler en js pour être sur que ça marche partout, c'est dommage. On se retrouve alors avec une énième surcouche comme type/coffee script

On est d'accord sur le fait que JS soit normé. Et encore, Microsoft a créé son JScript avec sa propre norme.
Le problème, c'est qu'on se retrouve avec les mêmes soucis que ce qu'on peut constater avec le W3C. 10 ans pour chaque version de la norme (je ne parle pas des sous-version qui n'ajoutent presque rien), donc quelque chose qui quelque part n'est pas très propice à l'innovation ou la mode du moment.
Un autre problème dont vous avez parlé, le non respect des normes par chaque navigateur pendant un certain nombre d'années, qui en ont dégouté pas mal du JS.

Les Fans du paradigme objet et du compilé dont je fais partie n'apprécient pas la plupart du temps Javascript. Car contrairement aux langages compilés, on a rien qui nous dit avant l'exécution qu'il y a une erreur. On n'a aucun garde fou qui nous dit "ça va donner ça si vous le mettez dans cette variable" dont le type et la conversion sont implicites. Et à l'exécution, souvent l'erreur est représentée par la non exécution de la totalité (ou d'une partie quand on est chanceux) du script, avec juste un point d'exclamation dans la console et un message d'erreur ne correspondant souvent pas du tout au problème. Difficile également de parcourir le code Javascript pas à pas pour trouver l'erreur, sauf avec des "Alert". Ajoutez à ça les différentes interprétations des navigateurs...

Donc je maintiens qu'il faut être pratiquement expert en JS pour maîtriser et vraiment l'apprécier à sa juste valeur. On n'a pas d'IDE pour nous aider (ou si peu). Les problèmes rencontrés ne sont jamais typiques et résolvables facilement à l'aide de forums. A l'aide de Frameworks comme JQuery, on obtient au final une syntaxe moins verbeuse, un même résultat quel que soit le navigateur, et certaines briques déjà toutes faites.
Les experts en Javascript ça ne court pas les rues, surtout quand on leur demande d'être en même temps experts en J2EE ou .NET.

Ces Framework et le Dart2JS sont moins performants que du natif, mais ils permettent aux développeurs de niveau au moins intermédiaire d'être productifs et de ne pas plancher une demi-journée pour débugguer le moindre petit script. Et je ne parle même pas de la maintenabilité.

Quelque part ça m'est égal qu'on doive compiler Dart en JS. Au contraire, si ça permet de valoriser JS. Ce qui compte c'est que la conversion soit vraiment fiable. Les performances de Dart2JS sont tout à fait honorables d'ailleurs.
Donc la VM pour moi, c'est la cerise sur le gâteau.

Ce que je trouve étrange c'est qu'il n'y est aucun plugin navigateur permettant de disposer de la Machine Virtuelle sous FF ou Chrome. A moins que je ne l'ai tout simplement pas trouvé ?

Je suis prêt à parier que c'est purement commercial.

Vous avez vu comment Google abuse pour imposer Chrome ? Il est souvent installé avec d'autres logiciels si on ne prend pas soin de décocher la petite case peu visible, on a des pubs à la TV, dans la rue,...

J'ai vu aussi que la VM était toujours en développement.

Firefox est open source et ne va pas facilement faire confiance à un big brother comme Google. On voit ce qui s'est passé avec le h264. Au mieux, la VM, créée par Google ou par un développeur lambda en licence open source, sera téléchargeable et traitée comme le plugin Flash ou Java.

Microsoft est, tout comme Google, une société à but lucratif. Et ce n'est pas du tout le grand amour entre les 2.

Même chose pour Apple avec Safari. Apple étant encore plus fermé et big brother que Microsoft ou Google.

[Driktheviking]

Ce que je trouve étrange c'est qu'il n'y est aucun plugin navigateur permettant de disposer de la Machine Virtuelle sous FF ou Chrome. A moins que je ne l'ai tout simplement pas trouvé ?

[laurent1133]

Bonjour je dois apprendre un language client pour une petite appli graphique. Je venais d'arrêter mon choix sur jquery, mais en lisant ceci j'hésite. Dart va-t-il être supporte sur ie et mobile ?
Cdt

[LSMetag]

Bonjour je dois apprendre un language client pour une petite appli graphique. Je venais d'arrêter mon choix sur jquery, mais en lisant ceci j'hésite. Dart va-t-il être supporte sur ie et mobile ?
Cdt

Est-ce que tu VEUX apprendre un langage ou est-ce que tu DOIS l'apprendre ?

Cette nuance est très importante :

JQuery est une bibliothèque Javascript très utilisée, même dans le monde professionnel. Tu trouveras toujours du boulot dessus. Elle est assez mature (déja la version 2.0). Tu dois néanmoins connaître un minimum Javascript pou l'utiliser. Pour IE (version 9 minimum pour les nouvelles versions de JQuery) et mobile aucun problème.

Dart, c'est un peu un pari. C'est un autre langage que Javascript. Il te plaira peut-être plus si tu n'aimes pas Javascript, mais ce sera probablement à toi d'essayer de l'imposer. Il vient à peine de sortir et les entreprises ont toujours un train de retard, niveau technologie, surtout parce que souvent elles attendent que les autres aient essuyé les plâtres. Normalement le code généré est compatible tout navigateur, avec IE version 9 minimum.

Donc d'un point de vue avenir professionnel, Javascript et JQuery.

D'un point de vue étudiant ou passionné de POO, je dirais Dart, notamment pour essayer de le propager. Il ne faut pas oublier que l'avenir de Dart n'est pas défini puisqu'il vient de sortir. Cette techno peut très bien finir aux oubliettes comme elle peut finir par supplanter JS. Donc commencer un projet pro dessus est un pari risqué. Mais prouver qu'elle est très bonne et le faire savoir avec de vraies créations est également une option.

Je fais partie de la catégorie des passionnés téméraires

[ivanpierre]

Et qu'ainsi on puisse compiler ce qu'on veut de manière efficace. Dart -> Js, ClojureScript->js, c'est tj du js...
Quand à du Google Dart comme natif... encore dix ans de programmeurs qui vont se foutre de notre gueule...