Discussion :

[Invité]

Je veux dire que les paradigmes de programmation ne sont pas homogènes. et que l'ergonomie ne l'est pas toujours.

Voici les trois paradigmes de JavaScript :

- C'est un langage orienté prototype
- C'est un langage impératif
- C'est un langage fonctionnel

Dire que deux de ces paradigmes ne sont pas homogènes entre eux n'a aucun sens.
Quand à dire que JQuery brise ou modifie l'homogénéité d'un des ces paradigme par rapport à un autre, ça n'a pas beaucoup plus de sens.
Quand j'ai utilisé ce terme, je voulais dire que votre conception du développement (votre vision du développement - votre paradigme), qui semble être, «*à chaque problème prenons le temps de choisir la solution la plus adaptée*», n'a pas de réalité économique. Elle est peut être très jolie telle qu'énoncée, mais dans la pratique, très peu de sociétés vont perdre ce temps. Généralement, ce sont des sociétés qui ont un département R&D qui se permettent ce luxe. Entre autre, parce qu'il faut au moins avoir une personne connaissant chacune de ces technologies, et d'autre part, parce que développer un prototype avec chaque librairie, pour ensuite comparer les résultats, demande du temps et coûte de l'argent. Sans même parler d'avoir ou pas en interne les ressources formées aux technologies visées.
Quant à mettre en rapport «*l'homogénéité des paradigmes*» d'un langage et l'ergonomie d'une application, je nage en plein surréalisme. Je ne vois pas en quoi l'un influe sur l'autre.
Je veux bien discuter, mais ne faites pas des phrases qui n'ont aucun sens.

Whaoo je ne sais pas où j'ai pu suggérer une telle chose. je dis simplement que le développeur quelqu'il soit doit se cultiver et avoir un peu de connaissance de ce qui existe. et non pas se tourner systématiquement vers ce qu'il connait.

Le développeur va se tourner vers les technologies qu'il connaît, tout simplement par se que son patron ne va pas lui accorder de jours de travail pour se former à une autre technologie, sauf si elle est imposée par le client. Si votre réponse c'est de me dire, «*le développeur n'a qu'à passer son temps libre pour se former à ce qu'il ne connaît pas*», vous oubliez sûrement que la vie de famille ne permet pas non plus ce luxe, ou que les loisirs ne consistent pas, pour tout le monde, à compulser des documents techniques. Et comment voulez-vous que les développeurs connaissent l'ensemble des librairies/frameworks JavaScript*? Rien que sur cette page, il y en a autant que de lettres dans l'alphabet : http://en.wikipedia.org/wiki/Compari...ipt_frameworks.

Je ne pense pas avoir mal lu je ne suis pas d'accord c'est tout. je pense que le monde ne fonctionne pas comme ça. JQuery à des qualité dans l'enrichissement de site web. et cela corresponds à un usage. ce ni le seul usage, ni la seule solution à celui-ci. je pense donc que comme toujours d'autres usage, d'autre façon de travailler arriverons sur le devant de la scène.Il n'est donc pas question de remplacer JQuery dans mon propos.

Vous pensez que le monde fonctionne comme vous. Et dans un sens, je vous rejoins, si tous les développeurs avaient le temps de faire de la veille technologique, voire de s'autoformer aux nouvelles technologies qui pointent au coin du web, alors, dans ce monde merveilleux, on ferait plein d'applications, bien fabriquées, qui auraient pu être réfléchies, testées, éprouvées, et même voire sans erreurs. Mais la réalité, c'est que très peu de gens dans l'industrie logicielle peuvent avoir ce luxe. Demander que tous les développeurs connaissent tout même de la technologie principale qu'ils utilisent au quotidien, c'est irréaliste.

Là encore cela montre bien ce que je dis JQuery est une techno qui est particulièrement bien adapté à recherché des éléments dans un DOM. du coup on ne se pose pas la question de savoir pourquoi on doit chercher des éléments, alors qu'on développe soit même l'application. Pourquoi devoir chercher ce qu'on a créer.

Lorsqu'un événement est déclenché par une action utilisateur sur un bouton et que l'action qui s'en suit, par exemple, c'est imprimer «*bonjour*» dans un champ de texte, par exemple, le code qui est associé au bouton doit retrouver le champ de texte pour y imprimer «*bonjour*». Bien que ce soit vous qui ayez fabriquer le champ texte plus tôt dans l'application, vous êtes obliger de le retrouver (ou de le nommer) pour écrire le code du bouton, si vous voulez qu'il puisse écrire dedans. Et une application JavaScript, ce n'est principalement que ça. Des réactions aux interactions de l'utilisateur (des événements) qui permettent aux composants du DOM de se retrouver mutuellement et de s'échanger de l'information pour modifier leur états, visuels ou pas. Voilà à mon sens, «*Pourquoi devoir chercher ce qu'on a créer*».

