Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Surtout le nombre de forum où quand tu cherches un truc en JS t'as plus de change de le trouver formé Jquery et résultat comme je n'ai pas Jquery dans le projet je n'ai pas la réponse.Envoyé par Bovino
Et pourtant... tu serais surpris du nombre de cas comme ça sur le forum où $() est uniquement utilisé comme raccourci de getElementById()...
Ca, c'est la manifestation hélas courante du syndrome du « marteau en or » : utiliser de manière indifférenciée le même outil, généralement sophistiqué, pour toutes les tâches, y compris les plus triviales. Ca n'est pas spécifique à jQuery (je crois me souvenir que le terme avait été inventé à l'origine pour J2EE).Et pourtant... tu serais surpris du nombre de cas comme ça sur le forum où $() est uniquement utilisé comme raccourci de getElementById()...
Cela dit, il y a un autre domaine dans lequel jQuery excelle, c'est la gestion des événements. Je ne suis personnellement pas prêt à abandonner la concision et l'efficacité de bind() et click() pour me fritter avec la gestion du bubble event ou les subtilités de chaque navigateur en ce domaine...
Peut on se passer de jQuery ? oui, le javascript se suffit à lui même, pas de nécessite absolut d'utiliser des lib.
La question, c'est : Pourquoi ce passer de jQuery ?
Questions un peu bête tout de même, imaginez que chaque constructeur de voiture ré-invente les alliages métallique, le moteur, les composants électroniques etc etc.. à chaque nouveau modèle. ça serai évidement une aberration, jQuery nous donne des outils utiles pour ne pas ré-inventer la roue à chaque fois, tout comme les frameworks. évidement on peux faire sans, mais alors il faut aller au bout du concept, et partir d'un langage pure à chaque projet (sans framework), et pourquoi pas écrire un langage à chaque projet puisqu'un langage informatique n'est qu'une couche supérieur. enfin bref. Question bête, réponse bête.
Ce qui pose problème avec JQuery, c'est son manque de modularité dans sa branche 1.x (c'est moins le cas avec la 2.x mais celle-ci n'est pas compatible avec IE8 et inférieur)
On est obligé d'intégrer la bibliothèque en entier, sans pouvoir retirer les parties qui ne serviront pas.
Pour reprendre ton exemple, les constructeurs automobiles ne vont pas utiliser les mêmes pièces pour fabriquer un cabriolet et un 4x4 militaire.
Le problème n'est pas que les développeurs essayent de réinventer la roue, c'est qu'ils essayent d'utiliser le set de pièces de camion 15 tonne pour tout faire, de la 4L à la navette spatiale. Alors quand ils vont construire un camion, ça marchera nickel. Par contre, leur 4L s’effondrera sous son propre poids, et leur navette spatiale risque d'avoir quelques soucis au décollage.
On parle beaucoup de performances JS natif vs librairie, mais il me semble que beaucoup dans ce fil de discussion oublient une réalité qui me paraît essentielle, la réalité économique.
Quand un client vous donne tant de temps pour fabriquer un site contenant des carrousels, des datepicker, des sélecteurs graphiques et autres gadgets clignotants, alors on n'a pas ni 1 jour ni 1 mois ni rien pour perdre du temps à fabriquer des fonctionnalités déjà développées et testées par d'autres, à moins de vouloir perdre le contrat en passant pour un type qui fonctionne à deux de tension.
Et quand on se tourne vers ces librairies, c'est justement pour ne pas perdre du temps de développement et de tests sur des modules déjà fabriqués et testés par d'autres.
Le succès d'une librairie comme JQuery tient davantage à la quantité de modules d'extensions fournies par la communauté, qu'à sa performance vis-à-vis d'un code natif.
Peut-on se passer de JQuery : Oui, si on a pas d'impératifs économique et qu'on a le temps de tout refaire from scratch, et qu'on aime bien se battre avec les spécificités de chaque navigateur. Personnellement, ce n'est pas ma tasse de thé.
Peut-on se passer de JQuery : Non, tant que les fonctionnalités demandées par un client sont déjà développées/testées par un tiers et dépendantes de JQuery.
Peut-on se passer de JQuery : Oui, quand il y aura encore mieux et plus fournies en modules d'extensions utilisables/modifiables rapidement.
Les combats de performances, c'est principalement des batailles de laboratoires.
La réalité industrielle, c'est "Fabriques moi un site le plus vite possible et le moins cher possible". -> librairies + plugins
Dernière modification par Invité ; 12/02/2014 à 15h25.
Tout à fait d'accord avec cela. Et si jQuery continue à tenir le haut du pavé, c'est qu'il remplit parfaitement ce rôle.
Tout à fait.
Ben peut être parce que Jquery n'est pas adapté ou moins qu'une autre lib ou que Jquery réinvente la roue là où d'autre l'on déjà inventé ou encore complètement inutile.
Tout dépend de ce qu'o a à faire.
moi je pose la question inverse pourquoi l'utiliser ?
si comme l'a dit @mekal c'est pour faire un pauvre $() à la place d'un document.getElementById(). pourquoi l'utiliser ?
ALors là je dis que tu t'é plenté de librairie. car JQUery n'est pas un modèle pour ce genre de situation.
YUI ou ExtJS par exemple sont beaucoup plus modulables, cohérentes, homogènes, et riches que JQuery.
A+JYT
Je suis plutôt d'accord et c'est plus ou moins ce que je dénonçais dans un précédent post. JQuery est surtout à mes yeux un outil de productivité fiable. Les entreprises l'ont bien compris et le plébiscitent donc à mort. Pour faire des caroussels rapidement et de manière fiable par exemple, JQuery est une très bonne solution. Surtout dans un gros site qui a déja une grosse architecture ou si la cible est un minimum réduite ou encore si le besoin de JS est moyen.
Le problème, c'est justement que les entreprises veulent tellement réduire les coûts, que même pour un site qu'elles voudront 100% Ajax et dont le public sera "tout le monde", la plupart ne saura pas panacher entre coût immédiat, pertinence par rapport au public visé et à la nature de la solution (si on veut du 100% Ajax pour tout le monde, il faut que ce soit ultra réactif, même pour les petites connexions) et maintenabilité (un peu de JQuery ça va, mais si le site repose presque intégralement dessus, il y aura un moment où ils se rendront compte qu'il faudra tout refondre...). De même, pour des simple getElementbyId, c'est ridicule mais les entreprises ça ne leur pose pas de problème.
Bref, je dénonce encore et toujours l'obsession de rentabilité à court terme, qui finit par coûter plus cher sur du moyen/long terme, avec en plus l'insatisfaction du client et l'inconfort des développeurs. Mais va faire comprendre ça à des commerciaux ou certains chefs de projets qui, quand tu leur signales un gros bug, te disent que ce n'est pas un bug parce que le client ne l'a pas encore signalé...
Le fond de la question est plutôt pourquoi se passer d'une librairie JS.
Si votre réponse est, "il y a des librairies qui font mieux que JQuery", ce dont je ne doute pas, alors vous proposez de remplacer une librairie par une autre et ça ne répond pas au fond du problème. (librairie ou JS natif).
Par soucis de productivité. Si j'ai une syntaxe qui me permet de trouver plus rapidement une solution, je vais l'utiliser. Je préfère perdre quelques microsecondes au traitement, que plusieurs heures/jours en développement. Parce qu'un code natif qui aura mis 3 mois à être développé vs un code synthétique qui m'aura pris 3 jours, la seconde solution convient au client et remplit mon frigo.
La principale erreur que je peux faire, c'est que le client ne soit pas satisfait. Depuis que je livre des sites dont les fonctionnalités sont basées sur JQuery, je n'ai jamais eu de retour du genre "Faudrait utiliser la librairie machin". Vous vous trompez de paradigme.
je ne dis pas qu'il y a mieux que ...
je dis que suivant ce qu'on a à faire JQuery n'est pas toujours le plus adapté.
et je maintient mon propos je trouve que JQuery est plutôt une bonne lib.
pour ce qui est de widget genre calendrier et autres
le principal reproche que je fais à JQuey c'est le manque d'homogénéité. ce qui est logique vu que ça ne fait pas partie de la lib. mais de plugin. et donc lorsqu'on doit rapidement présenter ce type de composants mieux vaut avoir fait un tour de ce qui existe car dans ce cas précis il y a des outil qui ont été pensés dès le départ pour ça.
la principale difficulté dans tout ça c'est que s'investir dans une lib ou un framework c'est déjà du boulot et en voir plusieurs est coûteux.
je comprends donc qu'on choisisse de rester sur une techno qu'on connait.
ce que je ne comprends pas c'est qu'alors vu qu'on se sens capable de tous faire avec ou presque on la croit indispensable.
Comme je le disais plus haut dans 90% des cas je n'ai aucune recherche à faire dans le DOM JQuery qui à été conçu dans ce but me parait pas le meilleurs des candidats.
quant au curseur code long à produire perf max face à code court à produire perf carde je n'i crois pas beaucoup. le monde est beaucoup trop nuancé pour s'arrêter à une telle caricature.
quoi qu'il arrive même si on voit ça comme un curseur il est quelque part entre les deux.
A+JYT
mine de rien quand on cree un site avec utilisation de jquery et ses plugin pour moi c'est de l'intregration et quand on utilise un plugin je croit pas que l'on s'occupe beaucoup de savoir comment il a ete codé il aurait pu etre codé en javascript pur dailleur beaucoup de plugins jquery etaient a la base codé en javascript pur ou voir d'autres librairies puis porté vers jquery car a la mode. Ce qui est dommage c'est que on parle peut de ceux qui cree ces programmes et qui souvent le mettent en libre sans rien demander a part un don dalleur je me demande si beaucoup font des dons ou préfère profiter de ce que les autre on codé gratuitement.
Sauf que je vois rarement ExtJS sur les CV et jamais vu YUI, donc les développeurs ne connaissent que jQuery.
S'investir dans une nouvelle techno sans intérêt pour la boite où on bosse c'est pas rentable ( à court terme ) donc il vaut mieux se tourner vers les pluggins jQuery.
Ceci n'a rien à voir avec la qualité des libs mais plus avec les exigences ( souvent à cout terme ) et les ressources humaines disponibles.
Il semble bien compliquer de sortir de cette logique sauf à aller travailler dans une boite prête à payer ExtJS ($2,885.00) ou à utiliser Dart.
Qui va regarder le code de PHP ( à part pour le Zend ou il fallait bien aller lire le code vu la qualité de la doc ), JAVA ... on fait avec et si les perfs sont raisonnables pas de raisons d'aller voir ailleurs.
Dernière modification par Invité ; 14/02/2014 à 12h53.
Petite intervention concernant les performances.
Comme certains d'entre vous l'ont dit, il y a la question du poids et de la vitesse... mais cela ne s'arrête pas là!
En effet, on est à l'époque de la mobilité, ce qui implique des connexions plus lentes, voire intermittentes, mais aussi une question énergétique.
Pour l'avoir expérimenté, il y a quelques années, un code lourd, en JS, peut très vite siphonner votre batterie.
Ajouter des bibliothèques ne fait qu'alourdir votre processus et est donc plus gourmand.
Les CDN? parlons-en... ok, cela allège la partie téléchargement mais pas l'exécution. De plus, ces services ne sont pas réellement gratuits, ils servent principalement à tracker des utilisateurs passant sur votre site, là où Google (par exemple) pourrait ne pas avoir de traces de leur passage.
Un exemple concret de ce genre de travers généré par jQuery. Posté aujourd'hui :Et pourtant... tu serais surpris du nombre de cas comme ça sur le forum où $() est uniquement utilisé comme raccourci de getElementById()...
Vous l'aurez compris, le paramètre objet est un objet DOM... et l'auteur a du mal à comprendre pourquoi la syntaxe est incohérente.
Code : Sélectionner tout - Visualiser dans une fenêtre à part jQuery('#' + objet.id)
D'ailleurs, l'ensemble du code est assez symptomatique d'une des utilisations importantes de jQuery qui consiste à essayer de masquer le fait qu'on ne connait pas le langage :
Code html : Sélectionner tout - Visualiser dans une fenêtre à part <input type="text" id="idInput" onkeydown="active(this)" />Donc pour revenir à la question initiale
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
un élément de réponse de ma part serait : oui, il faut se passer de jQuery au moins en phase d'apprentissage.Peut-on se passer de jQuery
L'utilisation de jQuery ne peut être un atout que lorsque l'on maitrise les concepts fondamentaux de JavaScript et que le projet sur lequel on travaille le justifie, en ça, je rejoins absolument sekaijin.
Oui parlons en
pourrais tu détailler s'il te plait, parce que moi à la lecture des échanges HTTP aussi bien avec chromium qu'avec firefox, je vois pas bien ce qui va être tracé, mais je n'ai pas la science infuse.
http://code.jquery.com/jquery-1.11.0.min.js par exemple, c'est sur CDN.
Firefox le charge une fois, c'est tout. Tu peux refaire entrée dans la barre d'adresse, il n'adresse plus de requête. Le fichier est donné en cache pour 10 ans par firefox.
Chromium refait une requête, reçoit HTTP 304. Je ne vois pas de champ indicateur de tracking dans les entêtes HTTP, alors ...?
Le CDN n'est ni plus ni moins qu'une passerelle entre nos FAI et les entreprises en question. Notre FAI va nous renvoyer vers un mirroir, choisi notamment par rapport à notre position géographique. Mais ce FAI, on ne sait pas ce qu'il envoie d'autre sur les serveurs de ces entreprises. Un CDN ce n'est pas un bête lien de téléchargement. Après, c'est la que nos copains des services secrets peuvent piocher si besoin pour savoir si on va visité tel site web.
Après, est-ce que les développeurs sont au courant qu'en utilisant des CDN pour JQuery (ou autre), ils choisissent d'autoriser le tracking de leurs utilisateur ?
Je sais même pas si surfer anonymement (VPN et cie) et bloquer les trackers suffit pour rester anonyme avec les CDN.
Non pas que j'ai des choses à me reprocher, juste parce que j'em..... l'espionnage.
Si JQuery permettait de générer le JS avant de le mettre en ligne, pourquoi pas. On serait moins pénalisé niveau performances.
Parce que là JQuery c'est quoi ? Mais c'est un gros code Javascript qui va s'exécuter pour transformer un autre code en Javascript passe partout !!!
La démarche d'une simplification de Javascript est bonne. Mais pourquoi diable en avoir fait une surcouche qui devra être interprétée quoi qu'il arrive par les clients, en plus du code du site ? Les mecs qui utilisent un Smartphone classique en 3g (ou edge) vont pas forcément passer un bon moment car le peu de processeur et de mémoire qu'ils ont vont être gâché pour exécuter ce JQuery. Ensuite, le JS généré consommera très probablement plus de CPU/mémoire que quelque chose de plus chiadé. Résultat, non seulement le smartphone va plus ramer, mais il va aussi se décharger plus vite. Si on rajoute derrière le téléchargement CDN, le temps de se connecter au serveur et de dl le fichier (je ne parle pas de haut débit) vont encore ralentir de quelques secondes le chargement du site.
Si on veut absolument transformer un code à la volée, les entreprises peuvent le faire en investissant dans un serveur ultra costaud et épargner les machines de leurs clients. Mais évidemment, ça coûte cher aux entreprises donc commercialement c'est pas viable.
Peut-on se passer de JQuery ? Oui, indubitablement. Dois-t-on se passer de JQuery ? C'est une analyse poussée du besoin, de la cible (et des budgets (mais bon, vu qu'on cherche tout le temps à le tirer vers le bas, ça ne veut plus dire grand chose)) qui nous dira si JQuery est un bon choix ou non.
Le plus adapté à quelle fonction ?
Le JavaScript et par là, JQuery et, j'insiste, surtout ses extensions, me servent à fabriquer et à dynamiser des site web. Pour cette fonction, ils remplissent très bien leur rôles.
Tout le monde ne fabrique pas des sites avec des spécificités qui nécessitent telle ou telle librairie. Personne n'a pas besoin de connaître toutes les librairies existantes et en devenir pour pouvoir fabriquer des sites.
De plus, dans une chaîne de production, chaque métier a ses spécificités. Et pour que la chaîne fonctionne bien, il vaut mieux que tout le monde travaille avec les mêmes technologies. Tout connaître, c'est mieux, mais pour travailler, connaître une solution comme JQuery est déjà un bon atout, parce qu'elle est populaire et donc largement utilisée et demandée.
Toutes les librairies, comme les langages, ont leur spécificités et leur points forts/faibles. Mais même si elles peuvent être chacune plus adaptée à certains types de problèmes ou de contextes, elles ne sont pas irremplaçables. Bonne ou pas bonne, JQuery est surtout suffisamment populaire pour avoir une grande communauté de développeurs tiers fabriquant des extensions qui en font sa richesse.
Que voulez-vous dire par manque d'homogénéité ?
Que le code n'est pas formaté de la même manière ? Forcément, c'est fait par une communauté. Il n'y a pas d'homogénéité de code à chercher. C'est vous qui fabriquez l'homogénéité par la logique de fonctionnement que vous impulsez quand vous fabriquez une solution en assemblant des différentes briques (le core et les plugins).
Vous pensez qu'une société qui fabrique des sites web va perdre du temps à faire le tour des Grands Ducs et le cas échéant, former son équipe à une nouvelle technologie, juste parce que le les extensions calendrier et carrousel fournie par la librairie B sont plus fonctionnels que ceux de la librairie A ? Non, dans la plupart des cas, par manque de temps, l'équipe va tordre les extensions de la librairie que toute l'équipe connaît pour l'adapter au besoin.
Oui, dans une société, former des gens, c'est du temps et de l'argent. Alors vous devez faire des choix et former des gens à des technologies efficaces. L'efficacité d'une technologie comme JQuery, c'est sa simplicité et sa rapidité d'accès, pas au DOM, on s'est compris, mais aux humains. Ainsi que sa popularité et la richesse de ses extensions, qui permettent de fabriquer rapidement des solutions. Je dis rapidement, parce que fabriquer des logiciels, ça coûte cher. Je parle d'applications professionnelles, pas du site d'une coiffeuse ou du boucher du coin. Notez que je n'ai aucune animosité envers les coiffeuses ni les bouchers, mais leur fabriquer un site nécessitera moins de ressources et sera moins complexe qu'un B2C, un B2B ou un site de eProcurement (les places de marchés).
Vous avez mal lu ma première réponse où je dis que JQuery sera peut être et même sûrement remplacé, par une librairie plus populaire et fournissant une quantité aussi impressionnante d'extensions, parce que l'une des forces de JQuery, c'est la richesse de ses extensions.
Intéressant*! Je suis curieux de savoir à quoi vous sert le JavaScript dans 90% de vos développements. Pour ma part, le JavaScript me sert principalement à manipuler l'apparence et le contenu de documents web, du moins la version objet d'un document, le DOM. Et pour manipuler un DOM ou un élément du DOM, je dois y accéder. JQuery offre une syntaxe synthétique, qui permet d'accéder rapidement à tous les sous composants d'un document. Dans quel domaine travaillez-vous, ou du moins à quoi vous sert le JavaScript ?
La seule application qui me vient à l'esprit où du JavaScript servirait massivement (90% dites vous !!) à autre chose que manipuler le DOM, c'est de faire du calcul scientifique. Dans ce cas, vous devriez savoir qu'il existe des environnements et des langages plus adaptés pour ça.
Quand je lis des pages comme celles-ci :
http://w3techs.com/technologies/over...pt_library/all
http://trends.builtwith.com/javascript
http://dev.opera.com/articles/view/javascript-uses/
Je me demande vraiment à quoi vous sert le JavaScript dans 90% de vos développements.
Même des frameworks qui commencent à monter comme Bootstrap permettent l'utilisation de plugins JQuery (http://getbootstrap.com/javascript/).
Vous semblez voir la librairie JQuery limité à ses seules capacités d'accès au DOM.
Je la vois comme une base de développement rapide, le noyau, augmentée de nombreuses sous solutions, les extensions, permettant de fabriquer une solution complète, l'application finale.
Je vais mettre ce 90% sur le compte de la discussion passionnée et de la caricature comme moi avec mes 3 mois.
Pour les 3 mois, admettons, c'est caricatural. Mais vous ne semblez pas avoir entendu parler de prototypes d'applications. Ce sont des versions simplifiées d'applications permettant de démontrer à un client que votre solution satisfait la majeure partie de ses besoins.
Lorsque vous devez fabriquer, en peu de temps, pour répondre à un appel d'offres, un prototype d'application, pour démontrer à un client que votre solution répond à ses besoins, tout en faisant au mieux pour que ça coûte le moins cher possible, parce que si le contrat n'est pas obtenu, c'est juste du temps et de l'argent perdus qui finalement n'auront servis à rien. Pour cela, vous pouvez mettre en marche une série d'acteurs. Le designer qui va fabriquer les visuels et faire une découpe de ses visuels, voire faire une pré intégration HTML/CSS et JS, quand il est talentueux, le développeur back qui va utiliser la solution pour montrer au client qu'elle peut lui fournir les données dont il a besoin, et le développeur front qui va assembler les visuels et les données puis dynamiser le tout par JavaScript, pour répondre à d'autres besoins dudit client, à savoir manipuler ses propres données dans le contexte de l'application que vous lui proposez de développer complètement. Pour répondre correctement et dans les temps, vous devez utiliser des technologies communes et connues de chacun de ses acteurs. Dans lesquelles, ils pourront trouver rapidement des solutions à de nombreux sous problèmes posés par le besoin du client. Dans ce contexte, la librairie JQuery, par sa syntaxe concise permet de faire gagner du temps de développement et de ne pas s’embarrasser avec les spécificités de chaque navigateur, qui auront été déjà testées par les développeurs de JQuery. Dans ce même contexte, et aussi dans le contexte du développement de sites web sans prototypage (méthode larache : http://www.byatoo.com/la-rache/, norme ISO 1664), la librairie JQuery, par la quantité d'extensions dont elle dispose, offre la plupart du temps, tout ce qu'il faut pour fabriquer un prototype ou une solution.
Dernière modification par Invité ; 15/02/2014 à 11h41. Motif: Ajout de la norme, c'est important
Je veux dire que les paradigmes de programmation ne sont pas homogènes. et que l'ergonomie ne l'est pas toujours.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.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.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. 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. 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. 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.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 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
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
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager