Open source et architecture logicielle

Je penses que ce qui a aussi pas mal contribué à l'essor de jQuery, c'est surtout qu'il assurait la compatibilité IE. Un même code pour tous les navigateur, ça s'était de l'or pour le développeur des années 2000.

Aujourd'hui, javascript a beaucoup évolué. Les navigateurs aussi. Et de plus en plus, je tourne le dos à jQuery. Je trouve qu'avec le javascript d'aujourd'hui, on peut faire autant de chose qu'avec jQuery, avec quelques lignes de code en plus certes, mais ça reste raisonnable.

Un des problème principal qui m'a fait me détourner de jQuery, c'est que la plupart des développeur ne savent finalement pas l'utiliser. Ils l'utilisent parce que la syntaxe est courte est clair, mais ils ne savent (ni ne cherche à savoir) comment ça fonctionne derrière. Ce qui amène a du code vraiment peu performant où des manipulation du DOM sont mis en boucle, etc. Les développeurs débutants ont tendance à penser que plus la syntaxe est courte, plus c'est efficace. Ce qui est faux bien entendu. A chaque instant, il faut vouloir avoir envie de savoir comment ça fonctionne derrière pour bien faire.

Le pire, c'est que la plupart des élèves issus de filières informatiques apprennent le javascript en faisant du jQuery en cours. Et ça, je trouve ça dramatique. On ne devrait pas apprendre jQuery sans savoir utiliser javascript parfaitement. Au final, ces derniers ne savent même pas comment fonctionne le DOM, les objets, le prototype, l' "héritage" ou ce genre de chose.

Finalement, en interdisant l'utilisation de jQuery à mon équipe de développement, déjà, ils ont dû passer un peu de temps au début dans la doc MDN. Mais finalement, ils y ont appris plein de trucs qu'ils ne connaissaient pas. Ils comprennent mieux comment fonctionne le DOM. Il font du code plus efficace et plus propre. Et aujourd'hui, ils codent aussi vite un front-end javascript que jQuery à l'époque.

Le problème principal maintenant, c'est que beaucoup de framework sont basé sur jQuery. Et ça, c'est très embêtant. Bootstrap pour ne citer que lui. Et je trouve dommage qu'il ne se soit pas affranchi de jQuery pour sa nouvelle version 4... En ce moment, nous sommes en train de découvrir de nouveaux framework qui fonctionnent sans jQuery, et ça, c'est cool. Je penses à React par exemple, que nous avons adopté pour nos nouveaux développements.

Jquery était quand même loin d'être en situation de monopole , il y'avait mootools et prototype (avec l'excellent scriptaculo.us) qui était là avant et qui ont lutter un petit moment

Jquery est trop gros pour être la base d'autre framework , on se retrouverait vite avec des lib énorme pour pas forcément grand chose. Par contre Sizzle (le moteur de selection css) peut à mon avis se retrouver un peu partout

"Cette bibliothèque était incontournable pour ses performances"

C'est principalement pour des raison de perfs que j'ai radié jQuery de mon utilisation (vive Vanilla JS!), je ne l'utilise qu’exceptionnellement quand un framework me l'impose (bootstrap).

Le seul vrais intérêt de jQuery c'était la compatibilité avec tous les navigateurs, chose plus vraiment d'actualité, IE7 c'est oublié et les polyfill se sont bien démocratisé.

"les bibliothèques maison ont été abandonnées au profit de standards consacrés par l’usage"

???
Pas vraiment non, malgré la grosse mode des "angular & cie" les frameworks maison sa se fait encore et sa se fera encore, avec du jQuery ou non.
C'est un peux comme PHP (et probablement d'autre langage au innombrable framework), c'est pas parce que la grosse mode est de parler uniquement des nouveauté dans les framework, que plus personne ne fais du sur mesure...

Envoyé par grunk

Jquery est trop gros pour être la base d'autre framework , on se retrouverait vite avec des lib énorme pour pas forcément grand chose.

83k actuellement dans sa version compressée, ça me parait pas exorbitant quand on voit que même la page très "nue" de google.com pèse pas loin du méga.
Donc non ça ne génère pas des libs énormes, par contre on se prend un overhead de traitement js immanquablement. Et même si les moteurs JS vont bien bien bien bien...bien plus vite qu'en 2000, autant se passer de surcouches si elle sont inutiles, on est bien d'accord.

Perso, je ne suis pas pro framework que je ne maîtrise pas. Je préfère le bon vieux framework maison que je fais évoluer au fur et à mesure de mes besoins. Je le trouve plus souple et plus léger.

Maintenant, je suis indépendant, c'est donc plus facile pour moi. C'est sûr que si je devais travailler dans une boîte dans laquelle ils utilisent jQuery et consors, je serrais obligé de m'adapter.

jQuery a inspiré les standards de demain, qui sont devenus les standards d'aujourd'hui. S'il vient à réduire en taille puis à disparaître, ce sera donc plutôt une bonne nouvelle, ça voudra dire qu'on a tout ce qu'il faut en vanilla.

sélecteur sizzle => querySelector
animate => animations/transitions CSS
ajax => fetch
Deferred => Promise

Mais il a encore quelques atouts en main comme les événements délégués ou les calculs de dimensionnement/offset.

jQuery a encore quelques beaux jours devant lui. Il assure mieux que quiconque la compatibilité entre navigateurs et permet d'avoir un peu de haut niveau là où on n'en a pas tellement.

Mais cela ne durera pas éternellement. Le jour où il n'y aura plus que du Webkit / Blink avec V8 pour exécuter le JS se rapproche de plus en plus. Ce jour là les problèmes de compatibilités seront fortement réduits, au point sans doute de devoir se passer de garants de compatibilité comme jQuery.

jQuery’s Relevancy – There and Back Again

Personnellement , je ne vois pas pourquoi j'aurai besoin d'utiliser un framework client MVC comme AngularJS ou Backbone.

Dans mon travail, j'utilise déjà un framework MVC serveur(symfony2):
1- Je crée le modèle avec Doctrine , le controlleur avec PHP , et la vue avec TWIG
2- Ensuite dans ma vue , j'affiche juste les données.
3- Et après j'utilise ensuite JQuery ou javascript pur pour placer les données issues du controlleur symfony à gauche ou à droite de ma page TWIG. Et tous çà de façon sécurisée car le contrôle se fait sur le serveur(php) et non pas javascript(client).

Donc , je ne vois pas pourquoi devrais-je m'embêter à utiliser le model-vue-controlleur d'AngularJS pour juste afficher les données dans ma vue TWIG qui sont déjà récupérées et bien controllées depuis le back de l'appli , parce qu'à force de croire à votre philosophie absurde , je dois m'efforcer de refaire le travail 2 fois:
- d'abord, un model-controlleur-vue depuis mon symfony2 qui est déjà assez sécurisée et bien fait
- et ensuite un model-controlleur-vue depuis angularJS qui n'est pas assez sécurisée(car côté client) et qui ne sert finalement pas à grand chose

Pour moi, ces frameworks soient disant en vogue(AngularJS, Backbone, etc) ne sont juste que de la pure publicité de leurs créateurs et qu'ils ont été créés juste pour voler vos données.

A moins de ne travailler exclusivement que sur du SPA, je ne vois pas pourquoi on devrait s'embêter à refaire une deuxième fois dans le front un travail déjà fait et mieux fait depuis le back