Je prend cet exemple, uniquement dans le cas de ces librairies. Pour des frameworks plus évolués, où l'on peut manipuler les éléments de l'application en terme plus abstrait, on peut s'abstenir de cette tache, le champs texte serait peut être conservé en tant que propriété d'un autre objet, auquel le bouton ferait sa demande. Mais dans la réalité, les frameworks, supportant le MVC, par exemple, commencent à peine à émerger et sont anecdotiques en terme d'exploitation. Comme aujourd'hui, beaucoup d'applications sont fabriquées avec JQuery, il y a une demande forte pour cette technologie.

la réponse est simple parce qu'on utilise une techno faite pour enrichir des site Web. lorsque je crée un élément du DOM, le n'ai pas besoin de le chercher je viens de le créer je n'ai qu'à le manipuler. JQuery est plutôt très mal foutu pour produire un DOM. en fait il ne crée pas un DOM il délègue ça au moteur HTML plutôt que d'utiliser l'accès au DOM de javascript.

la réponse est simple parce qu'on utilise une techno faite pour enrichir des site Web. lorsque je crée un élément du DOM, le n'ai pas besoin de le chercher je viens de le créer je n'ai qu'à le manipuler. JQuery est plutôt très mal foutu pour produire un DOM. en fait il ne crée pas un DOM il délègue ça au moteur HTML plutôt que d'utiliser l'accès au DOM de javascript.

Heureusement que JQuery délègue une partie de la création au moteur JavaScript, sinon votre code serait truffé de

si (moteurJavaScript1) alors FaireAvecLaMethodeOuSyntaxeMoteur1
sinon si (moteurJavaScript2) alors FaireAvecLaMethodeOuSyntaxeMoteur2
sinon si (moteurJavaScript3) alors FaireAvecLaMethodeOuSyntaxeMoteur3
etc.

Ça, c'est un plat de spaghettis mal cuits, mais sans la sauce bolognaise, une mélasse.

Heureusement que JQuery nous abstrait de ce genre de problèmes, c'est une de ses fonctions.
Plus bas vous dites que vous utilisez une sorte de framework propriétaire, qui doit probablement faire la même chose que JQuery, c'est-à-dire encapsuler toutes ces spécificités dans des fonctions / méthodes, qui vous masquent ces implémentations fastidieuses. Vous reprochez à JQuery ce que votre framework fait aussi pour vous il me semble. Ce n'est pas très clair.

du coût lorsque JQuery veut créer un élément du DOM et le manipuler il file un source HTML au moteur HTML qui va l'interprété pour créer le DOM. Lorsque l'élément est créé JQuery ne sais pas ce qui à été crée il est obligé de le rechercher. en javascript pur on peut très bien crée des éléments directement JS et donc avoir des référence sur les objet pour les manipuler.

De quoi parlez-vous*? La référence à une instance de prototype JQuery peut être aussi stockée dans une variable pour être utilisé (référencé) plus tard. Vous opposez trop JavaScript «*pur*» à JQuery. Quand on fait une application avec JQuery, on fait forcément aussi du JavaScript. Qu'il soit «*pur*» ou pas, ça n'a aucune importance.

C'est une approche totalement opposé à celle de JQuery. est-elle meilleur ou pas ce n'est pas question elle existe et là JQuery est franchement pas la librairie à utiliser. pourtant il s'agit bien de DOM et de javascript. cela comfirme ce que je dis. ne voir qu'une seule librairie. sans regarder autour, c'est s'enfermer dans une solution unique.

Votre opposition JavaScript «*pur*» / librairie me rappelle une discussion d'un autre temps, à laquelle j'ai assisté, où des types s'opposaient entre application assembleur «*pur*» et C. Le côté «*pur*» semble avoir un attrait pour certains et devenir comme une balise / une norme qui offriraient les meilleures solutions. Après, on adhère ou on n'adhère pas. C'est pour l'anecdote.

Je fais des application Web. Je n'enrichie pas des site Web. lorsque dans mon application je veux un menu je préfère faire new Menu() que de mettre un div dans du HTML pour ensuite les chercher, lui appliquer des transformation à l'aide de plugins afin de lui donner l'apparence d'un menu. Je ne manipule pas des div des ul li ni des p ou span je ne manipule pas des form ou des options. je manipule des tabpanel, des layaout des accordeon, des menus, des grid, des formulaires, des arbres, des histogrammes, des camemberts, des nuages de points des courbes, des graphes , bref je manipule des objets d'IHM de haut niveau. ceux-ci sont implémenté en javascript et produise un DOM. Il n'y a pas qu'une seule façon de faire dees application Web.

