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

JavaScript : un monde en perpétuelle évolution qui rime avec une remise en question
Yahoo! arrête le développement de sa bibliothèque JavaScript YUI


JavaScript évolue vite et dans beaucoup de directions différentes. Il semble incontournable aujourd'hui. Devant tous les frameworks et bibliothèques existants, il est difficile de choisir. Quelles sont les meilleures manières de faire ?

Developpez.com se posait déjà la question il y a quelques années par exemple dans ce débat sur la direction que prend le JavaScript ou bien dans cette présentation sur la place du JavaScript côté serveur.

Aujourd'hui, c'est un grand de l'informatique qui s'est remis en question. Utilisée par Yahoo! depuis 2005, la bibliothèque YUI a toujours eu le même objectif : celui de fournir un ensemble d'outils complet pour rendre plus facile la création d'applications Web riches. Cependant, il est devenu clair pour l'équipe que l'industrie se dirige vers une nouvelle direction. Les dernières évolutions dans le monde JavaScript rendent ce dernier omniprésent.

• Serveur : Node.JS a relancé l'utilisation du JavaScript côté serveur.
• Packaging : npm, bower, etc. ont favorisé l'essor d'un écosystème open source, avec des outils qui se complètent mutuellement, embrassant la philosophie UNIX et permettant des cas d'utilisation de développement très complexe.
• Build : Grunt, Gulp, etc. rendent plus facile l'assemblage des petits modules dans des applications larges et cohérentes.
• Framework applicatifs : Backbone, React, Ember, Polymer, Angular, etc. ont contribué à rendre l'architecture des applications Web plus évolutives et maintenable.
• Test : Mocha, Casper, Karma, etc. ont facilité la gestion des tests.
• Standards : W3C et Ecma ont normalisé ce que les grands frameworks JavaScript ont mis sur la table au cours des années, permettant ainsi leur mise à disposition en mode natif à un plus grand nombre de périphériques.
• Navigateurs : ils sont maintenant engagés à apporter des améliorations continues tout en s'alignant le plus possible aux normes.
• Etc.

Ces fréquentes évolutions ont pour conséquence que des outils complets comme YUI reçoivent moins d'attention. Moins de nouveaux utilisateurs, moins de retours des utilisations actuelles, etc.
La mission de l'équipe YUI est d'offrir les meilleures technologies de la nouvelle génération avec un accent sur les développeurs internes. C'est pourquoi les nouveaux développements sur cette bibliothèque sont arrêtés dès aujourd'hui. Les éventuelles révisions concerneront uniquement des points critiques.

Source : blog de Yahoo!


Et vous ?

:fleche: Connaissez-vous d'autres outils JavaScript qui ont disparu ou qui sont en perdition ?

:fleche: Quels sont pour vous les meilleures combinaisons d'outils pour créer vos applications ?

:fleche: Que pensez-vous de ces évolutions et qu'aimeriez-vous pour l'avenir ?

Ces librairies n'auront bientôt plus raison d'exister grâce aux navigateurs qui adoptent des rythmes de release + élevés tout en étant le plus proche possible des normes.

