JavaScript pur est-il en perte de vitesse par rapport jQuery ?

Bonjour à toutes et à tous.

j'aimerai connaitre votre assentiment au sujet de l'utilisation du JavaScript et du jQuery ?
Est- ce que votre choix se porte plus sur le jQuery, à cause des animations qui sont facile à mettre en œuvre ? Ou bien, est-ce la complexité du JavaScript qui vous rebute à l'utiliser ?

Pouvez-vous être assez explicite sur vos choix personnel ?

Peux-être que je me trompe, mais le CSS n'offre-t-il pas plus de fonctionnalités qui fait que l'on s'intéresse de moins en moins aux langages coté client ?

@+
Modifié par tournikoti (04 Nov 2013 - 10:07)

C'est pas possible que tu sortes encore des énormités pareilles. C'est franchement affolant.

a écrit :
C'est pas possible que tu sortes encore des énormités pareilles. C'est franchement affolant.

Désolé, mais +1.

Primo, javascript et CSS ne sont pas du tout en concurrence. Ils ne servent pas du tout à la même chose, et bien au contraire, ils sont plutôt complémentaires. Revois la base de la séparation des rôles.

Secundo, le titre de ton sujet et ta question principale sont un non-sens total. JQuery n'est pas un nouveau langage, c'est juste un framework javascript. Quand tu utilises JQuery, tu fais quand même toujours du javascript !

Rangez vos UZIs les gars, même si c'est très mal formulé vous avez bien saisi ce que veut dire tournikoti.

Oui, avec jQuery c'est plus simple pour le profane de faire de l'animation qu'en JS pur.
Non, ce n'est pas le seul intérêt de jQuery (ne pas se faire chier avec le cross-browser et la rétro-compatibilité est à mon avis son plus gros atout aujourd'hui).
Et oui, avec les avancées de CSS3, Javascript perd peu à peu son intérêt pour faire de l'animation.

Pour finir, et comme à chaque fois qu'on répond à cette question (c'est-à-dire environ une fois toutes les deux semaines ici) : la vérité sur "ce qui est mieux" n'existe tout simplement pas, car tout dépend du contexte projet.

tournikoti a écrit :
j'aimerai connaitre votre assentiment au sujet de l'utilisation du JavaScript et du jQuery ?

jQuery est une bibliothèque JS. On peut faire du JS sans jQuery mais l'inverse pas trop.

tournikoti a écrit :
Est- ce que votre choix se porte plus sur le jQuery, à cause des animations qui sont facile à mettre en œuvre ? Ou bien, est-ce la complexité du JavaScript qui vous rebute à l'utiliser ?

Est-ce que je préfère l'un ou suis rebuté par l'autre ? C'est réponse forcée ou bien ?

Ce qui m'a rebuté au départ, c'est IE. Le fait de devoir apprendre à tout faire de 2 manières. Me prendre la tête alors que j'avais tant d'autres choses à apprendre...
Ensuite est venu jQuery et j'ai pu d'un coup faire plein de choses utiles mais un peu lentes, surtout en connaissant bien les sélecteurs CSS.
Mais ça reste pas performant, plus lent, etc (et utilisé à tort et à travers avec des plugins bien pourris).
Avec la disparition des vieux IE (reste IE8 et ça va prendre un peu de temps avec XP mais déjà IE6 et IE7 adieu !) et l'avènement d'HTML5 dont 80% repose sur les API et donc JS, JS a un très très grand avenir.
On va faire dans le navigateur tout ce qu'on fait dans un OS. Et vice-versa. Et communiquer entre les 2, ou entre 300 navigateurs et 500 logiciels avec WebRTC.
JS côté serveur, c'est LE truc du moment. Ça remplacera pas de sitôt PHP et autres langages mais même (surtout ?) des outils utilisés "en interne" reposent entièrement sur du JS : node.js, Phantom.js + Casper.JS + PhantomCSS.
Si j'ai bien compris comment fonctionne le logiciel Prepros, c'est que du HTML/CSS/JS et c'est node-webkit qui assure la partie graphique, fonctionnelle, etc. Après compilation, ça fait 30 Mo au lieu de 4 mais bah, super outil.
Windows 8 idem : tout en HTML5/CSS3/JS si tu as envie (j'ai pas envie mais c'est pas le sujet).
Angular.JS, JS côté serveur et côté client (j'aime pas la manière dont beaucoup de dévs l'utilise mais c'est un autre sujet).

L'avantage de jQuery, c'est qu'on peut faire en 2H ce qui demande de réinventer la roue en JS. Les clients choisissent s'ils cherchent la perf à tout prix ou s'ils économisent 1 journée de travail.

tournikoti a écrit :
Peux-être que je me trompe, mais le CSS n'offre-t-il pas plus de fonctionnalités qui fait que l'on s'intéresse de moins en moins aux langages coté client ?

J'ai jamais vu autant de JS/jQuery partout. Au détriment de la dégradation un minimum gracieuse (oui canvas ne fonctionnera pas sans JS mais afficher un formulaire devrait pas dépendre d'activer JS...).
Je vois également un fort besoin de CSS qui tiennent la route, qui explosent pas à l'affichage pour un bloc en plus ou en moins.
Et des choses formidables rendues possibles grâce à CSS3 mais là c'est assez éloigné de mes activités vu les projets un peu mastodontes sur lesquels je travaille en ce moment ^^

Pousser CSS dans ses retranchements, c'est instructif mais si 30 lignes de JS avec 15 lignes de CSS plus compatibles font pareil, la 2e solution s'impose.
Seul JS permet de contrôler des éléments HTML stylés en CSS. Tout ça est hautement complémentaire.

Bonsoir à toutes et à tous.

@ jb_gfx : ce qui est surtout affolant, c'est ton intolérance !