Je vais revenir à la question initiale «*Peut-on se passer de JQuery*?*»
Je ne comprend pas où vous voulez en venir. Vous ne dites jamais la même chose. Au départ, vous me disiez, que pour faire une bonne application, il faut utiliser la librairie qui est le mieux adaptée aux problématiques de l'application, pour ensuite vanter les mérites de ExtJS puis de YUI, en particulier, pour enfin nous dire que vous vous semblez travailler avec un framework propriétaire.

La réponse que vous proposez à cette question, «*Peut-on se passer de JQuery*?*», c'est d'utiliser soit deux librairies qui sont utilisées de manière anecdotiques dans l'industrie logicielle, soit d'utiliser un framework, qui appartient à votre société, et qui est donc propriétaire, voire inaccessible*?

D'autre part, si on dit se passer de JQuery, alors on dit aussi que toutes les applications qui sont déjà en exploitation vont devoir migrer vers une autre solution, avant que JQuery devienne totalement obsolète. Où trouver suffisamment de développeurs pour migrer dans des solutions qui ne sont encore que trop peu utilisées aujourd'hui*?

Enfin, vous dites, qu'il ne faut pas se contenter d'une solution unique, mais vous vous semblez, vous aussi n'en utiliser qu'une seule, votre solution propriétaire.

Que vous fassiez du haut niveau, on ne peut être que content pour vous, puisqu'à ça à l'air d'être important pour vous. Par contre, si la réponse à «*Peut-on*» c'est «*Moi, je*», alors je trouve ça un peu court comme réponse. Et encore, c'est plutôt, si on vous suit bien, «*les autres doivent utiliser ExtJS et YUI, et d'autres framework à peine émergents, moi je continue avec mon framework propriétaire*».

Ma réponse c'était de dire, dans l'état actuel de l'industrie où JQuery est majoritairement utilisé, se passer de JQuery n'est pas envisageable. Maintenant, JQuery n’est pas le summum de ce qui peut se faire en terme de support de développement. D'ailleurs commencent à émerger de vrais frameworks MVC comme Angular et des environnements événementiels et server-side comme Node.js. Mais tant qu'il n'auront pas été suffisamment éprouvés, ils ne peuvent pas remplacer JQuery, et ses consoeurs, dans l'industrie. Faire migrer les applications déjà en exploitation et former une grande partie des développeurs à d'autres technologies et de nouveaux paradigmes, comme le fait que JavaScript devienne un langage serveur, prend du temps.
Peut-on se passer de JQuery*? Probablement, mais ce n'est pas pour demain. Malgré toutes ses qualités et sa richesse, il est loin d'offrir le mieux de ce qui se fait en développement moderne. Mais dans l'état actuel, il n'est pas possible de dire on va se passer de JQuery, parce qu'aucune autre alternative industrielle ne s'est suffisamment imposée pour la remplacer.

Le reste, c'est encore des histoires de 90%, voire de certitudes au niveau 5 sigma, je ne commente plus.

Je connais suffisamment JQuery pour avoir développé des plugins et de nombreuses applications avec. et je l'ai abandonnée pour des raisons d'efficacité et de rapidité de développement. cela peu vous paraitre étrange mais la principale raison de cet abandon à été le frein que représentait JQuery à un développement rapide.J'ai mi 90% car depuis 4ans je ne me souviens pas avoir utilisé une seule fois une recherche dans le DOM de mes applis. Je ne voulais pas être trop optimiste en mettant plus.Je ne vois pas ce qui vous permet de faire une telle affirmation. Je prototype très souvent est justement JQuery m'est apparu comme un frein. encore une fois. il existe bien des approches pour développer des applications et des prototypes. encore une fois il existe bien des outils pour faire cela. Je continus à affirmer que JQuery est une bonne solution mais que ce n'est pas la seule. elle excelle dans une approche, celle qui consiste à créer un site HTML et à l'enrichir avec Javascript. ce n'est pas la seule solution.

J'ai développé pour ma boite une lib bien avant que JQuery n'arrive pour palier les différences des navigateurs. lorsque JQuery a débarqué j'ai beaucoup apprécié ces qualités. et la décision de porter les éléments de notre lib sur JQuery à été pris. j'ai donc développé des plugins au tout début de JQuery. Mais les manques de JQuery, les difficultés à constituer un ensemble suffisamment riche et cohérent avec la pléthore de plugins, on fait que nous sommes allés voir ailleurs. et des ailleurs il y en a beaucoup. Nous avons trouvés des frameworks répondants à nos besoins et avons retenu plusieurs solution en fonction de ce que nous avons à faire. et je garde un oeil ouvert sur ce qui apparait et disparait. car je sais que les techno évolues et qu'un jours apparaitra probablement une techno dans la quelle cela vaudra le coup d'investir.

