JavaScript : un monde en perpétuelle évolution qui rime avec une remise en question

**danielhagnoul** · 02/09/2014, 16h39

SVG : il y a longtemps que j'ai abandonné http://raphaeljs.com/ pour http://d3js.org/.

Avec l'arrivée prochaine des nouveautés dans tous les navigateurs non obsolètes, il est vrai que le Vanilla JS suffira pour faire la plupart des travaux.

Mais il y a : "arrivée prochaine", "navigateurs non obsolètes" et les habitudes prises par au moins une génération de programmeurs web. De plus, même lorsqu'elles seront disponibles, il faudra du temps pour digérer les nouveautés.

J'en ai douté il y a quelques mois, après la lecture d'une série d'articles pessimistes, mais je ne "crie plus avec les loups". D'autres faits me font croire que jQuery survivra encore quelques années.

Vanilla JS a toujours été verbeux et il me semble que cette tendance s'amplifie avec l'intégration des nouveautés. Je ne crois pas être le seul à ne pas aimer les langages verbeux.

Le code (du Vanilla JS) de la branche 2 de jQuery va certainement évoluer en intégrant les nouvelles possibilités dès qu'elles seront normalisées et disponibles sur la plupart des navigateurs non obsolètes.

**kdmbella** · 03/09/2014, 02h48

Envoyé par danielhagnoul

SVG : il y a longtemps que j'ai abandonné http://raphaeljs.com/ pour http://d3js.org/.

J'avais jamais entendu parlé de d3js je vais de ce pas voir ce qu'il propose. Pour ce qui est de jQuery et autres framework "syntaxe like" j'avoue que cette manière ne m'a jamais plu je la trouve non standard et en contradiction avec ce que je sais déjà du développement web du coup j'ai jamais essayé

**vermine** · 05/09/2014, 14h02

L'équipe Sencha du framework ExtJS, étroitement liée à YUI (historiquement du moins), a réagi à cette annonce :

A Fond Farewell to YUI (Adieu à YUI)

Voici un résumé de ce qui est dit. C'est une traduction transversale.

----------

Ils expliquent les liens qu'il y avait au début mais rassurent en disant que ExtJS a pris un autre chemin.

Ils ont également publié une image de la pile moderne du JavaScript. C'est une comparaison (voire une promotion pour eux) entre ce qui est implémenté en AngularJS et ExtJS.

En fait, l'équipe Sencha constate que la pile JavaScript third party est problématique dans les entreprises. Pour certains types d'application (par exemple une pure application de contenu qui cible les navigateurs modernes, écrite et maintenue par un seul développeur) un framework n'est pas nécessaire. En revanche, pour un ensemble d'applications complexes et interdépendantes développées par diverses (grandes) équipes, il vaut mieux adopter un framework unique, basée sur des normes au sein de l'entreprise.

AngularJS sort actuellement du lot et devient populaire mais reste incomplet. Il y a un certain nombre de questions à court et à long terme avec cette stratégie. Sans une architecture ou un style de codage communs, les tests et la maintenance deviennent difficiles car le framework "maison" se développe au fil du temps. Chaque bibliothèque indépendante peut apporter une interprétation subtilement différente des fonctionnalités apparemment similaires. Et surtout, l'équipe de développement doit faire face à plusieurs cycles de versions qui ne sont pas toujours synchronisées entre elles. C'est pourquoi Sencha offre un framework beaucoup plus global conçu et testé pour que toutes fonctionnalités soient compatibles, maintenues et mis à jour de façon synchronisée.

----------

Question d'opinion et d'intérêt me direz-vous. S'enfermer avec un seul outil et ne pas trop en sortir, ou bien devoir gérer plusieurs outils en même temps mais en ayant une plus grande liberté.

**SylvainPV** · 05/09/2014, 15h20

Cette comparaison est ridicule, tout comme l'est l'ambition d'ExtJS de devenir l'unique outil pour faire tout et n'importe quoi. Je trouve qu'Angular est déjà bien assez vaste comme ça. Ce n'est pas étonnant que les développeurs commencent à en avoir ras-le-bol des frameworks, en particulier en JavaScript. Au lieu d'avoir une boîte à outils où l'on peut choisir pour chaque tâche l'outil le plus adéquat, on essaie de nous refourguer un couteau suisse.

**Marco46** · 05/09/2014, 17h52

Effectivement la comparaison est ridicule compte tenu des différences d'âges entre les deux framework. D'autant plus que leur graphique est carrément mensonger l'approche n'étant pas la même. Angular a une approche modulaire, cela signifie que toutes les cases en gris dans la partie angular sont passable en vert avec le module qui va bien.
C'est un peu comme faire une comparaison entre .NET (qui est un environnement très intégré) avec Java (et son armée de librairies externes) en terme de fonctionnalités.

Sur AngularJS et jQuery je suis en complet désaccord avec vous. D'abord Angular ne dépend pas de jQuery et n'embarque pas non plus jQuery. Il embarque une version light de jQuery nommée jQueryLite qui a été réécrite par l'équipe pour l'occasion.

De plus, il est fortement conseillé dans un projet Angular de ne pas utiliser du tout jQuery. Après plusieurs projets pro et perso réalisés je me rends compte que jQuery devient complètement inutile sauf à de très rares exceptions (notamment en dev web mobile).

