Discussion :

[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.

[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++.

[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 ?

[LSMetag]

L'utiliser, non... enfin, non tant qu'il ne fonctionne pas sur tous les navigateurs.
Si au moins Firefox l'utilisait, voir Safari, on aurait un débouché sympa. Mais Chrome n'est pas suffisant selon moi.
En plus, ce navigateur n'est pas accepté dans ma boite pour des raisons de sécurité. (mais je suppose que Chromium embarque DART non ?)

Au final, plus qu'un bon travail, je pense que google doit mettre en place un très fort lobbying pour intégrer DART au moins dans firefox(quitte a payer le développement du module) Ca amènerai a une couverture d’environ 50% des utilisateurs, ce qui est pas trop mal(et surtout, ca amène a 95% d'un type d'utilisateurs que je qualifierai d'avertis et pointilleux)

Là tu parles vraiment du DART pur. Mais tu peux le compiler en Javascript pour les autres navigateurs. Niveau performances, cette conversion équivaut à l'utilisation d'une librairie style JQuery et peut parfois même dépasser du natif.
Donc je ne vois pas où est le problème, à part bien sûr d'éventuels bugs de la conversions Dart2Js.

[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.

[stailer]

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

Oui c'est ça... Apparemment j'ai vu sur le site de Kendo que c'est en préparation.

Lien officiel vers le dév en cours : https://github.com/kendo-labs/angular-kendo

[Marco46]

Oui c'est ça... Apparemment j'ai vu sur le site de Kendo que c'est en préparation.

Lien officiel vers le dév en cours : https://github.com/kendo-labs/angular-kendo

Ah ben ok.

Parce que j'allais te dire que le mieux c'est d'utiliser Bootstrap et Angular-Ui.

[DonQuiche]

A mon sens le web n'a pas besoin d'un nouveau langage pour remplacer JS, il a besoin d'un mécanisme permettant aux développeurs d'utiliser efficacement le langage de leur choix.

Pour l'heure NaCL et asm.js semblent être les meilleurs candidats. Pour ma part je prône le premier.

[mlp56]

Lol je vois pas comment il va détroner java ...


☻
/▌\ ︻╦╤─
░░░███████ ]▄▄▄▄▄▄▄▄ GOOGLE
▂▄▅████████▅▄▃▂
I███████████████████]

[CapFlow]

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.

Je suis plutôt d'accord sur le fond.

Mais remplacer JS n'amènera à rien de mieux.

Et puis, si j'interprète ton message, jQuery serait à moitié une librairie.
S'il se débarrassait de tout ses sélecteurs et autre qui changent le langage en ne gardant que des éléments clés (ajax, animate et autre), je dis pourquoi pas !

NB: Il ne faut pas croire que personne n'aime JavaScript. C'est surtout que plus beaucoup de personnes n'ont envie de défendre le langage face à ceux qui disent "c'est vieux, c'est nul, c'est moche ...". On tombe toujours dans le même débat.

[LSMetag]

Je suis plutôt d'accord sur le fond.

Mais remplacer JS n'amènera à rien de mieux.

Et puis, si j'interprète ton message, jQuery serait à moitié une librairie.
S'il se débarrassait de tout ses sélecteurs et autre qui changent le langage en ne gardant que des éléments clés (ajax, animate et autre), je dis pourquoi pas !

NB: Il ne faut pas croire que personne n'aime JavaScript. C'est surtout que plus beaucoup de personnes n'ont envie de défendre le langage face à ceux qui disent "c'est vieux, c'est nul, c'est moche ...". On tombe toujours dans le même débat.

Personnellement je n'aime pas Javascript. Et pourtant je m'accroche. Pourquoi maintenant on est passé au JQuery dans beaucoup d'entreprises ? Pour rendre le Javascript plus utilisable par le développeur moyen. Car il faut une certaine expertise à mon avis pour bien gérer du JS de base.

Pour moi, DART est comme une sorte de JQuery, avec la possibilité de multiplier les perfs si on a la chance d'avoir le navigateur qui va bien.

[Zefling]

Et puis, si j'interprète ton message, jQuery serait à moitié une librairie.
S'il se débarrassait de tout ses sélecteurs et autre qui changent le langage en ne gardant que des éléments clés (ajax, animate et autre), je dis pourquoi pas !

Jquery est un framework, le plus populaire, mais il y en a d'autre.

Je remarque beaucoup l'utilisent pour sa gestion par sélecteur... Du coup, beaucoup ne savent même pas que querySelector("selector") existe qui fait grosso modo la même chose que $("selector") avec sa couche Jquery par dessus.

Code :

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

1
2
3
$ = function (selector) {
  return document.querySelectorAll(selector);
};

Car il faut une certaine expertise à mon avis pour bien gérer du JS de base.

Ce qui est valable pour tous les langages ou frameworks. J'ai vu de belles horreurs en Java. En partie parce que le langage est très strict, un mauvais développeur pour arriver à ses fins fait des trucs d'une débilité ahurissante. Des types qui venaient du développement d'application lourde, qui n'avaient jamais fait de web et qu'on a foutus sur la création d'un site web. Le type n'avait aucune expertise pour ça... et là ce n’est pas la faute du langage, c'est qu'ils ne sont pas formés. Mais quand tu les écoutes, ils accusent le langage d'être merdique.

[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.

[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.

[Watilin]

Il est temps de remplacer le Javascript par un langage qui n'a pas été écrit en quelques heures

Ça c'est du troll bête et méchant. Va dire à Brendan Eich que JS a été écrit en quelques heures…

Pour moi, habituellement défenseur de JavaScript, je trouve que Dart est un projet intéressant. Je suis séduit par la syntaxe, proche de JavaScript mais avec les aspects qui lui manquent cruellement, à savoir une vraie gestion des classes, un typage explicite, des modules, etc. Nombre de ces aspects sont d'ailleurs en projet pour les futures versions d'ECMAScript.

Après, il faut savoir que Dart est comme TypeScript ou GWT : ce n'est pas un nouveau langage client. Ça se compile en JS. Alors quand je lis « Dart est plus rapide que JS » j'ai envie de dire your argument is invalid. Mais sinon, un langage agréable à utiliser, avec une belle syntaxe et qui se compile en JS, je dis pourquoi pas. C'est comme CoffeeScript.

Le truc qui me dérange c'est Google. J'ai vraiment du mal à faire confiance à cette firme. Quand on sait qu'ils parlent de retirer TamperMonkey du Chrome Web Store, ça en dit long sur l'importance qu'ils accordent aux libertés de leurs utilisateurs.

[LSMetag]

Après, il faut savoir que Dart est comme TypeScript ou GWT : ce n'est pas un nouveau langage client. Ça se compile en JS. Alors quand je lis « Dart est plus rapide que JS » j'ai envie de dire your argument is invalid. Mais sinon, un langage agréable à utiliser, avec une belle syntaxe et qui se compile en JS, je dis pourquoi pas. C'est comme CoffeeScript.

Dart est réellement plus rapide que JS si utilisé en tant que tel (avec la machine virtuelle DART, sans conversion Javascript). Donc en gros, si utilisé sous Chromium ou Chrome (pour le moment).

[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.