Guillaume Denry a écrit 2971 commentaires

Est-il préférable d'ajouter des éléments dans le dom depuis le html, ou de les créer par javascript ? Pourquoi ? (performances ou autres) Quelles règles à respecter à ce niveau ?

On va partir de l'hypothèse qu'on parle d'une application comme la tienne qui tourne entièrement sur le navigateur ou au moins qui délègue entièrement son rendu au navigateur.

Dans ce cas là, la modification du DOM via JavaScript répond essentiellement à des besoins "dynamiques", par exemple, si je veux créer un ensemble de sprites qui correspondent à l'ensemble des objets que j'ai défini en interne dans mon programme JavaScript. Le bon sens veut en effet qu'on automatise le plus de choses pour éviter de se répéter un peu partout dans son programme et dans ce cas là, la page html de base ne devra pas contenir grand chose.
C'est la tendance actuelle pour les "Web Single App" : on définit grosso modo une structure générale statique en HTML et on laisse ensuite le programme gérer le DOM de façon dynamique.
Dans ton cas, tout l'"univers" de ton jeu devrait idéalement être généré par JavaScript, surtout que comme ça, on a pas à faire constamment l'aller/retour entre le code et la page pour avoir une idée de comment tout ça s'articule.

Lorsque l'on utilise fréquemment une référence à un élément du DOM, est-il préférable de faire un appel à la fonction javascript lors de chaque appel, ou de créer une variable globale avec cette référence ?

L'utilisation de variable pour stocker des résultats d'appels de fonction répond principalement à deux besoins :
1/ avoir un cache pour le résultat d'appel de fonction (optimisation)
2/ éviter de se répéter dans le code (maintenabilité)

Dans la plupart des cas, la maintenabilité d'un code est pour moi plus important que son optimisation, et en tout cas, on ne devrait pas se soucier trop tôt de l'optimisation de son programme. Comme dirait Donald Knuth, "Premature optimization is the root of all evil (or at least most of it) in programming."

Dans ton cas, récupérer un élément par son id est quelque chose d'ultra optimisé, surtout par les navigateurs actuels, cela dit, ça reste un appel de fonction.
Dans une boucle de 1 000 000 itérations, utiliser getElementById avoir le même id ne serait probablement pas très malin.
Cependant, dans la grosse majorité des cas, c'est l'élégance du code, la concision et le soucis de ne pas se répéter qui devrait primer, et c'est parfois aussi une question de goût.
En gros, pour moi, dans ton contexte, il n'y a aucun soucis à utiliser getElementById() à chaque fois qu'on a besoin de travailler sur l'élément, si ce n'est que de voir 4 getElementById('toto') au sein du même bloc d'instructions sera pénible à relire/maintenir.

Bien sûr, aucun soucis

Si ça t'intéresse, je peux te proposer un patch ou pull request.

localement, let est limité au bloque tandis que var est limité à la fonction (globalement, il n’y a pas de différence)

J'essaye au possible d'écrire des fonctions courtes donc effectivement, re-déclarer deux fois la même variable dans une même fonction ne m'arrive pas souvent. Mais il est possible que ça soit intéressant dans d'autres cadres. En tout cas, ça ne permet plus d'écrire ce genre d'horreur :

function toto() {
  if (...) {
    var toto = 4;
  }
  console.log(toto);
}

Avec let, ça ne passe pas.

en mode « strict », let définie des constantes.

Non, en mode strict, ce qu'on ne peut pas faire, c'est redéclarer la même variable deux fois dans un même scope.

Pour faire une "constante" (*), il faut utiliser const.

Je parlais de "hoisting" plus haut, le var peut être piégeux à cause de ça, let et const ne te permettent pas d'utiliser les variables avant leur déclaration (oui ça semble idiot de faire ça, mais pas mal de développeurs JavaScript usaient et abusaient de ça), et donc, n'avaient pas forcément conscience qu'en déclarant un var toto en plein milieu d'une fonction, toto était en fait remonté en haut de la fonction par l'interpréteur.
let est ce que var aurait dû être dès le départ.
Comme === est ce que == aurait dû être dès le départ.
On constate que de nombreuses améliorations des différentes moutures de JavaScript ont pour objectif de corriger les erreurs de jeunesses du langage.

(*) en réalité, seule la valeur de variable est constante, on ne peut pas utiliser const pour faire réellement de l'immutabilité, par exemple.

const obj = { a: 4 };
obj.a = 5; // parfaitement autorisé

En pratique, la "fausse" immutabilité de const fait que ce dernier est largement plus utilisé que let dans les programmes depuis ES6. A vue de pif, je dirais que j'utilise 15 fois plus de const que de let. (et plus aucun var)

Quelques remarques en vrac (sur le code) :

• Ca pique un peu de voir autant de variables globales et aussi destructurées, je recommande vivement d'en faire le bilan et de distinguer celles dont tu as besoin pendant toute la vie de ton application (comme difficulte) de celles qui ont une durée de vie courte et localisée (comme PositionX) et qui pourront donc être déclarées au plus proches de l'endroit où elles sont utilisées. Tu peux organiser tes variables de façon hiérarchisée et en partant d'une seule variable globale etat et qui contiendrait l'ensemble des paramètres de ton application.

Exemple :

    const etat = {
      difficulte: 1,
      objects: [], 
      masses: [],
      chargeGauche: 0,
      chargeDroite: 0,
      (...)  
    };

• De manière générale, ne pas hésiter à écrire le plus possible de fonction "pures", c'est plus facile de raisonner dessus quand on relit le code par exemple : la plupart de tes fonctions lisent et écrivent des variables extérieures à elles, c'est difficile de suivre le fil quand on se plonge dedans => ne pas hésiter à utiliser des arguments dans les fonctions pour éviter ce phénomène. Si tu réorganises les variables de ton programme dans un "etat", tu pourrais passer cet "etat" en argument des fonctions pures.

• Pas mal de variables sont déclinées en 4 catégories, si j'ai bien compris, ces catégories correspondent à la fois à des index de séries d'objets mais aussi au niveau de difficulté courant. Pour mieux s'y retrouver, je regrouperai toutes ces données de manière plus sémantique (c'est juste une façon d'organiser, y'en a plusieurs possibles) :

    const series = [
      {
        difficulte: 1
        objets: [
          ["img/boite-mais.png",413,116,132,"auto"],
          ["img/cahier.png",96,239,137,"152,38"],
          (...)
        ]
      },
      {
        difficulte: 1
        objets: [
          (...)
        ]
      },
      {
        difficulte: 2
        objets: [
          (...)
        ]
      },
      {
        difficulte: 2
        objets: [
          (...)
        ]
      }
    ];

• Je ne sais pas pourquoi tu n'as pas utilisé le même système de déclaration statique des masses dans le jeu, au lieu d'écrire cette horrible fonction creeMassesBase() :-), ca permettrait de réduire pas mal le nombre de lignes de code et l'expressivité
• la fonction estPresent est à la fois dans balance.js et dans outils.js
• Cela dit, tu peux la remplacer par monTableau.indexOf(monElement) >= 0 ou bien monTableau.includes(monElement) si tu peux t'en ficher d'internet explorer.
• Se tenir à une nomenclature cohérente au niveau du nommage : par exemple, en JavaScript, l'usage veut qu'on commence le nom d'une variable en minuscule (camelCase)
• Tu utilises des var et des let, je te recommande de laisser tomber var et d'adopter const, tu éviteras le problème d'hoisting et bénéficieras également de la vérification de mutabilité de la constante
• Je recommande l'usage de noms anglais dans le code source si tu souhaites partager ce code en dehors de la francosphere

Y'aurait encore plein d'autres trucs à dire, mais j'arrête là.

En tout cas, beau projet, et ça marche plutôt pas mal sur mon ordi. Je pense qu'une amélioration fonctionnelle serait de guider un peu plus le joueur lorsqu'il souhaite déposer des poids, en mettant par exemple en surbrillance la zone de dépôt, pendant le drag'n'drop.

Je suis franchement plus partagé. Au moment de la mort de Jobs, ça faisait longtemps que son "oeuvre" (selon Stallman) était achevée. Est-ce que Stallman pense vraiment que la disparition de Jobs rendra le monde du logiciel meilleur ? Est-ce que ça n'était pas trop tard de toute façon ? C'est en cela que je trouve la sortie de Stallman assez mesquine et petite.

Je suis plutôt d'accord avec le contenu de ton message, mais le titre est à gerber, donc moinssage.

Les droits du libre… Je pensais que c'était de libérer l'utilisateur en lui offrant des outils de qualité ? :)

Non, la qualité est éventuellement un effet de bord du libre, mais ça n'a rien à voir avec le libre.

Plus je lis tes réponses à côté de la plaque, imprégnées du ton condescendant et hautain que tu adoptes, plus je me dis que les gens comme totof2000 ont bien du courage de te répondre de façon aussi argumentée.

TCP corrige les problèmes de perte ponctuelle de paquets ou d'arrivée dans le désordre de la couche IP.

Ce ne sont pas des "problèmes" d'un point de vue IP, puisqu'IP ne garantie pas l'ordre des paquets ni que les paquets arrivent tous au destinataire, et c'est tout-à-fait délibéré.

NodeJS n'est pas qu'un moteur d'exécution JavaScript donc non.

Je ne comprends pas pourquoi tu es surpris…

Personnellement, j'ai moinssé parce que :
- il s'agit ici d'un simple copier/coller d'un billet de blog
- la forme est déplorable, le logiciel n'est pas présenté, on ne dit pas que c'est un logiciel libre, pas de lien explicite vers le site, vers le github, on n'explique pas clairement quelles sont les nouveautés du logiciel
- On parle d'une version "ultimate" sans présenter ce que c'est, et ça n'est même pas sur le site
- Petit lien de pub pour acheter des trucs

J'ai un mal de chien à trouver les sources sur le site…

Par contre, je ne m'attendais pas à lire ici de telles horreurs homophobes, et encore moins à les voir autant pertinentées. Idem avec les messages qui renversent le rapport agresseur / victime.

Je me demande si quelque part, ça n'est pas bon signe pour linux et la communauté du libre qu'il y ait une telle diversité :)

"Hiver".

Voilà.

Le pire c'est les trucs du genre Ugears ou ROKR (maquette en bois) : c'est génial à monter, à jouer avec 5 jours mais ensuite, on se demande bien où les mettre.

Juste pour te dire pas merci.

Depuis que j'ai lu ton journal hier, j'ai sans arrêt l'air de Capitaine Flam dans la tête, et ça m'a poursuivi jusqu'à mes insomnies :)

si il faut se taper les ouates mille film avant de comprendre la moelle du film, très peu pour moi.

Non, La Classe Américaine est une sorte de patchwork, ce que tu suggères c'est un peu comme si pour apprécier un morceau de hip-hop, on avait besoin d'écouter toutes les musiques originales dont sont issus les samples.

Ca dépend ce que tu appelles "pleinement", mais personnellement, je n'ai vu quasiment aucun des films qui constituent le patchwork de la Classe et je me bidonne quand même.

C'est difficile d'analyser un phénomène comme La Classe Américaine, mais je pense que ce qui fait surtout marrer les gens tient dans le côté transgressif du flim : on fait dire des grosses conneries à des acteurs légendaires dans un contexte de films légendaires, et en utilisant leurs doubleurs français officiels par dessus le marché.

J'ai pas dû m'exprimer de façon très claire, je suis d'accord sur le fait qu'il n'y a pas de recette toute faite, je voulais juste dire que parfois il faut lutter contre son envie de supprimer tout pleure chez l'enfant à des moments stratégiques dans la journée car sans se rendre compte, en faisant cela systématiquement, on ne cesse de l'interrompre dans sa routine d'endormissement.
En tout cas, chez nous, ça nous a sauvé nos nuits.

un enfant de 2 ans qui ne fait pas ses nuits. Les parents doivent être épuisés, et l'enfant aussi et cela doit gêner ses apprentissages (alors qu'un enfant est capable de faire ses nuits dès 3 mois et 5 kg) (faire ses nuits == dormir 7 heures d'affilée la nuit)

Ce point là résonne en moi car c'est LE piège principal dans lequel tombent les jeunes parents : aller voir son bébé au moindre pleure de celui-ci. Le pleure du soir (*) dans le lit fait partie du "rituel" du très jeune bébé, il est important de ne pas l'interrompre avec des "allez viens dans mes bras mon chéri" toutes les 5 minutes, car on "casse" le rituel et le bébé perd ses repères.

J'ai vu pas mal de couples galérer avec ça et ne pas réussir à dormir pour cette raison, dont le mien, les premières semaines. Heureusement qu'une copine bienveillante nous a remis dans le droit chemin assez vite.

Chez nous, on appelait ça la "règle des 5 minutes" : on ne va pas voir le bébé qui pleure avant 5 minutes chrono. Mais ça peut bien sûr varier suivant la personnalité du bébé, et d'autres paramètres.

(*) à condition qu'on ait pas affaire à de "vrais" soucis : douleur, faim, etc, et prendre également en compte l'âge du bébé

Si je comprends bien ton propos, une politique commerciale ne regarde personne d'autre que ceux qui la produisent et il n'est pas logique de la critiquer de l'extérieur ?
Par exemple, imaginons une stratégie commerciale qui consiste à faire un prix d'appel, à capter un monopole ou un quasi-monopole, puis à monter les prix petit à petit, après tout, c'est une politique commerciale comme une autre hein, qu'est-ce qu'on aurait à lui reprocher ?

Ok, je sens le gros private joke :)

Je pige pas le score de ce journal (35), j'ai raté quoi ?

C'est juste parce que y'a des gens qui connaissaient pas encore La Poudre Verte ?

Tu te sens d'aller voir un boulanger pour râler à propos de sa politique commerciale ?

De la politique commerciale d'une entreprise émane des effets publics très concrets qu'il est parfaitement possible de critiquer, par quelque biais que ce soit.
Lorsque je souligne ce qui me paraît être disconvenant dans la façon dont un(e) commerçant(e) vend quelque chose, je ne suis pas en train de lui dire "Vous devriez faire comme ci, comme ça" mais plutôt "ce que vous faites actuellement ne me plaît pas, je vais (voir ailleurs)/(reste quand même)". La personne fait ce qu'elle veut de cette info, mais à mon avis, si c'est une personne/société agile, elle prendra soin de recueillir les avis de sa clientèle pour éventuellement agir en conséquence. Ou pas.