@ QuentinC : je parle de deux choses :

1) du désintéressement de plus en plus grandissant de JavaScript au profit de jQuery.
2) du fait que le CSS offre de plus en plus de fonctionnalité qui ne nécessite plus de programmer en JavaScript ou en jQuery.

En quoi mon titre est un non sens ? Au cas où tu ne l'aurais pas compris, c'est une question !
Et je n'ai jamais dit que le jQuery était un nouveau langage. Et alors ???

@ STPo : merci pour ta réponse.

"STPo" a écrit :
la vérité sur "ce qui est mieux" n'existe tout simplement pas, car tout dépend du contexte projet.

Justement, ne crois-tu pas que le contexte dont tu parles, est de simplifier l'approche de l'utilisateur en offrant plus de fonctionnalité en CSS ?
Reste que tout ne se fait pas en CSS et que le jQuery répond bien à ces manques.

@ Felipe : tu es très prolixe sur le sujet. En tout cas merci pour ta réponse.

"Felipe" a écrit :
L'avantage de jQuery, c'est qu'on peut faire en 2H ce qui demande de réinventer la roue en JS. Les clients choisissent s'ils cherchent la perf à tout prix ou s'ils économisent 1 journée de travail.

Voilà le type de réponse que j'attendais ! Le choix du jQuery est une question de délai dans les développements. Autrement dit "time is money".
A bien te comprendre, tout va se résumer à un jeu de construction, du genre copier/coller.
Si cette façon de travailler devient accessible à tout le monde, ce métier risque de disparaitre, non ?
A moins que le véritable métier est celui du graphiste !

@+

STPo a écrit :
Rangez vos UZIs les gars, même si c'est très mal formulé vous avez bien saisi ce que veut dire tournikoti.

Pas de Uzi, juste un bol plein à ras bord. Tournikoti c'est Artemus24 qui trolle ce genre de non-sens depuis des années sur tous les forums qui ont le malheur de croiser son navigateur. Il a sorti exactement le même genre d'inepties il y a un an sous son autre pseudo. A force ça lasse.

Cherche son pseudo (Artemus24) sur Google et tu verras que son seul intérêt c'est de sortir des énormités sur tous les forums qui traitent de programmation (quand c'est pas des forums de poker).

Je rappelle que le mec est censé avoir une formation d'ingénieur en informatique et fait semblant (j’espère) de ne pas faire la différence entre un langage et un simple bibliothèque écrite dans ce même langage.

Et quand je lis ce genre de merde (je cherchais un mot qui sente bon mais ça sent vraiment la merde) :

tournikoti a écrit :

Voilà le type de réponse que j'attendais ! Le choix du jQuery est une question de délai dans les développements. Autrement dit "time is money".
A bien te comprendre, tout va se résumer à un jeu de construction, du genre copier/coller.
Si cette façon de travailler devient accessible à tout le monde, ce métier risque de disparaitre, non ?
A moins que le véritable métier est celui du graphiste !

J'ai juste envie de prendre rendez-vous avec un chirurgien pour une ablation des glandes olfactives tellement ça shlingue.
Modifié par jb_gfx (04 Nov 2013 - 01:29)

Salut,

tournikoti a écrit :
En quoi mon titre est un non sens ? Au cas où tu ne l'aurais pas compris, c'est une question !
Et je n'ai jamais dit que le jQuery était un nouveau langage.

Si tu avais précisé JavaScript « pur » (ou « natif »), tu n'aurais pas attiré autant les foudres de jb_gfx. Autrement dit, c'est un tel manque de précision dans la formulation de ta question qui en fait un non-sens, puisque jQuery, c'est du JavaScript.

tournikoti a écrit :
Si cette façon de travailler devient accessible à tout le monde, ce métier risque de disparaitre, non ?
A moins que le véritable métier est celui du graphiste !

Si c'était vraiment accessible au commun des mortels ou si ce n'était pas un véritable métier, les intégrateurs comme STPo, Felipe et moi auraient changé de métier depuis longtemps.

a écrit :
Si tu avais précisé JavaScript « pur » (ou « natif »), tu n'aurais pas attiré autant les foudres de jb_gfx. Autrement dit, c'est un tel manque de précision dans la formulation de ta question qui en fait un non-sens, puisque jQuery, c'est du JavaScript.

Voilà.

a écrit :
A bien te comprendre, tout va se résumer à un jeu de construction, du genre copier/coller.

Le copier-coller est l'ennemi n°1 du programmeur; surtout quand on pompe sans comprendre ce que ça fait et pourquoi on le fait.

a écrit :
Si cette façon de travailler devient accessible à tout le monde, ce métier risque de disparaitre, non ?
A moins que le véritable métier est celui du graphiste !

Je ne savais pas que les intégrateurs et les programmeurs front-end jouaient aux lego.
Oui, bon, encore que, avec certains CMS usines à gaz, c'est sûrement possible...



J'ai malheureusement l'impression qu'on veut mettre du javascript, de l'AJAX et du JQuery partout alors que dans 99% des cas ça ne se justifie pas vraiment. En tant qu'utilisateur de lecteur d'écran essentiellement sur IE avec un PC pas forcément dernier cri, je sens bien la différence: il y a des sites qui sont très rapides (de moins en moins), et des sites qui rament, sans trop que je sache pourquoi. Je suis même déjà tombé sur des sites qui font tourner le CPU à 100%. Pour des animations ou des pub à la con, c'est ridicule.

Les animation en CSS3 plutôt qu'en javascript, c'est une très très bonne chose pour l'accessibilité: ça permettra à ceux qui n'en veulent pas ou qui n'en en ont strictement rin à cirer de les désactiver, tout simplement, et tout en gardant javascript activé, car quand il est bien utilisé, il permet vraiment de faire des choses intéressantes. Pour le moment, c'est juste impossible de trier les effets désirés et les effets non désirés puisque tout est en javascript. IL faut penser aux malvoyants pour qui ça peut être très gênant, aux épileptiques pour qui c'est carrément une question de survie...

