Javascript/AJAX : où l'utiliser, où l'éviter ?

[Maks]

bref si on te suis c'est le mal, bla bla bla... :guitare:

[niahoo]

Jobi, Joba !

Disons que certains sites abusent et que ce n'est pas nécessaire.

Mais perso mon jeu sera pas jouable sans javascript, toute l'interface et la communication avec le serveur en dépend ; tant pis pour les joueurs que je pourrais manquer, RAF.

[Xenos]

Ce n'est pas le langage javascript qui est le mal, mais l'utilisation que l'on en fait.
Par exemple, je viens de voir passer le post de Ducky sur la création d'une carte de jeu (auquel je répondrai un peu plus tard après l'avoir entièrement lu). Dans son code, j'ai vu, en le survolant, du "$script .=" ce qui me fait penser que la carte est entièrement en javascript: c'est un énorme tort! Les données de la carte ne sont pas du javascript; leur mise en dynamique, peut-être, mais les données de base sont du html. Au lieu d'utiliser un script qui indique "case.position = [x,y]" par exemple (pour positionner la case), je recommande plutôt d'utiliser un élément html auquel on applique les attributs "class" et "data-*". Avec ce système:
- les données html sont lisibles sans avoir forcément du javascript
- elles restent manipulables par javascript à postériori
- elles allègent le code en déclarant l'intégralité de la case dans le html, et l'intégralité des codes de dynamismes dans le javascript.

Ce que je reproche aux utilisateurs du javascript, c'est:
- de l'utiliser pour de la présentation: utilisez CSS, c'est fait pour!
- de l'utiliser pour des données de fond (sémantique, le web "3.0"...): utilisez html
- d'appeler un tas de scripts (ce qui ralentit la page): optimisez vos appels et évincez les scripts pas utiles!

Pour moi:
CSS = présentation (forme)
html = fond (sémantique)
javascript = dynamisme et réactivité (facilitation d'utilisation)

Or, souvent, je constate que:
- html = bouillie de divs (je sais, je faisais pareil avant de l'apercevoir que c'est bien plus efficace, propre et standardisé de changer un peu de balises et de stopper la "div-ïte" aigüe)
- css = coloration des textes
- javascript = tout le reste que je sais pas trop bien faire en html mais dont j'ai pompé des codes jvs tous faits

@Niahoo:
Un jeu non-jouable en javascript, ok, mais pour ma part, je pense que le jeu devrait être compréhensible sans javascript. En d'autres mots, la structure du code html doit refléter, par exemple, l'existence d'une carte 2D isométrique ou bien recueillir toutes les données du personnages que l'on s'est créé pour le RPG.

C'est pas tant pour les utilisateurs que pour les développeurs: mélasser les codes dans javascript rend très difficile la maintenance du site sur le long terme. Et pour exemple, des tas de sites à grand succès fonctionnent sans javascript (un peu moins bien, mais ils fonctionnent): facebook (version mobile), twitter, wikipedia, google...
Souvent, ces sites marchent mieux avec javascript, mais la bonne utilisation des 3 langages (html/css/jvs) leur permet d'être viable sans jvs ou sans css.

Bref, pour moi, le porteur de sens est le html, pas le javascript, et trop souvent, les développeurs (par facilité) font porter le fond (le sens) de leurs pages sur le javascript.

[niahoo]

Ben pour un siste web qui doit présenter du contenu, je suis d'accord. Idem pour l'aide d'un jeu, les pages wiki, les pages background ou autre ; ok.

Mais ensuite tu as plusieurs styles de jeu. Si tu veux présenter un gameplay un peu dynamique, afficher les actions jouées en temps réel, ça devient nécessaire de passer à un niveau au dessus dans la programmation côté client.

Perso j'essaie de faire une carte où on peut voir un vaisseau/bateau se déplacer ... ça serait chaud sans javascript. Là c'est un débat sans fin faut d'abord voir de quel jeu on parle, au cas-par-cas.

[Maks]

Je suis globalement d'accord avec ce que tu dis Xenos. Cependant tu soulèves de vieilles problématiques. On utilisait du Javascript pour la présentation (beurk on est d'accord) car CSS n'était pas assez poussé pour faire certaines choses. Mais ça c'était avant le HTML5

J'avais l'impression que ton dernier propos tournait plus à une critique du langage que de son utilisation (cf. "Il surcharge le client (si le client a plusieurs fenêtres ouvertes sur le même site bourré de javascript, il peut être fortement ralentit)" un peu cliché quand même).

[Xenos]

Un peu cliché, mais vrai, Maks, s'il est utilisé à mauvais escient Cliché infondé s'il est bien utilisé, selon la méthode que niahoo a synthétisée dans sa réponse (bien que pour le déplacement, on pourrait envisager d'utiliser l'animation CSS, dans un fichier généré par le serveur :p).

[niahoo]

Sauf que ton fichier CSS va générer une animation ... si ensuite un autre joueur bouge encore, tu dois recharger le CSS via ... AJAX ! ou bien recharger la page, ce qui annule de fait la possibilité d'avoir une carte dynamique. Et encore, si c'était possible, il faudrait bien être averti que tel autre joueur a bougé .. là c'est du push du coup.

[Xenos]

D'acc, je savais pas que les déplacements dépendaient aussi des autres joueurs. Dans un tel cas, ok. Je croyais que le joueur donnait des ordres à ses bateaux, et que pour les voir bouger en conséquences, tu utilisais javascript (bateau.offsetLeft=...)

[niahoo]

Effectivement si tu ne bouges que les tiens tu peux recharger la page et regarder l'animation, oui. Mais voilà, javascript offre de quoi faire des jeux en soft-real-time comme-y-disent, je vais pas m'en priver

[Sephi-Chan]

Sur Bombermine (un Bomberman massivement multijoueur), par exemple, Javascript est indispensable !