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