Je crois malheureusement qu'on est de retour en l'an 2000 en ce qui concerne le javascript: on l'utilise pour tout et n'importe quoi.

Keep it simple and stupid, qu'ils disaient !

*** A suivre
Modifié par QuentinC (04 Nov 2013 - 11:25)

Bonjour !

Afin de satisfaire la demande, j'ai corrigé le titre de mon sujet, en ajoutant "PUR" pour qualifier le javascript.

"QuentinC" a écrit :
Le copier-coller est l'ennemi n°1 du programmeur; surtout quand on pompe sans comprendre ce que ça fait et pourquoi on le fait.

N'est-ce pas une pratique courante pour gagner du temps ?
Vous n'allez pas me faire croire, que cela ne vous arrive jamais de "pomper" un code, même si c'est le votre, et de l'intégrer dans un nouveau développement, uniquement pour gagner du temps.
Et du coup, vous avez des parties qui ne servent à rien et que vous laissez en l'état.

"QuentinC" a écrit :
Je ne savais pas que les intégrateurs et les programmeurs front-end jouaient aux lego. Oui, bon, encore que, avec certains CMS usines à gaz, c'est sûrement possible...

Si vous ne jouez pas au lego, alors vous faites constamment du sûr mesure ! Et cette pratique n'est pas très performante en terme de délai.

"QuentinC" a écrit :
J'ai malheureusement l'impression qu'on veut mettre du javascript, de l'AJAX et du JQuery partout alors que dans 99% des cas ça ne se justifie pas vraiment.

Donc tu suggères que tout peut se faire en HTML et en CSS dans 99% des cas ?
Si je prends le cas de l'Ajax, il a bien une raison d'être dans les échanges entre le client et le serveur. Tu ne vas pas me faire croire que dans 99% des cas, il ne sert à rien ?

"QuentinC" a écrit :
Les animation en CSS3 plutôt qu'en javascript, c'est une très très bonne chose pour l'accessibilité: ça permettra à ceux qui n'en veulent pas ou qui n'en en ont strictement rien à cirer de les désactiver, tout simplement, et tout en gardant javascript activé, car quand il est bien utilisé, il permet vraiment de faire des choses intéressantes.

Je n'ai pas bien compris ce que tu essaye de dire. On désactive quoi et comment ?
Si c'est du CSS, je ne vois pas comment. Pour le JavaScript, et sous firefox, il faut bidouiller dans about:config alors qu'avant la version 23, c'était dans Outils / Options / Contenu.

"QuentinC" a écrit :
Pour le moment, c'est juste impossible de trier les effets désirés et les effets non désirés puisque tout est en javascript. IL faut penser aux malvoyants pour qui ça peut être très gênant, aux épileptiques pour qui c'est carrément une question de survie...

Qu'est-ce que tu entends par JavaScript ? Je croyais que l'on parlait des animations en CSS3.

"QuentinC" a écrit :
Je crois malheureusement qu'on est de retour en l'an 2000 en ce qui concerne le javascript: on l'utilise pour tout et n'importe quoi.

Là encore, je ne comprends pas la comparaison avec cette période. N'est-ce pas un préjugé que tu formules ainsi ?
A ma connaissance, dans cette période, on faisait beaucoup de HTML avec du CSS intégré au HTML (pas d'externalisation du CSS) et rarement du JavaScript car souvent trop compliqué à mettre en œuvre ou mal connu.

@ tous : à bien comprendre, le JavaScript PURE est délaissé, tandis que le jQuery est utilisé à tort et à travers, pour des animations qui n'ont souvent pas lieu d'être.
Est-ce que cela vient de la prolifération des utilitaires qui vont simplifier l'utilisateur final ?
Il y en a des tas sur le net, dont la qualité est très variable d'un site à l'autre.

Vous préférez faire des animations en HTML et CSS3, plutôt que de les faire en jQuery, pour l'accessibilité.

Que les sites sont trop surchargés pour des effets esthétiques, et que l'on ne privilégie pas assez la disponibilité de l'information utile pour les malvoyants et autres personnes ayant des difficultés à maitriser les claviers et la souris.

Que les délais de conception des sites étant courts, vous préférez reprendre des existants plutôt que de faire du sûr mesure.

Voilà, on avance dans le thème du sujet.

QuentinC a écrit :
J'ai malheureusement l'impression qu'on veut mettre du javascript, de l'AJAX et du JQuery partout alors que dans 99% des cas ça ne se justifie pas vraiment.

Ce n'est pas parce que toi tu trouves ça non-justifié que ça l'est pour tout le monde...
La cible, tout ça, tout ça...

QuentinC a écrit :
Pour le moment, c'est juste impossible de trier les effets désirés et les effets non désirés puisque tout est en javascript.

De moins en moins, en fait. Merci CSS3.

QuentinC a écrit :
Je crois malheureusement qu'on est de retour en l'an 2000 en ce qui concerne le javascript: on l'utilise pour tout et n'importe quoi.

Pas du tout d'accord. C'est même tout l'inverse à mon sens (cf. CSS3 ci-dessus).

QuentinC a écrit :
Keep it simple and stupid, qu'ils disaient !

Oui, sauf que la vraie citation c'est "Keep it Simple, Stupid", ce qui ne veut pas tout à fait dire la même chose...

Pour un projet qui nécessite pas mal de javascript pour ses fonctionnalités, si tu veux te passer d'un framework comme jquery, tu vas vite te rendre compte que tu passes ton temps à écrire des fonctions qui auront pour seul but "l'abstraction" du navigateur, c'est à dire écrire du code tel que : if IE8 ... bla bla bla... if Opera... bla bla bla...
C'est en partie ce que propose jquery. Et il le fait mieux que toi Et en cadeau avec les quelques kilobits qu'il te fait gagner avec son code mieu optimisé que le tien, il t'offre toute une ribanbelle de fonctions utiles, elle est pas belle la vie ?

C'est pour ça que tout développeur web qui exerce depuis pas mal d'années, te dira que ce genre de librairie c'est du pain bénit...

a écrit :
Vous n'allez pas me faire croire, que cela ne vous arrive jamais de "pomper" un code, même si c'est le votre, et de l'intégrer dans un nouveau développement, uniquement pour gagner du temps.

Si, bien sûr ! Mais pas sans comprendre ce que ça fait, pourquoi, et comment.

Le problème c'est qu'il est tellement facile d'ajouter un plugin pour ci, un plugin pour ça, et encore un autre, et un autre, qu'on finit par se retrouver avec plus de trucs inutiles qi pourrissent les performances que de trucs vraiment utiles.

a écrit :
Donc tu suggères que tout peut se faire en HTML et en CSS dans 99% des cas ?

Non, j'ai jamais dit ça.

a écrit :
Si je prends le cas de l'Ajax, il a bien une raison d'être dans les échanges entre le client et le serveur. Tu ne vas pas me faire croire que dans 99% des cas, il ne sert à rien ?

Bah, si; enfin, des fois; ça dépend pour quoi. Par exemple, je n'arrive toujours pas à comprendre quel intérêt il y a à refaire tout son site pour que la navigation soit entièrement en AJAX alors que ça marche très bien avec des liens classiques et que c'est de toute façon requis au cas où. La différence en volume de communication est négligeable vu que l'essentiel de ce qui prend de la place (les images) est en principe intellligemment mis en cache par le navigateur.

Par contre pour valider et envoyer des données, pour faire un petit like, pour un chat ou pour une application vraiment dynamique, là, bien sûr que c'est indispensable.

En fait je défends le point de vue que c'est utile, mais à petites doses, pour des petits changement discrets ou pour des applications vraiment dynamiques comme un chat. Pas pour changer les 3/4 de la page comme certains sites ont tendance à le faire.

a écrit :
Je n'ai pas bien compris ce que tu essaye de dire. On désactive quoi et comment ?
Si c'est du CSS, je ne vois pas comment. Pour le JavaScript, et sous firefox, il faut bidouiller dans about:config alors qu'avant la version 23, c'était dans Outils / Options / Contenu.

Je parlais de désactiver les animations CSS3. On ne peut pas encore le faire (ou alors montrez-moi comment, je serais ravi de le savoir) parce que CSS3 est relativement nouveau. Mais c'est une option qui, à terme, devra être proposée si elle ne l'est pas encore.

a écrit :
Qu'est-ce que tu entends par JavaScript ? Je croyais que l'on parlait des animations en CSS3.

Les deux. Ca sera toujours plus facile de désactiver telle ou telle famille de propriétés CSS que de désactiver certaines fonctionnalités de javascript sans le désactiver complètement. Simplement parce qu'en CSS, il n'y a pas 36 façons d'obtenir quelque chose de précis. En javascript par contre, c'est pas compliqué de faire 10000 variantes d'un code qui fait exactement la même chose et d'en trouver juste une qui arrive à contourner les blocages.

a écrit :
De moins en moins, en fait. Merci CSS3.

JE disais « maintenant » parce que cSS3 ne s'est pas encore imposé partout je pense, mais à terme, oui, complètement. Ca va décharger javascript d'une de ses fonctions phares et c'est très bien, ça sera plus facile d'écarter ce qui peut déranger.

a écrit :
tu vas vite te rendre compte que tu passes ton temps à écrire des fonctions qui auront pour seul but "l'abstraction" du navigateur, c'est à dire écrire du code tel que : if IE8 ... bla bla bla... if Opera... bla bla bla...

J'ai une question par rapport à ça. Est-ce que ce genre de code différencié par navigateur n'est pas surtout nécessaire uniquement parce qu'on aurait tendance à « faire du CSS en javascript » ?

Par faire du CSS en javascript, j'entends par là un code dont le principal but est de modifier des propriétés CSS: des lignes de montruc.style.bidule =machin et des calculs de positionnement, alors qu'on devrait plutôt se contenter d'ajouter/supprimer des classes et rien d'autre, et donc au final de limiter le code différencié à CSS seulement (où c'est évidemment et malheureusement toujours nécessaire).

CSS3 va fortement contribuer à faire cette séparation à mon avis importante, c'est certain; parce qu'à terme, javascript ne devrait plus être utilisé pour faire des animations mais juste pour indiquer à quel moment les lancer.

Je pose cette question parce que je me rends compte que pour mon projet personnel phare, j'ai réussi à pondre un code javascript de 30-40 Ko sans JQuery que je n'ai pas eu trop de mal à faire fonctionner à la fois sur IE8+, firefox et safari. Le seul code différencié important existe parce qu'IE8 ne comprend pas <audio>. La particularité de ce code est ne pas contenir une seule instruction de changement de style à part display pour ne se limiter qu'à des changements de classes. Certes, j'ai absolument aucune nécessité de design avec le public que je vise prioritairement, mais quand même.
Modifié par QuentinC (04 Nov 2013 - 22:54)

Bonsoir.

@ Yvan L. : tu te méprends à mon sujet en ce qui concerne le jQuery. Je n'ai jamais dit que ce langage n'était pas utile pour les développeurs web ! Mais je constate qu'il est surtout utilisé pour créer des animations et autres trucs forts inutiles en ce qui concerne l'accessibilité d'un site. Inversement, il est facile d'utilisation et permet une compatibilité entre tous les navigateurs. Sur ce dernier point, je pense que nous sommes d'accord !

J'ai un portable un peu lent, surtout depuis que je suis passé à Windows 7 pro. Et je fais aussi l'amère constatation que certains sites sont très lent au chargement. Ce que je recherche en surfant sur les sites, ce sont des informations ! Selon moi, tout ce surplus qui fait plaisir au concepteur est totalement inutile, voire handicapant pour une bonne accessibilité de ce que je recherche.

Des exemples d'une lourdeur inutile :
--> deux bibliothèques jQuery : quelle en est la raison, je ne saurais répondre à cette question.
--> une multitude de petites images pour embellir le site et qui ralentissent le chargement.
--> des fonctionnalités qui sont opérationnelles que sur certains navigateurs mais pas sur d'autres.
--> une complexité dans le code HTML et CSS pour cause d'une mauvaise maitrise de ce que l'on veut faire.

et j'en passe car la liste serait trop longue. Mais la principale constatation que je fais, c'est la prédominance de l'esthétique et des animations au détriment de la présentation des informations utiles.

Maintenant dire que le jQuery est utile est une question que je me pose !

@ QuentinC : nous sommes bien d'accord que les temps de chargements doivent être réduit à leur maximum. Une présentation minimaliste n'est pas un défaut de conception mais plus une présentation de ce qui doit être essentiel dans un site.

"QuentinC" a écrit :
Par exemple, je n'arrive toujours pas à comprendre quel intérêt il y a à refaire tout son site pour que la navigation soit entièrement en AJAX alors que ça marche très bien avec des liens classiques et que c'est de toute façon requis au cas où. La différence en volume de communication est négligeable vu que l'essentiel de ce qui prend de la place (les images) est en principe intelligemment mis en cache par le navigateur.

En quoi ajouter l'Ajax rendra le site plus performant ? C'est l'exemple même d'une complexification à outrance qui n'a de raison d'être que dans le tête du concepteur. D'où ce que je nomme l'usine à gaz !

Tout dépend de ce que tu nommes une application dynamique. Les cours de la bourse, les températures de la météo, je veux bien car la fonctionnalité est de faire un rafraichissement périodique de sa page sans intervention de l'utilisateur. C'est utile car le transfert de l'information est faible ! Inversement, je pense que c'est complètement idiot de faire par Ajax de gros transferts qui sont plus des demandes spécifiques que du rafraichissement.

"QuentinC" a écrit :
J'ai une question par rapport à ça. Est-ce que ce genre de code différencié par navigateur n'est pas surtout nécessaire uniquement parce qu'on aurait tendance à « faire du CSS en javascript » ?

La raison de faire du JavaScript, c'est de ne pas pouvoir résoudre certains problèmes avec uniquement le CSS. De plus, il y a deux types de navigateurs, l'internet explorer de Microsoft et les autres, qui complexifie cela. Afin de remédier à la compatibilité des différents navigateurs d'un part, et à la formulation plutôt longue et complexe du langage JavaScript d'autre part, les Framework ont été inventé pour simplifié cette démarche.

Mais l'amélioration du CSS, qui à la base ne sert que pour la présentation, va de plus en plus se substituer en fournissant des mini utilitaires qui rendront à terme, le langage JavaScript pur, ainsi que les Framework, inutile !

C'est la raison de mon sujet : la prédominance du CSS au détriment des Framework dans les animations et autres bidules esthétiques, mais inutiles.

@+

QuentinC a écrit :
Si, bien sûr ! Mais pas sans comprendre ce que ça fait, pourquoi, et comment.

D'ailleurs, il s'agit moins de « pomper » que de réutiliser du code.

QuentinC a écrit :
Je parlais de désactiver les animations CSS3. On ne peut pas encore le faire (ou alors montrez-moi comment, je serais ravi de le savoir) parce que CSS3 est relativement nouveau. Mais c'est une option qui, à terme, devra être proposée si elle ne l'est pas encore.

En effet, à l'heure actuelle, il est impossible de désactiver ou relancer une animation CSS 3 sans passer par du JavaScript. En revanche, il est déjà possible de limiter la durée d'une animation CSS 3, ainsi que le nombre de fois où elle est répétée, et ce uniquement en CSS 3 (voir les propriétés animation-duration et animation-iteration-count).

QuentinC a écrit :
Par faire du CSS en javascript, j'entends par là un code dont le principal but est de modifier des propriétés CSS: des lignes de montruc.style.bidule =machin et des calculs de positionnement, alors qu'on devrait plutôt se contenter d'ajouter/supprimer des classes et rien d'autre, et donc au final de limiter le code différencié à CSS seulement (où c'est évidemment et malheureusement toujours nécessaire).

Les styles en ligne, « caÿmal », comme dirait l'autre. Cela dit, pour certaines valeurs calculées dynamiquement (je pense, par exemple, au positionnement des éléments constitutifs d'un carrousel), il sera difficile de se passer de JavaScript (à moins de multiplier les classes non sémantiques générées à la volée au moyen d'un préprocesseur CSS, pour obtenir un .l-moins-1280 { left: -1280px; }, un .l-moins-1279 { left: -1279px; }, et ainsi de suite ).

tournikoti a écrit :
@ Yvan L. : tu te méprends à mon sujet en ce qui concerne le jQuery. Je n'ai jamais dit que ce langage n'était pas utile pour les développeurs web !

Encore une fois, jQuery n'est pas un langage, mais une bibliothèque JavaScript.

tournikoti a écrit :
J'ai un portable un peu lent, surtout depuis que je suis passé à Windows 7 pro. Et je fais aussi l'amère constatation que certains sites sont très lent au chargement. Ce que je recherche en surfant sur les sites, ce sont des informations ! Selon moi, tout ce surplus qui fait plaisir au concepteur est totalement inutile, voire handicapant pour une bonne accessibilité de ce que je recherche.

Il s'agit moins d'un problème d'accessibilité que de performances Web.

tournikoti a écrit :
deux bibliothèques jQuery

Il n'y a qu'une seule bibliothèque jQuery. À moins que tu n'aies voulu parler d'appel à un plug-in jQuery en plus de l'appel à la bibliothèque elle-même…

tournikoti a écrit :
une multitude de petites images pour embellir le site et qui ralentissent le chargement.

Ce point particulier des performances Web n'a pas de rapport étroit avec jQuery ou le JavaScript : tu peux très bien utiliser cette multitude de petites images par insertion de ces images en dur dans le code HTML ou en les gérant comme des images d'arrière-plan en CSS.

tournikoti a écrit :
Maintenant dire que le jQuery est utile est une question que je me pose !

Une question à laquelle Felipe et Yvan L. ont apporté des réponses pertinentes.

tournikoti a écrit :
@ QuentinC : nous sommes bien d'accord que les temps de chargements doivent être réduit à leur maximum.

Cela dit, JavaScript n'est pas le seul domaine pouvant avoir un impact sur les performances Web.

tournikoti a écrit :
De plus, il y a deux types de navigateurs, l'internet explorer de Microsoft et les autres, qui complexifie cela.

En tenant compte des toutes dernières versions d'IE, il n'y a plus de quoi être aussi catégorique que cela.

tournikoti a écrit :
Mais l'amélioration du CSS, qui à la base ne sert que pour la présentation, va de plus en plus se substituer en fournissant des mini utilitaires qui rendront à terme, le langage JavaScript pur, ainsi que les Framework, inutile !

Le JavaScript sera toujours utile, ne serait-ce que parce qu'il est le langage sur lequel reposent les API apparues en HTML 5.

tournikoti a écrit :
C'est la raison de mon sujet : la prédominance du CSS au détriment des Framework dans les animations et autres bidules esthétiques, mais inutiles.

Je croyais que ton sujet traitait de la prédominance de jQuery au détriment du JavaScript pur… Enfin, bref…

Bonjour à tous,

Comme le sujet se déplace un peu, je me permets de répondre au sujet de CSS, jQuery, des animations et autres images "décoratives" qui plomberaient la lecture de l'information sur le web

tournikoti a écrit :
Ce que je recherche en surfant sur les sites, ce sont des informations ! Selon moi, tout ce surplus qui fait plaisir au concepteur est totalement inutile, voire handicapant pour une bonne accessibilité de ce que je recherche.
[…]
la principale constatation que je fais, c'est la prédominance de l'esthétique et des animations au détriment de la présentation des informations utiles.
[…]
@ QuentinC : nous sommes bien d'accord que les temps de chargements doivent être réduit à leur maximum. Une présentation minimaliste n'est pas un défaut de conception mais plus une présentation de ce qui doit être essentiel dans un site.

Alors je pense qu'il ne faut pas exagérer non plus dans ce sens. D'aucuns se souviendront du débat/troll sur le «webdesign honnête» initié par A List Apart qui a été l'occasion de pas mal d'échanges (et d'affrontements) dans la communauté francophone… un débat qui s'est avéré fructueux pour tout le monde selon moi d'ailleurs

L'esthétique, le design, le graphisme, les… animations –pour autant que tout ça soit fait professionnellement– font partie intégrante d'un site web comme de tout support de communication (oui oui, les animations aussi ;–) ). Tout cela participe à véhiculer de l'information et ne devrait pas être assimilé à de la simple déco «inutile».
Je suis surtout dév front mais il y a aussi un moment où il faut reconnaitre que ramener ce qui fait partie du design –des animations aux sprites (berk) en passant par l'ambiance graphique générale de la page– à une simple lubie coûteuse en perfs, c'est une erreur. Et le faire sous prétexte d'accessibilité, ça l'est encore plus ! L'identité d'une marque, d'un territoire, d'une agence, d'un journal en ligne… tous les repères graphiques que le design apporte, c'est aussi de l'information.

Bien entendu, se placer dans une démarche d'accessibilité et d'amélioration des performances, c'est indispensable (et encore, pas partout : public cible, toussa, poke STPo), mais on est aussi pas mal revenus de la lecture de fils RSS purs

Victor BRITO a écrit :
Il n'y a qu'une seule bibliothèque jQuery. À moins que tu n'aies voulu parler d'appel à un plug-in jQuery en plus de l'appel à la bibliothèque elle-même…

J'imagine que tournikoti parlait plutôt des double appels de la bibliothèque (souvent une minifiée, l'autre non, voir dans des versions différentes… vive les conflits potentiels !) malheureusement fréquents lorsque le site passe par un intégrateur puis par des dévs, etc., sans méthode de travail ou presque (Rache©…). C'est aussi souvent le cas lorsque une maquette HTML est intégrée pour un CMS à la va-vite (Rache© bis)… En fait il y a plein de petites situations –évitables facilement, mais bon !– dans lesquelles le navigateur va parfois se retrouver à charger deux fois la bibliothèque

Victor BRITO a écrit :

Cela dit, pour certaines valeurs calculées dynamiquement (je pense, par exemple, au positionnement des éléments constitutifs d'un carrousel), il sera difficile de se passer de JavaScript (à moins de multiplier les classes non sémantiques générées à la volée au moyen d'un préprocesseur CSS, pour obtenir un .l-moins-1280 { left: -1280px; }, un .l-moins-1279 { left: -1279px; }, et ainsi de suite ).

Au secours !
Modifié par audrasjb (05 Nov 2013 - 15:05)

Bonjour à toutes et à tous.

"Victor BRITO" a écrit :
Encore une fois, jQuery n'est pas un langage, mais une bibliothèque JavaScript.

Je sais très bien que jQuery repose sur du JavaScript et que c'est une bibliothèque, pardons un framework. Désolé, mais ma langue à fourchée. Les mauvaises habitudes sont tenaces.

"Victor BRITO" a écrit :
Il s'agit moins d'un problème d'accessibilité que de performances Web.

Je ne comprends pas ta réponse ? Ne serait-il pas possible d'être un plus minimaliste dans la conception des sites ? J'ai accédé à des sites, qui nous ouvre une multitudes de fenêtres et je ne sais quoi d'autre, comme des diablotins sortant de leur boite.

"Victor BRITO" a écrit :
Il n'y a qu'une seule bibliothèque jQuery. À moins que tu n'aies voulu parler d'appel à un plug-in jQuery en plus de l'appel à la bibliothèque elle-même …

Je parle des différentes versions du même framework jQuery qui coexiste dans la même page. La cause comme le dit audrasjb, provient d'une multitude de maintenances faite par différentes personnes qui n'ont pas la même compétence. Et l'on ne parle même pas des confits possibles.

"Victor BRITO" a écrit :
Une question à laquelle Felipe et Yvan L. ont apporté des réponses pertinentes.

Pertinentes pour eux, oui ! J'avoue que passer par du jQuery alors que l'équivalent existe en JavaScript pur, sans que cela soit plus compliqué à mettre en œuvre, ne se justifie pas à mes yeux.

"Victor BRITO" a écrit :
En tenant compte des toutes dernières versions d'IE, il n'y a plus de quoi être aussi catégorique que cela.

Mais je croyais que la principale raison du framework jQuery était justement la compatibilité entre tous les navigateurs ?

"Victor BRITO" a écrit :
Le JavaScript sera toujours utile, ne serait-ce que parce qu'il est le langage sur lequel reposent les API apparues en HTML 5.

Je ne te parle pas sur quoi repose les API du HTML5, mais si l'on va encore utiliser le JavaScript et le jQuery dans les développement. A moins que tu considères que son rôle va diminuer car ces API font se substituer à du développement qui n'a plus de raison d'être ? Autrement dit, le CSS3 va fournir des propriétés qui ne nécessiteront plus une complémentarité dans le JavaScipt ou le jQuery.

"Victor BRITO" a écrit :
Je croyais que ton sujet traitait de la prédominance de jQuery au détriment du JavaScript pur…

Si si, c'est bien ma question !

Mais je la complète aussi par le fait, et je peux me tromper, qu'il sera de moins en moins nécessaire de faire du développement en JavaScript pur et en jQuery, car presque tout sera disponible par des propriétés en CSS3 qui se suffiront à elle-même.

"audrasjb" a écrit :
Alors je pense qu'il ne faut pas exagérer non plus dans ce sens.

C'est une réponse toute relative !

"audrasjb" a écrit :
L'esthétique, le design, le graphisme, les… animations –pour autant que tout ça soit fait professionnellement– font partie intégrante d'un site web comme de tout support de communication (oui oui, les animations aussi ;–) ).

En te lisant, j'ai l'impression que plus tu en mets et mieux c'est. Et ton seul argument, pour justifier cela, c'est "que tout ça soit fait professionnellement" !

"audrasjb" a écrit :
Tout cela participe à véhiculer de l'information et ne devrait pas être assimilé à de la simple déco «inutile».

Justement, c'est qu'il y a une ambiguïté entre information utile et décoration ! Et pour répondre franchement à ton affirmation, cela dépend du contexte. Un logo est utile car porteur d'une information, une image, non ! Inversement, si je cherche une chambre d'hôte, voir des images sous forme d'une galerie de photos, ça, c'est utile, parce que c'est un argument de vente !

"audrasjb" a écrit :
Je suis surtout dév front mais il y a aussi un moment où il faut reconnaitre que ramener ce qui fait partie du design –des animations aux sprites (berk) en passant par l'ambiance graphique générale de la page– à une simple lubie coûteuse en perfs, c'est une erreur. Et le faire sous prétexte d'accessibilité, ça l'est encore plus !

Autre argument que tu soulèves est la performance. Sur la question de la seule performance, je suis d'accord ! Mais la performance de qui ? De l'ordinateur du concepteur ou de celui de l'internaute au fin fond de sa campagne ? Car si ton ordinateur est booster, tu trouveras cela rapide et tu vas justifier se surplus comme normal, alors que tu ne te rendra même pas compte que l'ordinateur de l'internaute met 1/4 d'heure pour charger cette même page.

"audrasjb" a écrit :
L'identité d'une marque, d'un territoire, d'une agence, d'un journal en ligne… tous les repères graphiques que le design apporte, c'est aussi de l'information.

Oui, je suis d'accord, mais ne pas être dans la démesure. Un seul et petit logo suffit amplement. Pourquoi mettre en arrière plan une image lourde qui est couteuse en performance comme cela se fait parfois. De petites sociétés se sentent obligées de mettre la façade de leur entreprise dans la page d'accueil, alors qu'un grand nombre d'internaute, pour ainsi dire tous, ne se rendront jamais en ce lieu.

Comme tu le dis, audrasjb, on s'est écarté un tantinet du sujet de base. Je ne considère pas cela comme un hors sujet, car justement ces débordements dont on parle sont la cause d'une part des mauvaises performances et d'autre part de la justification de l'usage du JavaScript pur ou du jQuery pour ces animations bien inutiles.

Ce n'est pas un sujet pour troller, mais bien une question qui m'intéresse car du fin fond de ma campagne, je n'ai pas des interlocuteurs qui puissent me dire le pourquoi du comment, qui semble si évident pour beaucoup d'entre vous.

@+

Bientôt des sockets et du XHR en CSS. On va s'éclater...

Yop,

tournikoti a écrit :
Pertinentes pour eux, oui ! J'avoue que passer par du jQuery alors que l'équivalent existe en JavaScript pur, sans que cela soit plus compliqué à mettre en œuvre, ne se justifie pas à mes yeux.

Ben si tournikoti (j'aime bien ton pseudo décidément ), c'est justifié depuis un moment dans ce topic, car souvent on n'a pas juste une pauvre petite sélection d'ID à faire, et la lib va très rapidement s'imposer : son interopérabilité importante ; le fait qu'elle soit très "populaire" et qu'elle évolue en conséquence en fait un point stratégique intéressant au niveau de la continuité du projet (il faut voir le marché du recrutement côté inté ou dév front – même s'il est souvent über caricatural) ; ses perfs sur certains points saillants et sa mise en œuvre relativement peu coûteuse par rapport à des développements JS qui peuvent vite devenir assez complexes et difficiles à maintenir…
… Le tout fait que cette lib a de très beaux jours devant elle
… Et si elle est utilisée correctement, elle n'est pas si gourmande que ça en ressources finalement.

tournikoti a écrit :
En te lisant, j'ai l'impression que plus tu en mets et mieux c'est. Et ton seul argument, pour justifier cela, c'est "que tout ça soit fait professionnellement" !

Non ! justement, tournikoti, c'est le job du webdesigner. Il n'est pas forcément sensé tabler sur la quantité mais –aussi– sur la qualité ("ce sera peut-être un peu plus lourd, mais ça vaut le coup") des éléments identitaires de sa maquette et de ses intentions : le design (en anglais) ça véhicule autant le dessin que le dessein. C'est aussi là que beaucoup de choses se passent. Il y a beaucoup d'informations qui passent par le design, au sens général du terme.

tournikoti a écrit :
Justement, c'est qu'il y a une ambiguïté entre information utile et décoration !

Dans mon intervention précédente, je tenais justement à te préciser le fait que ce que tu appelle décoration est peut-être en fait une information au sens strict. Je prends des exemples pas forcément représentatifs (ou trop), pour illustrer mon propos => Si je te présente deux articles sur le même sujet de société du Figaro ou de Libération sans aucune mise en forme ni mention du journal, tu devrais lire et ensuite tu reconnaitra probablement/peut-être certains patterns éditoriaux qui te feront reconnaitre l'identité ou du moins l'orientation du journal. Si je t'ajoute un logo au dessus de l'article, tu décodera l'identité du journal à coup sûr et en tireras un certain nombre de conclusions avant lecture. Si je restitue une "ambiance" proche de "l'esprit" de chaque journal, à l'aide de typos (pas forcément websafe, donc à l'aide d'imports de fonts potentiellement coûteuses en termes de perfs), d'illustrations, de couleurs, si j'appose une charte graphique complète en somme, tu pourra te retrouver à adhérer à une "communauté de lecteurs". Encore une question de stratégie de communication. Une page web, ce n'est pas que de l'informatique et de la transmission d'information pure et dure.

Mon exemple fondé sur des sites de PQN est caricatural, mais il révèle le fond de ma pensée. C'est ce qui fait aussi que des sites comme ceux de certains des intervenants sur ce topic et sur le forum en général véhiculent justement quelque chose de particulier : ils proposent un design qui n'est pas uniquement celui des mots, du contenu, mais aussi de leur mise en forme (images de fond et animations aidant, pourquoi pas).
Il appartient à chacun d'ensuite mettre en œuvre les bonnes pratiques relativement bien connues et recommandées sur ce forum afin de donner toute son importance au contenu et de respecter les critères d'accessibilité élémentaires

tournikoti a écrit :
Autre argument que tu soulèves est la performance. Sur la question de la seule performance, je suis d'accord ! Mais la performance de qui ? De l'ordinateur du concepteur ou de celui de l'internaute au fin fond de sa campagne ? Car si ton ordinateur est booster, tu trouveras cela rapide et tu vas justifier se surplus comme normal, alors que tu ne te rendra même pas compte que l'ordinateur de l'internaute met 1/4 d'heure pour charger cette même page.
[…]
Ce n'est pas un sujet pour troller, mais bien une question qui m'intéresse car du fin fond de ma campagne, je n'ai pas des interlocuteurs qui puissent me dire le pourquoi du comment, qui semble si évident pour beaucoup d'entre vous.

Ah mais il faut quand même pas charrier non plus… j'habite en Ardèche : on n'a pas de gare d'arrêt SNCF, ni d'autoroute mais on a une connexion suffisante pour bosser de façon professionnelle et pour pouvoir afficher la plupart des "gros" sites web avec à peine moins de 1000 millisecondes que quand on habitait à Grenoble ! Bon si on se prend un coup de foudre on n'a plus rien mais à part ça…
Non sérieux, travaillant avec des collectivités sur des projets de webapps localisées, je sais bien qu'il faut tenir compte des perfs, et pas forcément compter sur de grosses connexions. Cela dit, je ne pense pas que ce soit jQuery qui soit forcément le plus incriminé dans les mauvaises perfs que tu décrit. D'ailleurs dans tes exemples, il semble en l'occurrence beaucoup plus s'agir de mauvaises pratique en tant que telles (tu parles d'ouverture de multiples fenêtres, etc., et jb_gfx évoque des sites de poker en ligne… *) je ne veux pas te jeter la pierre mais…)


(*) note provisoire et à caractère autodestructible dès que besoin s'en fait valoir : la remarque entre parenthèses est une attaque discutable vus les propos précédents et j'accepterais évidemment de la retirer si cela importune tournicoti Modifié par audrasjb (06 Nov 2013 - 01:04)

jb_gfx a écrit :
Bientôt des sockets et du XHR en CSS. On va s'éclater...

Haha, on va faire de l'ajacss