Prototype (2005 - 2010 même si y'a toujours quelques petits commits)
YUI (2005 - 2014)
Mootools (2006 - ???)
jQuery (2006 - ???)

MooTools est déjà au ralenti (voire à l'arrêt) depuis un certain temps et la dernière mise à jour sert surtout à redevenir compatible avec les évolutions des navigateurs. Je ne suis pas sûr qu'ils atteindront la version 2.0. Edit : Quoiqu'il y a une nouvelle révision qui vient de sortir. ^^

Je pense que jQuery a encore quelques beaux jours devant lui car sa communauté est grande et active.

est-ce que Node.JS ou Angular peuvent complètement remplacer jQuery ?

Il faut savoir tourner la page, on ne peut pas maintenir une même approche et API pendant dix ans si tout l'environnement autour change radicalement.

@sami_c: Node.JS, Angular et jQuery n'ont rien à voir entre eux. Le premier est un environnement serveur bâti sur un moteur d'exécution JavaScript, le second est un framework Model/View qui utilise jQuery en interne, et jQuery est une bibliothèque rassemblant des fonctions utilitaires, en particulier autour de la manipulation du DOM et l'AJAX.

Citation:

---

Envoyé par vermine

MooTools est déjà au ralenti (voire à l'arrêt) depuis un certain temps et la dernière mise à jour sert surtout à redevenir compatible avec les évolutions des navigateurs. Je ne suis pas sûr qu'ils atteindront la version 2.0.

Je pense que jQuery a encore quelques beaux jours devant lui car sa communauté est grande et active.

---

D'autant plus que la force de jQuery ne se limite pas simplement à son framework de fonctionnalités (qui sont de plus en plus implémenté nativement par javascript) mais aussi et surtout par le nombre important de ressources et de plugin proposés comparé aux autres frameworks : jquery-ui, mobile, et ceux créés par la communauté (slideshow, datatables, etc...)

Citation:

---

Ces librairies n'auront bientôt plus raison d'exister grâce aux navigateurs qui adoptent des rythmes de release + élevés tout en étant le plus proche possible des normes.

---

Les navigateurs sont de plus en plus au points mais tu auras toujours une grosse partie des internautes ayant 5 ou 6 versions de retard.
Par ailleurs, chaque navigateur continue de développer ses propres spécificités, le rêve du compatible partout me paraît encore lointain.

Citation:

---

Envoyé par Sodium

Les navigateurs sont de plus en plus au points mais tu auras toujours une grosse partie des internautes ayant 5 ou 6 versions de retard.
Par ailleurs, chaque navigateur continue de développer ses propres spécificités, le rêve du compatible partout me paraît encore lointain.

---

À court terme, peut-être, mais dans 3 ans... Même avec beaucoup de retard, il y aura quand même une avance significative. On est plus à l'ère 9X/XP où les choses pouvaient rester statiques pendant plusieurs années pour les navigateurs. Le support le plus long de Mozilla ça reste 1 an. Aucun pour Chrome ou Opera. Il ne reste qu’IE qui tant de plus en plus à faire comme les autres. Le support d'IE 8-9 ne seront jamais aussi long que celui d'IE6, ça sera encore plus court pour IE 10 et suivant.

Citation:

---

Le support d'IE 8-9 ne seront jamais aussi long que celui d'IE6, ça sera encore plus court pour IE 10 et suivant.

---

Certes, mais va expliquer à ton client que tu ne veux pas adapter ton code à l'avant-avant-dernière version d'IE sous prétexte qu'elle n'est plus supportée. Il s'en fiche que la version soit supportée ou non, s'il reste 5% de gens dessus ça reste 5% qui doivent pouvoir accéder au site normalement.
Par ailleurs, je n'utilise jamais Internet Explorer donc j'ignore comment il se met à jour, mais s'il se met à jour via Windows update il faut faire avec une grande portion d'utilisateurs qui piratent Windows et ne font donc pas nécessairement ces mises à jour.

Citation:

---

Envoyé par Sodium

s'il se met à jour via Windows update il faut faire avec une grande portion d'utilisateurs qui piratent Windows et ne font donc pas nécessairement ces mises à jour.

---

Crois-moi, pirater Windows n'empêche pas de faire les mises à jour et ces pirates n'utilisent pas IE7 :P

IE est passé lui aussi à la mise à jour transparente depuis IE11, on peut donc espérer que les versions obsolètes seront minoritaires, comme pour Chrome aujourd'hui.

Les navigateurs sont déjà très respectueux des standards. Ils ne peuvent pas l'être totalement car les standards évoluent, ne sont pas parfait... Mais les navigateurs ont pour but de réaliser la "couche basse" de l'application Web, une couche très optimisés évoluant lentement. (C'est un peu l’assembleur voire le C/C++ de l'informatique) Il faut des librairies plus haut niveau comme JQuery pour donner des fonctionnalité haut niveaux au détriment des performances (C'est un peu le PHP/Python). Certes les standards évoluent pour intégré aux navigateurs quelques fonctionnalité des librairies haut-niveau mais cela doit se faire lentement pour assurer une pérennité du standard. L'avantage des librairies c'est quelles sont libres de tous standard donc qu'elle peuvent rechercher les pistes d'évolutions même si beaucoup seront abandonnées. Ainsi les navigateurs sont compatible avec les premier standards HMTL/Javascript.

Pour continuer le parallèle PHP/Python peuvent être changé assez facilement si on leur trouvent mieux (Java ;) ) en comparaison, revenir sur l'assembleur demande un travail absolument inconcevable car alors absolument tout en informatique devrait être repris...

@abriotde: pourquoi est-ce que les standards devraient évoluer lentement ? Dans tous les cas, il y a rétrocompatibilité donc la pérennité est conservée. Et les bibliothèques ont besoin de cette évolution des standards pour progresser, c'est essentiel. Par exemple Angular.js va pouvoir utiliser Object.observe pour des gains de perf et de taille de code énormes. Plus vite Object.observe sera implémenté, mieux ce sera. Et tous ces parallèles avec les langages serveur et l'assembleur m'ont l'air assez hors-sujet :weird:

Javascript est devenu totalement débordant.Le pluralité des frameworks qui pilulent sur le marché ne fini pas par rendre la vie facile au développeur.
Tu te retrouves dans une même entreprise avec des développeurs qui travaillent sur des projets avec du JS mais avec des frameworks différents puis 3 ans plustard lors des maintenances,l'un des developpeurs te dit

Citation:

---

"moi je fait avec Yahoo UI je ne connais pas JQuery UI"

---

et L'autre

Citation:

---

j'ai pas encore utilisé NodeJS ou Backbone.js.

---

Alors tu vois un nouveau stagiaire te demande s'il peut utiliser Dart.Et là tu te pose plein d'autres questions.Juste pour dire que de nos jours le choix d'un framework JS n'est plus aisé car il peut rapidement se faire renverser par un nouveau venu

Bonjour,

D'accord avec Seb33300 et Vermine, parmi les lib, jquery est sans doute celle qui sera la plus pérenne. La tendance n'est pas nouvelle puisque quand je me suis enfin décidé à travailler avec une lib javascript il y a quelques années, le choix de jquery s'imposait déjà de par ses fonctionnalités, son dynamisme, sa communauté et le nombre de modules proposés. Aujourd'hui il est presque rare de trouver un site ne l'utilisant pas...

Le temps que les utilisateurs aient tous un navigateur dernière version, le temps que javascript offre nativement les mêmes fonctionnalités, et le temps que de nombreux développeurs perdent l'habitude de l'utiliser sans même en avoir un réel besoin (je veux dire pour ne gagner que quelques lignes de code, ce qui m'arrive souvent parce que je sais qu'il a déjà été chargé pour d'autres scripts), en effet son avenir semble assuré pour assez longtemps.

Citation:

---

Connaissez-vous d'autres outils JavaScript qui ont disparu ou qui sont en perdition ?

---

Il y a une bibliothèque pour le dessin vectoriel RaphaëlJs que j'aimerai voir évoluer plus rapidement mais il me semble qu'ils sont un peu à la traîne.

Citation:

---

Quels sont pour vous les meilleures combinaisons d'outils pour créer vos applications ?

---

Pour moi dans mes développements j'essais d'une part d'être le plus natif possible et d'autre part
d'adopter des bibliothèques qui restent le plus possible dans une logique native et évolutive et dans ce cadre
dhtmlx me satisfait assez.

Citation:

---

Que pensez-vous de ces évolutions et qu'aimeriez-vous pour l'avenir ?

---

J'aimerai que le JS évolue de façon à devenir un langage suffisamment robuste et complet pour ne plus avoir besoin
d'une bibliothèque supplémentaire pour faire quoi que ce soit. Je pense qu'avec la naissance et la mort des différents outils
on devrait penser à fédérer tout ce qui a poussé à leur naissance pour fournir un JS "Prêt pour tout".

Par contre concernant YUI que j'ai utilisé dans mes développements dans ça version 2, il m'a toujours semblé
assez complexe à utiliser mais très puissant. Espérons que Extjs/Sencha qui est un fork de YUI ne sera pas perturbé
par cette décision.

Moi j'attends la disparition de JQuery !

J'admire le boulot fait par les concepteurs de ce framework et par les contributeurs, mais quand je vois des gens qui se disent "développeurs JQuery" ça m'énerve et me consterne à la fois.

Mais bon, un autre truc du genre prendra sa place je suppose...

Citation:

---

Envoyé par kdmbella

J'aimerai que le JS évolue de façon à devenir un langage suffisamment robuste et complet pour ne plus avoir besoin
d'une bibliothèque supplémentaire pour faire quoi que ce soit. Je pense qu'avec la naissance et la mort des différents outils
on devrait penser à fédérer tout ce qui a poussé à leur naissance pour fournir un JS "Prêt pour tout".

---

Euh tu ne crois pas que c'est un peu extrême, "ne plus avoir besoin d'une bibliothèque supplémentaire pour faire quoi que ce soit" ? JavaScript est déjà un langage très riche, je ne pense pas que ce soit une bonne idée de venir le surcharger exagérément.

Citation:

---

Envoyé par SylvainPV

Euh tu ne crois pas que c'est un peu extrême, "ne plus avoir besoin d'une bibliothèque supplémentaire pour faire quoi que ce soit" ? JavaScript est déjà un langage très riche, je ne pense pas que ce soit une bonne idée de venir le surcharger exagérément.

---

Ben quitte à surcharger, autant le faire avec en rajoutant du natif plutôt qu'un(e) blibliothèque / framework qui utilise le language en question.

Enfin moi je trouve ça plus logique.

Citation:

---

Envoyé par jojosbiz

Ben quitte à surcharger, autant le faire avec en rajoutant du natif plutôt qu'un(e) blibliothèque / framework qui utilise le language en question.

---

Cela se fait bien mais pas vite car il faut un consensus. Si cela peut être assez simple de se mettre d'accord sur l'implémentation de sélecteurs largement plébiscités, d'autres fonctionnalités proposées dans les lib sont d'un intérêt plus marginal et il est normal qu'on évite de surcharger le code natif pour satisfaire tous les besoins sinon c'est no limites.

Citation:

---

Envoyé par ABCIWEB

Cela se fait bien mais pas vite car il faut un consensus. Si cela peut être assez simple de se mettre d'accord sur l'implémentation de sélecteurs largement plébiscités, d'autres fonctionnalités proposées dans les lib sont d'un intérêt plus marginal et il est normal qu'on évite de surcharger le code natif pour satisfaire tous les besoins sinon c'est no limites.

---

Je suis bien d'accord avec toi, avec une légère nuance...je remplacerai "tous les besoins" par "toutes les fainéantises" (je sais je suis un peu radical mais bon...)

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.

Citation:

---

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é :weird:

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

:fleche: 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é.

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.

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.

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

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 ?

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

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.

@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).

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

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

Citation:

---

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. ;)

http://media.tumblr.com/e58f0e5de009...jav1t2nk29.png

Citation:

---

Envoyé par arnogues

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

---

Sensa JS

Citation:

---

Envoyé par vermine

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

---

Merci ça me permet de lancer un coup d’œil sur le Framework ReactJS... je n'en avais pas encore entendu parler ...