J'ai l'impression que je vous ébranle en affirmant qu'il existe d'autre façon de faire et que je pense que JQuery n'est pas toujours la lib la plus adaptée au besoin des applications qu'on développe.
pour donner une idée de ce qu'on peut faire sans JQuery et sans recherche dans le DOM cet article contient des captures d'écrans. et le voir en action (limité lorsqu'on est anonyme)

A+JYT

[SpaceFrog]

Poser cette question c'est un peu comme demander si on, peut se passer du rouge en peinture...
ça dépend du peintre et du sujet à peindre !
Demandez à un daltonien de vous peindre une toile de volcan sans rouge ...

En revanche je pense que Jquery a en effet pris une place trop importante par rapport a ce que devrait être sa place réelle, en grande partie à cause de la méconnaissance générale des développeurs web face à javascript.
JQuery propose en effet nombre de plugins qui favorisent la fainéantise du développeur qui a tendance à empiler les bouts de codes plutôt que de réellement rationaliser ou de chercher la performance maximale.

Je poserais plutôt la question concernant le réel besoin de la performance à tout prix. Pour plus de 95% des sites web la performance de javascript n'est pas vraiment le nerf de la guerre. gagner des pouillèmes de secondes sur le navigateur du client est il vraiment nécessaire ?
Je constate souvent l'utilisation de centrales nucléaires pour alimenter un led ... ou d'un bazooka pour tuer un moustique. A la limite c'est juste des ressources sur-utilisées coté client et ce n'est pas très dérangeant.
Ce que je trouve plus gênant, que ce soit avec JQuery ou pas d'ailleurs, c'est la multiplication des scripts externes. On voit en effet de plus en plus souvent 30 voire 40 (ou plus ...) appels réseau pour charger des librairies, des widgets, des composants. Là cela devient plus gênant au niveau de l'encombrement de la bande passante.

[Pelote2012]

Perso, avant je faisait du .net et en passant à Jquery , mes tailles de pages on fondu ... ne faisant plus que quelques kilo voir octets pour certaines ...
C'est pas lourd, c'est efficace ... en plus il y a la partie UI très intéressante pour permettre de faire des pages design sans trop se fatiguer
C'est multi OS, multi Navigateur ...
Perso si j'abandonne ... se sera pour quelques chose de mieux ... mais aujourd'hui je ne vois pas ce qui le remplacera

[Darkaurora]

Je crois qu'on est tous plus ou moins d'accord pour dire que dans l'absolut jQuery n'est pas indispensable mais il offre plus de facilité que le JS natif (lib, UI, plug...). Maintenant à vous lire on en viendrait presque a se poser la question, est il nécessaire de programmer avec des langages haut niveau...

Si on a le temps de l'optimisation maximale tout est bon à prendre et chacun trouvera sa manière de se prendre la tête pour un code qui est plus qu'efficace. Maintenant dans un contexte de projet on prend des raccourcis même si le code pondu est "dégueulasse" on a pas le choix c'est bien souvent dans l'ordre suivant que ça se passe: Fonctionnel => Ergonomique/Élégant => Performant.

A moins d'avoir une bonne & grande équipe de développeur pour un projet moyen, il faut bien se résoudre à la première contrainte de nos métiers: les délais!

[sekaijin]

...
Ma réponse c'était de dire, dans l'état actuel de l'industrie où JQuery est majoritairement utilisé, se passer de JQuery n'est pas envisageable.
...

Waoo quelle attaque en règle.
Je présentait que j'ébranlais une certitude absolue en disant simplement que JQuery n'est qu'une lib comme une autre et qu'elle ne mérite pas plus qu'une autre le titre d'incontournable. C'est bien plus profond encore.

Je suis sur à 100% qu'une autre façon de travaillier aura dans un avenir proche les faveurs des développeurs. que les petits nouveaux qui n'auront pas appris à nr ce servir que de JQuery y regarderons de plus près. et que jquery alors retrouvera une palce comme tant de technologies.

Je crois qu'il n'est nullement nécessaire d'argumenter mon propos.
Merci pour la leçon d'informatique.

...
A moins d'avoir une bonne & grande équipe de développeur pour un projet moyen, il faut bien se résoudre à la première contrainte de nos métiers: les délais!

je pense que justement pour répondre au besoin dans les delais il est bon même à minima de se posser la question du choix technologique. être concient des limites d'une techno qu'on maitrise évite de partir dans le mur. Pour moi il n'existe aucune techno qui réponde à tous les besoins. Croire que JQuery permet à coup sur de raccoucir le temps de dev est une erreur grossière. Elle le permetra dans certains cas, dans d'autre elle n'auras pas effet sur ce delais et dans dautre encore elle les allongera. Comme tout technologie.

A+JYT

[Darkaurora]

Même si le sujet dévie légèrement je ne parlais pas uniquement de jQuery mais des Libs, UI et autres... Effectivement dans chaque projet il faut se poser la question de la techno mais si tu choisis le JS je suis certains que tu gagnes des jours de dev en intégrant jQuery ou Prototype ou X ou Y. Il est très rares que l'on ne trouve pas de solutions adéquates (même a 80%) aux besoins des clients et quand bien même nous devions développer nous mêmes nos plug et autres ils seront réutilisé par la suite.

Je rejoins l'avis de certains ici en disant que ce n'est pas la bibliothèque jQuery qui est intéressante mais la communauté qui s'active autour de cette lib et la richesse des ressources à nos dispositions.

[GrandFather]

Elle le permetra dans certains cas, dans d'autre elle n'auras pas effet sur ce delais et dans dautre encore elle les allongera. Comme tout technologie.

Certes. Maintenant, tout est question de proportion, les cas dans lesquels elle les allonge ne doivent pas être les plus fréquents, si on considère que plus de 55% des sites Web utilisent jQuery. Le diagramme du dessous est tout aussi éloquent: les plus proches compétiteurs sont loin derrière.

Cela ne peut pas être un effet de mode (le hype est quand même passé depuis longtemps), ce sont donc bien les qualités intrinsèques de la librairie qui expliquent son succès, non ? Je m'explique mal que des sites comme Amazon ou Microsoft l'utilisent par conservatisme ou ignorance ; et les moyens en R&D pour définir ou même créer leur propre solution optimale, ils les ont largement...

[LSMetag]

Certes. Maintenant, tout est question de proportion, les cas dans lesquels elle les allonge ne doivent pas être les plus fréquents, si on considère que plus de 55% des sites Web utilisent jQuery. Le diagramme du dessous est tout aussi éloquent: les plus proches compétiteurs sont loin derrière.

Cela ne peut pas être un effet de mode (le hype est quand même passé depuis longtemps), ce sont donc bien les qualités intrinsèques de la librairie qui expliquent son succès, non ? Je m'explique mal que des sites comme Amazon ou Microsoft l'utilisent par conservatisme ou ignorance ; et les moyens en R&D pour définir ou même créer leur propre solution optimale, ils les ont largement...

Pour moi c'est simple. JQuery est principalement plébiscité car justement dans le monde du travail on a décidé que la priorité n°1, c'était de raccourcir les délais, pour réduire les coûts et surtout remporter des appels d'offre (SS2I et cie). JQuery a beaucoup de qualités, notamment celle du gain de productivité, de facilité de relecture du code, de la communauté et de sa croissance justement qui fait qu'il y a plus de main d’œuvre qualifiée dans ce framework. Ca ne veut pas dire pour autant que c'est la technologie qui répondra le mieux au besoin dans les faits. C'est d'abord celle qui permet de remporter l'appel d'offre...

Après je suis d'accord pour dire que dans la plupart des cas, utiliser du JS natif augmentera de façon importante le temps de développement, sans pour autant apporter en qualité vu le manque de qualification dans le domaine. Donc l'utilisation d'une lib ou d'un framework est quasiment incontournable, sauf pour les petites choses. Mais il y a tout un tas d'alternatives à JQuery, et c'est là qu'il devrait y avoir matière à réflexion par rapport au besoin. Mais c'est le commercial qui va l'emporter, pas la qualité de la réponse au besoin. Sauf chez les éditeurs, startups ou quelques clients plus consciencieux.

[LSMetag]

Franchement je sais pas d'où tu sors ça, mais je crois que tu n'es pas loin de la paranoïa.

Et au demeurant si tu as des doutes sur la neutralité de ton FAI, rien ne t'empêche de faire le tien, ou de rejoindre des FAI qui font effectivement le choix d'un internet neutre et propre... mais c'est un autre sujet de toute façon.

Ceci étant, je veux bien que tu m'expliques plus clairement techniquement comment c'est plus qu'un "bête lien de téléchargement.". Parce que à part accuser ton FAI de faciliter le tracking en prétendant que tes requêtes vont être enrichies d'un contenu dont on ne connait pas la teneur mais utile aux services secrets, je ne vois pas l'ombre d'une explication.

En plus je comprends pas bien ton point de vue : tu te mets du coté du développeur, de l'architecte de l'appli ? ou bien du coté de l'utilisateur ?
Si tu te mets du coté de l'utilisateur tu as peu à craindre de ces CDN, le tracking se fait autrement : google-analytics par exemple, cookies, insertions d'images...
Tu peux requêter ces fichiers sur CDN sans cookies, en refusant les cookies du CDN, et ils sont marqués pour être cachés par ton navigateur, donc tu le charges une fois, point. Il y a plus pratique pour du tracking, ou alors ils sont balèzes.

Si tu te mets du coté du dev en souhaitant protéger tes utilisateurs, on a à peu près la même logique, sauif qu'effectivement la requête portera peut-être un http_referer en entête, ce qui peut indiquer que ton site/appli utilise jquery... comme 70-80% du web non ?

Et puis le surf anonyme à base de VPN, bien sur... peut être que ça te sauvait les miches pour Hadopi avec emule et bittorrent, mais là on est dans une autre dimension.


Très clair je trouve

Oui je sais que je suis pas loin de la paranoïa. Mais malheureusement je me base sur des faits. Le fait que les services secrets américains ont des partenariat avec nos opérateurs téléphoniques a été prouvé avec les documents de Snowden. Pour les FAI, je ne serais pas surpris que ce soit la même chose. Je suis dans une logique de protection des utilisateurs. Et pour ce faire j'essaie de garder une certaine indépendance et de faire en sorte de ne connaître aucune information d'eux (cryptage en amont, avant d'atteindre les serveurs) sauf l'adresse mail (et si on peut espionner leurs mails, c'est le problème de la boîte qui gère leurs mails, pas le miens). Comme ça, si on me demande de communiquer sur eux, je ne pourrai pas et ne serai pas considéré comme "hors la loi".

Ce n'est pas parce que 70-80% du web est comme ça que j'ai envie de m'y conformer. C'est juste une question de principe. Mes convictions me disent de ne pas soutenir des gens censés faire respecter la loi, mais ne la respectant pas eux même. Google Analytics et consorts, je bloque tout ça. Je n'utilise d'ailleurs pas Google mais Ixquick comme moteur de recherche. Pareil niveau mails, je n'utilise pas quelque chose de public. Pour la synchronisation Firefox, on peut d'ailleurs mettre son propre serveur. Autant que possible, j'essaie de vider mes en-têtes HTTP (ou au pire de les falsifier).

Alors oui, je fais peu confiance. Quand je vois qu'Hollande a recadré ses ministres quand ils dénonçaient l'espionnage de la NSA (source : Canard Enchaîné) car il ne voulait pas se mettre les puissants USA à dos et qu'il a ensuite fait intercepter l'avion d'un chef d'Etat étranger pour livrer Snowden... Donc oui, on est dans un monde où le pouvoir est tout et où on s'assoie sur ses convictions, même quand un Etat bafoue les lois internationales (et ses propres lois).

[sekaijin]

Serait-on en train d'essayer de me convaincre de ce que je répète depuis le début ?
JQuery est une bonne librairie.

à mon avis
JQuery est indispensable ? NON
répondre non à cette question implique-t-il que Jquery soit un mauvais choix ? NON
JQuery reste-t-elle une bonne librairie bien qu'elle ne soit pas indispenssable ? OUI
Existe-t-il des alternative ? OUI
L'exitance d'alternative font-elles de JQuery une mauvaise librairie ? NON
JQuery reste-t-elle une bonne librairie bien qu'il y ait des alternatives ? OUI
JQuery est-elle toujours pertinante ? NON
Le fait que JQuery ne soit pas toujours pertinante implique-t-il que Jquery soit une mauvaise librairie ? NON
JQuery reste-t-elle une bonne librairie même si elle n'est pas toujours pertinante ? OUI
Le modèle de programmation par enrichissement du DOM proposé par JQuery est-il un bon modèle : OUI
L'existante d'autre modèle de programmation d'application web font-ils de JQuery une mauvais librairie : NON
JQuery reste-elle une bonne librairie bien qu'il existe d'autre modèle de programmation web : OUI

Je n'utilise pas le modèle de programmation par enrichisement du DOM. dans ce cas JQuery est-elle Indispensable ? NON
Je n'utilise pas le modèle de programmation par enrichisement du DOM. dans ce cas Existe-t-il des alternative ? OUI
Je n'utilise pas le modèle de programmation par enrichisement du DOM. dans ce cas JQuery permet-elle un gain de productivité par raport à ces alternatives ? Parfois
Je n'utilise pas le modèle de programmation par enrichisement du DOM. dans ce cas JQuery est-elle un frien à la productivité par raport à certains de ces alternatives ? OUI
Je n'utilise pas le modèle de programmation par enrichisement du DOM. dans ce cas JQuery permet-elle un gain de performence par raport à ces alternatives ? Parfois
Je n'utilise pas le modèle de programmation par enrichisement du DOM. dans ce cas JQuery est-elle un frien à la performence par raport à certains de ces alternatives ? OUI
Je n'utilise pas le modèle de programmation par enrichisement du DOM. dans ce cas JQuery est-elle mon choix de prédilection ? NON

Le fais que dans ce cas JQuery ne me permette ni un gain de productivité ni un gain de performence, fait-il que je considère que JQuery n'est pas indispensable : OUI
Le fais que dans ce cas JQuery ne me permette ni un gain de productivité ni un gain de performence, Fait-il de JQuery une mavaise librairie : NON
JQuery reste-elle une bonne librairie bien que dans ce cas JQuery ne me permette ni un gain de productivité ni un gain de performence : OUI


Il me semble assez clair que je dis que JQuery est une bonne librairie.
si je compte les points 11 favorables à JQuery, 8 neutre, 3 défavorables

si je réponds à la question Peut-on se passer de jQuery ? Il existe au moins un cas où la réponse est OUI.
A+JYT

[Invité]

Poser cette question c'est un peu comme demander si on, peut se passer du rouge en peinture...
ça dépend du peintre et du sujet à peindre !
Demandez à un daltonien de vous peindre une toile de volcan sans rouge ...

C'est vrai. Mais ici, la base est commune, c'est le langage JavaScript, c'est un peu la couleur de la discussion.

En revanche je pense que Jquery a en effet pris une place trop importante par rapport a ce que devrait être sa place réelle, en grande partie à cause de la méconnaissance générale des développeurs web face à javascript.
JQuery propose en effet nombre de plugins qui favorisent la fainéantise du développeur qui a tendance à empiler les bouts de codes plutôt que de réellement rationaliser ou de chercher la performance maximale.

Oui, JQuery a pris trop d'importance, alors que commencent à pointer des solutions de développement bien plus avancées.
Cette méconnaissance est peut être due à l'enseignement qu'on dispense à la base. Quand on en dispense un. Je pense que l'enseignement du JavaScript se limite très souvent au langage lui même et éventuellement une ou deux librairies, probablement pas encore de solutions complètes. Et le JavaScript n'est pas, dans les enseignements informatiques, un langage prédominent, à part pour les formations plus spécialisées sur les technologies web.

Je poserais plutôt la question concernant le réel besoin de la performance à tout prix. Pour plus de 95% des sites web la performance de javascript n'est pas vraiment le nerf de la guerre. gagner des pouillèmes de secondes sur le navigateur du client est il vraiment nécessaire ?

Très souvent les principales problématiques d'un client, ce ne sont pas la réactivité du frontal, tant qu'elle reste raisonnable/acceptable/dans ses normes. Ce sont soit les possibilités d'échange avec son propre SI, soit la quantité de fonctionnalités qu'il va offrir pouvoir à ses clients soit des problématiques marketing. Voire dans d'autres cas, mais plus rares, des problématiques de back due à leur charge de connexions ou de données.

Pour citer quelques cas extrême que j'ai rencontré, un site de collectionneurs, où sont vendues des séries limitées, de manière sporadique dans l'année. Le site est utilisé de manière informative le plus souvent dans l'année, puis il connaît des pics de connexions effrayants, lorsqu'une série limitée est mise en vente. La problématique n'est clairement pas le frontal et le JavaScript et/ou Jquery dans ces situations. C'est plutôt, «*est-ce que les serveurs vont tenir la charge*?*». Des problèmes de monitoring principalement.
Dans un autre cas, la question fût «*est-ce que la base de donnée va tenir la charge*?*». Ici, ce sont la quantité de références des produits et de variantes du client, son référentiel produits, qui oblige à maintenir un index de plusieurs millions d'entrées. Oracle, même malgré l'intervention de «*spécialistes*», n'arrivait pas à tenir la charge pour de simple requêtes, dans certaines situations, comme les recherches par suggestions. La solution a été de déporter l'index et le moteur de recherche sur Lucene/Solr.

Même si ces cas restent plutôt rares, les problématiques principales d'un client ne sont que très rarement la réactivité du frontal. Et par la la qualité du JavaScript, il faut bien le reconnaitre.

Je constate souvent l'utilisation de centrales nucléaires pour alimenter un led ... ou d'un bazooka pour tuer un moustique. A la limite c'est juste des ressources sur-utilisées coté client et ce n'est pas très dérangeant.
Ce que je trouve plus gênant, que ce soit avec JQuery ou pas d'ailleurs, c'est la multiplication des scripts externes. On voit en effet de plus en plus souvent 30 voire 40 (ou plus ...) appels réseau pour charger des librairies, des widgets, des composants. Là cela devient plus gênant au niveau de l'encombrement de la bande passante.

Ce sont, peut être, les conséquences d'un soucis de conception de l'application, par manque de temps ou autre, et aussi d'un client mal conseillé. Mais la minification/compilation des CSS/JS, loué soit le Yui Compressor, et les tables de sprites nous sont parfois demandés par les clients eux mêmes lors de la conception de leur sites.

[le_chomeur]

Dommage que la discussion parte en troll avec les pro jQuery et les ayatollah du js pur ...

Comme sekaijin l'a dit et redit, jQuery EST une bonne librairie et OUI on peut s'en passer.

L'argument principal est "oui mais on a des délais !" hé bien je peux vous assurer que malgré ces délais un bon développeur JS les assurera tout autant qu'un développeur qui ne maîtrise que jQuery et certainement de manière "plus propre" et plus performante ( attention ce n'est que mon avis de simple développeur).

Bien à vous mes cher collègues développeurs ^^

[GrandFather]

Comme sekaijin l'a dit et redit, jQuery EST une bonne librairie et OUI on peut s'en passer.

Dans l'absolu, on peut se passer de tout, évidemment. L'utilisation d'une librairie, quels que soient le langage et l'objectif, est toujours subsidiaire.

Une fois qu'on a dit ça (et enfoncé une porte bien ouverte au passage), il faut aller plus loin et expliquer pourquoi concrètement on ne s'en passe pas, et quelles en sont les conséquences. C'est là que le débat peut être intéressant.

L'argument principal est "oui mais on a des délais !" hé bien je peux vous assurer que malgré ces délais un bon développeur JS les assurera tout autant qu'un développeur qui ne maîtrise que jQuery et certainement de manière "plus propre" et plus performante ( attention ce n'est que mon avis de simple développeur).

Déjà, ton exemple est biaisé, en confrontant un bon développeur JS à un développeur qui ne connaît que jQuery. Il serait plus pertinent de s'interroger sur la plus-value que peut constituer l'utilisation d'une librairie comme jQuery pour un développeur, selon qu'il est aguerri ou débutant.

Ou alors tu sous-entends que jQuery ne serait utilisé que par des développeurs connaissant peu ou mal JS, mais comme en même temps tu te plaignais des trolls j'imagine que c'est une mauvaise interprétation de ma part...

[le_chomeur]

Dans l'absolu, on peut se passer de tout, évidemment. L'utilisation d'une librairie, quels que soient le langage et l'objectif, est toujours subsidiaire.

Tout a fait daccord !

Une fois qu'on a dit ça (et enfoncé une porte bien ouverte au passage), il faut aller plus loin et expliquer pourquoi concrètement on ne s'en passe pas, et quelles en sont les conséquences. C'est là que le débat peut être intéressant.

Malheureusement comme on l'a vu malgré les nombreux arguments avancés par ceux qui pensent que l'on peut s'en passer tous ceux qui disent que non ont comme arguments, les contraintes de temps et la facilité de dev ... assez limités selon moi comme arguments ...

Déjà, ton exemple est biaisé, en confrontant un bon développeur JS à un développeur qui ne connaît que jQuery. Il serait plus pertinent de s'interroger sur la plus-value que peut constituer l'utilisation d'une librairie comme jQuery pour un développeur, selon qu'il est aguerri ou débutant.

Ou alors tu sous-entends que jQuery ne serait utilisé que par des développeurs connaissant peu ou mal JS, mais comme en même temps tu te plaignais des trolls j'imagine que c'est une mauvaise interprétation de ma part...

Comme je l'ai dis cela n'engage que moi et effectivement mon exemple n'expose que les deux catégories de développeur suscité , les bon dev js et les débutants ...

Je n'ai pas lu un seul développeur avancé js qui a dit que l'on ne pouvait pas s'en passer

[sekaijin]

...
Une fois qu'on a dit ça (et enfoncé une porte bien ouverte au passage), il faut aller plus loin et expliquer pourquoi concrètement on ne s'en passe pas, et quelles en sont les conséquences. C'est là que le débat peut être intéressant....

Malheureusement les ayatollahs de JQuery ne semble pas supporter qu'on puisse penser différemment d'eux.
Pour moi effectivement on peu s'en passer avantageusement dans bien des cas. soit au profit d'autre framework, soit d'autre librairie, voire même de js pur.
Mais il n'y a aucun absolu. Si je connais bien Une techno et que je refuse ce qu'il y a autour. Je n'aurais d'autre choix que de l'utiliser même lorsque elle est inadapté. Si j'ai une connaissance même partielle des domaine de prédilection d'autre techno, je serais à même de comprendre en quoi mon usage n'est pas adapté. Si parmi toutes la pléthore de techno je fais l'effort d'investir dans quelques une j'étends ma capacité à répondre de façon et rapide efficace à plus de domaines (délais).

alors concrètement même si ça s'améliore le plugins JQuery sont hétérogènes. certain joue à fond le jeux de la fluentAPI comme la lib elle-même d'autres optent pour un mode plus procédural d'autre encore pour du descriptif. en termes d'ergonomie aussi l'homogénéité est facile à obtenir quand on à peut de widget mais dès que le nombre augment il est difficile de fournir un ensemble cohérent.

enfin la base même de JQuery c'est fournir un sélecteur d'objet très efficace pour chercher dans le DOM et appliquer des transformations à ces éléments. A quoi cela peut-il bien me servir si mon DOM est vide.
Dans ce cas non seulement JQuery ne m'aide pas mais elle me freine par rapport à d'autre librairie.

Et je ne dis pas que les utilisateur de JQuery sont des c@n ou quoi que ce soit. je dis que quelque soit l'outil qu'on maitrise il faut faire attention car on a toujours tendance à privilégier son usage. parfois à tord.

A+JYT