Au final, il s'agit de deux outils complètement différents, jQuery est une boite à outil (ou une collection de librairies si vous préférez) et ne fournit aucun cadre pour le développement, Angular est un framework structurant pour une application. Il introduit des notions complètement absentes de jQuery (le databinding, l'injection de dépendance, l'enrichissement du HTML via les directives, une gestion déclarative des templates, ... etc ...)

A application égale, une application web écrite avec jQuery nécessite beaucoup plus de code qu'une application écrite avec angular (ou un autre framework js moderne, je pense à EmberJs par exemple) et le code est beaucoup moins clair, et plus difficilement testable.

En bref, en ce qui me concerne jQuery appartient déjà au passé.
(EDIT : Pour compléter, je veux pas dire que jQuery c'est de la m.... Je veux juste dire que jQuery a rempli sa mission qui était de combler les manques du javascript, pour moi son destin et de se fondre petit à petit dans les évolutions du langage en lui même)

Après, Angular a été conçu pour le développement d'applications web single page (et pas pour du dev de sites web au sens large), et se spécialise pour les mobiles (qui est le périphérique de l'avenir pour le web).

Si vous travaillez dans le web avec une architecture contenant du templating côté serveur, inquiétez-vous vous êtes entrain de manquer un wagon important.

L'architecture du futur c'est un client léger autonome écrit en html/css/js qui tape sur des services web REST pour intéragir avec un backend qui ne contient pas une seule ligne de html/css/js.

**SylvainPV** · 05/09/2014, 18h19

@Marco46: je n'ai pas dit qu'Angular embarquait jQuery, seulement qu'il l'utilisait en interne s'il est disponible. Si jQuery n'est pas présent, AngularJS reprend effectivement sa propre implémentation de jQuery lite. Et oui, en théorie il n'y a pas beaucoup d'intérêt à vouloir utiliser conjointement jQuery et Angular. Mais si Angular a fait ce choix d'implémentation en interne, ce n'est pas anodin : c'est pour faciliter la transition, autant pour le développeur qui retrouve une API qu'il connaît, que pour tous les plug-ins jQuery existants et encore utilisés aujourd'hui. Enfin, j'ai bon espoir qu'avec ES6 on finisse par arrêter de faire des plug-ins de ceci ou cela pour se contenter du Vanilla.

**kdmbella** · 09/09/2014, 04h05

Question : étant donné cette décision de chez Yahoo concernant YUI, ont-ils communiqué
sur comment ils comptent dorénavant réaliser les IHM de Yahoo mail ?
Car d'après ce que je sais, les interfaces de Yahoo mail sont fortement dépendantes du Framework YUI du coup
on est obligé de se demander l'orientation qu'ils veulent prendre de ce côté là : ont-ils prévu de faire du "From scratch" (ce qui
serait étonnant pour une telle application) ou alors comptent-ils utilisée des bibliothèques déjà existante ?

**petitjojogolo** · 30/09/2014, 14h38

L'histoire de la comptabilité entre navigateurs est une bétise.

Moi je fais des programmes, et je dis "C'est uniquement compatible avec Firefox point final" par exemple.
Pourquoi devenir fout à tenter de faire tourner ses programmes dans des navigateurs de M.... du style Explorer ?

Ce sont les clients finaux qui ont la responsabilité de télécharger le bon navigateur, point final

**Watilin** · 30/09/2014, 15h47

C'est naturel de vouloir s'épargner des efforts. Et c'est tentant quand on débute de vouloir changer le monde. Le monde évolue, mais à son rythme… IE6 est mort, c'est déjà un beau progrès non ?

Les incompatibilités sont malheureusement nécessaires car elles font partie du processus d'évolution des navigateurs. Les frameworks JavaScript sont là pour faire le travail à notre place, utilisons-les !

Si tu demandes à tes clients de s'adapter à ton produit, tu risques fort de les voir partir en courant. C'est une marque de qualité que de proposer des logiciels qui s'adaptent, qui marchent sur le plus grand nombre de plateformes. Si tu ne penses pas de cette façon, tu te fermes des portes. Tu comprendras sans doute ça avec le temps.

**SylvainPV** · 30/09/2014, 17h02

@petitjojogolo: le fait que tu appelles un site web "programme" donne déjà beaucoup d'indices

Dans un vrai contexte web, tu ne connais ni tes clients, ni leurs environnements. Et si tu rejettes un client parce qu'il n'a pas le bon navigateur selon toi, il ne reviendra jamais à moins d'y être forcé (par son employeur).

**chris52** · 06/10/2014, 11h28

Bientôt la fin des librairies (propriétaires) !

**arnogues** · 10/10/2014, 07h27

Quelles sont les librairies propriétaires que tu pourrais me citer ?
Car personnellement j'en utilise aucune

**vermine** · 06/11/2014, 13h50

Envoyé par kdmbella

Question : étant donné cette décision de chez Yahoo concernant YUI, ont-ils communiqué
sur comment ils comptent dorénavant réaliser les IHM de Yahoo mail ?
Car d'après ce que je sais, les interfaces de Yahoo mail sont fortement dépendantes du Framework YUI du coup
on est obligé de se demander l'orientation qu'ils veulent prendre de ce côté là : ont-ils prévu de faire du "From scratch" (ce qui
serait étonnant pour une telle application) ou alors comptent-ils utilisée des bibliothèques déjà existante ?

Il semblerait qu'ils aient finalement opté pour Node.JS et ReactJS.