Bonnes pratiques JavaScript [Débat]

**Willpower** · 15/03/2011, 20h40

Envoyé par Bovino

Alors si je peux me permettre de recentrer un peu le débat, je rappelle que le titre de la discussion est

Or les bonnes pratiques et les performances ne sont pas toujours en rapport, loin de là.
A titre d'exemple, les bonnes pratiques demandent habituellement de placer les scripts dans la balise <head> du document, ceci afin de pouvoir respecter le principe de séparation des couches ((X)HTML pour le contenu, CSS pour la présentation et JavaScript pour le comportement), or la recherche de performances préconise plus de placer les scripts juste avant la fermeture du </body>.

Du coup, pour répondre à

je partage l'opinion de sekaijin : à mon sens, la bonne pratique est de stocker dans une variable les données utilisées plusieurs fois plutôt que de les rechercher plusieurs fois.
C'est la même raison qui fait qu'il est préférable de stocker le length avant une boucle plutôt que de rechercher cette valeur à chaque itération.

pour mon length, je trouve ça vraiment moche de rajouter une ligne de code pour les petits parcours (genre 3 iters)

genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
var length = tableau.length;
for(var i=0;i<length;i++)
  document.write(tableau[i]+"<br/>"); // c'est fait exprès parce que je sais que vous êtes allergiques au document.write ^.^

plutot que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
for(var i=0;i<tableau.length;i++)
  document.write(tableau[i]+"<br/>");

alors en général, je me contente d'un compromis entre les 2 quand le parcours n'a pas de "sens de traitement" imposé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
for(var i=tableau.length-1;i>0;i--)
  document.write(tableau[i]+"<br/>");

**Bovino** · 15/03/2011, 20h52

Je suis d'accord avec toi, mais là il s'agit du pragmatisme dont parlait sekaijin

Vouloir toujours appliquer les bonnes pratiques peut contribuer à alourdir inutilement le code.
En revanche, connaitre les bonnes pratiques permet de choisir ses options au mieux.

**sekaijin** · 15/03/2011, 21h02

Envoyé par marcha

Qu'entends-tu par bien plus efficace ? gagner 10 nano secondes toutes les
secondes ? getElementById est optimisé aujourd'hui par les navigateur, c'est
un non sens de chercher à économiser quelques cycles CPU au détriment de
la simplicité d'écriture du code.

heu c'est quoi le plus simple ??
exemple on cherche l''élément à chaque click

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
<script>myFonction(id) {
   el = document.getElementById(id);
   //fait quelque chose avec el
}</script> 
<a id="45" onclick="return myFonction(45)">click</a>

le même

Code html :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<script>myFonction(el) {
   //fait quelque chose avec el
}</script> 
<a onclick="return myFonction(this)">click</a>

lorsque tu a trois élément dans ta page pas de pb
j'en ai parfois plusieurs dizaines de milliers
et je peut affirmer que ça ce voit

d'ailleurs beaucoup de lib on une fonction qui fait ça
dès que tu cherche un éléments elle en place une référence dans un tableau au cas où pour le coup d'après.
et ce n'est pas un hasard.

quand à la simplicité du code c'est généralement beaucoup plus simple d'avoir une référence que de jongler avec les ids.

mais là encore il faut être pragmatique.
dans une page HTML avec un plugin Jquery pour saisir une date les ID c'est cool

dans une application comme ce que fait madevilts ou comme moi toujours autour de 30 000 ligne de javascript auxquelles j'ajoute ExtJS les id c'est chronophage.

il n'est donc pas question de les bannir mais de les utiliser à bon escient.

quant à chercher à les supprimer c'est une vois d'optimisation dans les grosses applications. dans ce cas on gères des milliers voire des millions d'événement dans une session. et le travail de l'utilisateur en dépends. donc comme pour une application C++ un cycle d'horloge de moins X quelques millions d'événements par session X 100 000 utilisateurs X 300 Jours.

ça représente du temps et ce temps il est payé pour travailler pas pour attendre que l'appli réagisse.

c'est peut être con mais Oui on traque les milliscondes dans les entreprise.
A+JYT

**Auteur** · 15/03/2011, 22h40

Envoyé par sekaijin

Pourquoi à chaque fois on ne se concentre que sur une partie du post des gens
en omettant ce qui change tout son sens ?

donc en toutes circonstances soyez pragmatique.

C'est étonnant de voir que lorsque quelqu'un dit
il a A
ou il a B

Les réaction sont

et ceci mais cela

Heu les gars un post c'est un tout
Lisez le entier. et si vous en critiquez une partie n'oubliez de citer ce qui dans le reste dit exactement la même chose que votre critique.

j'ai effectivement raté la fin de ton message sekaijin
Et avec la dernière ligne ton message prend un tout autre sens. J'ai donc mal compris ta pensée. Encore désolé

**laurentg2003** · 17/03/2011, 08h31

Merci pour ton explication sekaijin

trés bon topique j'apprends beaucoup de chose

**sylvain230** · 28/04/2011, 16h54

Est ce que vous pensez que c'est une bonne pratique d'intégrer la nouvelle API WebGL dans du Javascript ?

**giltheb** · 03/06/2011, 08h24

Le javascript ne possédant pas de "JIT compiler" à ce que je sais il faut trouver un bon équilibre entre garder une bonne structure pour pas que le flot de code gène sa conception et être le plus "verbose" possible ... ne pas hésiter à forcer des micro compilations comme "var length=tableau.length;" c'est un peu la base.

**sekaijin** · 03/06/2011, 11h41

suivant les moteur JS JIT ou ce qui s'en approche est présent ou pas.

le machine virtuelle JS moderne ont un fonctionnement qui à mon avis est très proche de JIT
le source est chargé dans le buffer l'analyser lexical entre en oeuvre et détecte les éléments définis dans le script comme les var et les fonctions pour chaque nom que l'analyser syntaxique détecte il crée dans la VM la définition correspondante. si c'est une fonction seule la signature est créée est le source du corps lui est associé et elle est marquée non compilé.
elle ne le sera que l'ors de la première utilisation.

ce n'est pas JIT mais ça y ressemble furieusement.

je ne sais pas si les vm comme celle IE9 ou le nouvelle version de JavaScriptCore (webkit) ne pousse pas jusqu'à faire l'analyse syntaxique sans faire la génération de code. je n'ai pas regardé le fonctionnement interne des moteur depuis longtemps. mais il me semble que IE9 stocke les chaînes de dépendance entre les fonctions et qui compile dans les temps mort certaines méthodes pour éviter les chaînes trop longues qui engendreraient des temps de compilation/exécution trop long.

les stratégies des différents moteurs sont justement ce qui les différencient.
A+JYT

Invité · 11/07/2011, 16h52

Pour ma part, en plus de ce qui a déjà été dit :

Préférer au possible le passage d'objet en paramètres de fonction lorsque beaucoup d'arguments.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
function toto(obj){
 /*ie : obj=={name:'bob',firstName:'moran',...}; */
}

Une seule "classe"=function à instancier avec new par fichier et nommer son fichier du même nom que la fonction avec la première lettre en majuscule.
Cela facilite l'exploration du code quand on dev.
Les fonctions ne nécessitant pas instanciation ont justement la première lettre en minuscule.
Toujours des accollades {} autour des if/else. Ca a déjà été dit, mais je rajoute une raison (que j'ai pe ratée). Il s'agit de pouvoir facilement tracer le code en rajoutant une ligne dans le bloc (console.log par exemple). Donc c'est pas perdu.

Lors de la définition d'une fermeture, préférer la première syntaxe

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
function Popper(objParams){
  var _private = objParams['specialProperty'];
  var that = {};
  that.kikoo = function(){
   return _private;
  };
  that.kikooUpper = function(){
    return that.kikoo().toUpperCase();
  };
  return that;
}

à la suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
function Popper(objParams){
  var _private = objParams['specialProperty'];
  var kikoo = function(){
    return _private;
  }
  return {
    kikoo:kikoo,
    kikooUpper:function(){
      return kikoo().toUpperCase();
    }
  };
}

Dans le premier cas, on a déjà moins d'indentation.
En plus, les méthodes définies sur that sont déjà accessibles par celles qu'on définit par la suite.
Dans la seconde, on est obligé de définir kikoo pour pouvoir l'appeler depuis kikooUpper, donc autant définir directement sur la variable that.

Egalement, préfixer les variables "privées" (non visibles par l'appelant) par un underscore.

Et un anti-pattern : on ne peut pas utiliser un nom de variable qui est un mot clé du langage. Donc par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
function popper(class){
 //do some stuff on html nodes with 'class' attr
}

est incorrect.
J'ai déjà vu du

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
function popper(klass){
 //do some stuff on html nodes with 'class' attr
}

pour contourner le probleme. C'est mauvais car pertube l'esprit. Préférer className, ou quelquechose dans le genre.

Voilà pour ma part.

**ensareab** · 09/08/2011, 10h36

Je réagis à un premier message où quelqu'un disait qu'il valait mieux éviter les innerHTML et leur préférer le DOM.

Personnellement je trouve que le DOM implique une connaissance parfaite de l'architecture de la page, ce qui n'est pas forcément le cas. Je m'explique : je créé moi-même un gestionnaire de blog. Chaque blog contient des articles, qui sont récupérés en base via AJAX/PHP puis mis en forme et insérés. Donc chaque article récupéré rajoute un gros bout de code contenant toute sa mise en page, bouleversant ainsi le DOM de la page : dès lors il est très difficile de remonter/redescendre via les noeuds.

Dans ce cas, rien de mieux que de bons vieux innerHTML sur des byId (dojo).

**sekaijin** · 12/08/2011, 14h54

je ne vois pas en quoi
un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

document.getElementById('myId').innerHtml('ici du code source html avec des concaténation de chaine complexe pour insérer des ' + myVariable + ' le reste du Html en faisant attention que le code source soit conforme car il est facile d\'oublier de fermer une balide.')

n'a rien de mieux que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
document.getElementById(
  document.createElement('Div')
    .setAttribute('class', myVariable)
    .appendChild(document.createTextNode(
      'ici la variable s\'insère sans concaténation sans pb de syntaxe html'
    ))
);

bref que tu passe par innerHTML ou DOM ça ne change rien sur la page existante seul le fragment que tu définit passe par une interprétation de javascript qui passe ensuite par une interprétation d'une chaîne html généré pour donner un arbre DOM dans le cas d'Inner ou par l'interprétation de javascript pour donner un arbre DOM

pour le reste pour l'arbre déjà existant ça ne change rien que tu passe par un parcours de l'arbre existant ou par un getElementById seul la façon don tu traite ton fragment change.

A+JYT

**madevilts** · 12/08/2011, 16h34

Au niveau des performances, qu'en pensez vous sur les nouveaux navigateurs ?

Il y a 2 ans sur IE7 j'avais testé l'utilisation du DOM ou du innerHTML, sous IE7, l'utilisation du innerHTML était presque 2x plus rapide.

Y a t'il des choses à éviter / ne pas faire ?

Sur des RIA, il est difficile de mesurer la "lourdeur" du javascript sur les machines peu puissante.

**Bovino** · 12/08/2011, 16h42

Effectivement, pendant longtemps, la performance a été du coté d'innerHTML. Il me semble que sur les versions récentes des navigateurs, la tendance s'inverse.
Ceci dit, innerHTML peut aussi poser des problèmes... pour IE

Voir : http://www.developpez.net/forums/d97...l/#post5463783

**madevilts** · 12/08/2011, 17h11

Ton exemple est très interessant néanmoins il me parait un peu paradoxale de faire une telle manoeuvre, à savoir : commencer par utiliser innerHTML puis continuer en DOM.

Personnellement, autant que je peux j'utilise le DOM mais lorsque je souhaite remplir une popup avec du html reçu en ajax (par exemple), en un seul innerHTML, c'est souvent le plus pratique.

Enfin, en clair, j'utilise soit l'un, soit l'autre mais jamais les 2 comme dans ton exemple.

Pour ce qui est des performances, c'est assez étonnant. J'avais comparé entre IE7 et FF3, globalement FF3 est plus rapide mais sur certaines méthodes il était plus lent que IE. Je ne me souviens plus exactement mais sur la 1ere partie de mon code, IE était 20% + rapide que FF3, puis le renard reprenait l'avantage en lui collant +80% sur la génération du DOM.

**Eric2a** · 12/08/2011, 17h21

@Bovino

Après la lecture du message d' ensareab j'ai de suite pensé au message que tu avais déposé dans le fil de discussion dont tu viens de placer le lien ici. Tant mieux parce que je ne le trouvais plus.

@ensareab

Avant je disais :

"Moi j'aime utiliser le couple document.getElementById / innerHTML"

Parce que c'est simple mais surtout parce que je n'avais pas envie de me prendre la tête avec DOM.

Après avoir vérifié la démonstration de Bovino, je me suis mis modestement au DOM. Et maintenant je n'utilise innerHTML que dans de tès rares occasions.

**Lcf.vs** · 11/11/2011, 12h46

Pour moi, la seule utilisation propre d'innerHTML, c'est pour vider entièrement un noeud...

Dès qu'il s'agit d'ajouter du contenu -> DOM.

**Willpower** · 11/11/2011, 14h13

Envoyé par Bovino

Effectivement, pendant longtemps, la performance a été du coté d'innerHTML. Il me semble que sur les versions récentes des navigateurs, la tendance s'inverse.
Ceci dit, innerHTML peut aussi poser des problèmes... pour IE

Voir : http://www.developpez.net/forums/d97...l/#post5463783

Le problème c'est que tu mélanges 2 façons de faire (bon ok, le vrai problème c'est IE mais soit).

Tu crées un DIV en DOM.
Tu l'injecte dans un autre DIV.
Tu détruis le contenu de cet autre DIV grâce à innerHTML.
Tu essayes de réinjecter ton premier DIV grâce au DOM.

IE a donc détruit le contenu de ton autre DIV (et sa hiérarchie descendante) au lieu de les détacher simplement de ton autre DIV. Maintenant, je trouve ce comportement "presque" normal. Vu que innerHTML n'est pas une méthode de manipulation du DOM et n'est pas censé savoir qu'on garde des objets de type DOM en dehors de ceux attachés au document.

Personnellement ton exemple ne me convainc pas d'exclure mes appels à "innerHTML" pour mes "petits" projets. Par contre, effectivement, j'éviterai les mélanges. (DOM et innerHTML).

EDIT: je n'étais pas encore arrivé à la réponse de madevilts, on est apparemment sur la même longueur d'ondes.

**Willpower** · 11/11/2011, 14h16

Envoyé par Lcf.vs

Pour moi, la seule utilisation propre d'innerHTML, c'est pour vider entièrement un noeud...

Dès qu'il s'agit d'ajouter du contenu -> DOM.

C'est l'exemple que Bovino montrait comme "mauvais".

**Lcf.vs** · 11/11/2011, 17h38

Ah, oui, tiens, un cas que je n'avais pas encore rencontré, pourtant, j'aurais dû m'en douter, pas la première "amnésie" d'IE que je remarque...

L'ébauche de mon premier article y pointe un cas

**Fenn_** · 02/02/2012, 14h54

Une intervention un peu tardive. ^^'
J'ajoute de l'eau au moulin "pourquoi bannir eval() et dérivés" :

Lorsqu'on utilise un minifier dans le process de release de l'environnement de développement vers l'environnement de prod, noms de fonctions et de variables sont remplacés par des raccourcis et tout le code est placé sur une ligne. Mais les chaînes de caractères, elles, ne sont évidemment pas remplacées. Aussi, imaginons le (sale) code suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
function displayToto() {
    alert("toto");
}
setTimeout("displayToto()",300);

En environnement de développement, tout se passera bien. Mais lors du déploiement vers la production, le minifier va passer par là, et ce code deviendra:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

function a(){alert("toto");}setTimeout("displayToto()",300);

Avec comme résultat à l'exécution: "displayToto is not a function"...
Et si vous faites la même chose avec une variable, ce sera un "maVariable is undefined"...
Comme vous vous en doutez peut-être, je dis ça par expérience: il m'est arrivé de devoir intégrer dans mes apps du code fourni par des tiers, minifié évidemment, et de rencontrer ce genre d'erreur. La première fois que cela arrive, on se pose des questions, jusqu'à ce qu'on fasse une recherche sur la chaîne qui plante et qu'on la voie dans un setTimeout ou setInterval. -_-

Note: je travaille fréquemment avec des régies publicitaires. Beaucoup d'entre elles n'ont pas de développeurs et se contentent de louer des adservers dans lesquels elles pluggent des tags d'autres régies (qui parfois renvoie vers des adservers d'encore autre régies, etc.). De plus, ces tags javascript sont généralement "optimisés" pour tenter de contourner les adblockers -_-' ("optimisations" faisant systématiquement appel à document.write() et eval(). -_-" ) Au final, l'éditeur d'application qui intègre les pubs dans ses produits se retrouve avec un monstrueux bout de javascript qui écrit des iframes, s'eval lui-même, et contient plusieurs imbrications du même tonneau... Sachez-le, beaucoup de saletés js et de crashs ne proviennent pas directement des développeurs qui codent l'app sur laquelle vous vous trouvez lorsqu'ils surviennent, mais des fichus espaces pub que leur marketing les force à intégrer.

En terme de bonne pratique, je suis entièrement d'accord pour dire que le JS devrait toujours être placé dans des fichiers séparés et intégré avant la fermante de body d'une page.
Mais quand on bosse sur une grosse application, particulièrement en .Net, pour une question de réutilisabilité du code, on réalise fréquemment des "contrôles" (pour ceux qui ne sauraient pas de quoi il s'agit, ce sont des fractions de code html + code behind + code js, un peu l'équivalent d'un widget, qui forment un objet que l'on peut instancier dans les objets pages).
De plus, quand on reprend une appli qui a vécu, on doit faire avec ce qu'on a, et tout le monde ne se préoccupe pas de mettre son js là où il faudrait.
Comme workaround afin de faciliter la maintenance, j'organise mon js comme suit:
- la vue principale inclut un script externe définissant un objet js nommé selon l'application et contenant les variables globales, pour peu qu'elles soient vraiment obligatoires.
- chaque bloc de code destiné à être rattaché à un contrôle se trouve dans un fichier séparé, et contient du code "objectisé" ajoutant une propriété nommée selon la fonctionnalité à l'objet de base de l'application. Ces propriétés sont bâties sur un modèle de closure (définies comme le retour d'une fonction anonyme qui va contenir des variables et des méthodes qui pourront être privées ou publique).
- chacun de ces objets est paramétrable et possède une méthode "publique" init à laquelle passer un objet de settings.

Par exemple: (tout est en anglais car je ne code que dans cette langue. Entreprise internationale ^^)
fichier application.js:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
var Application = window.Application || { 
    iGlobal: 10,
    sGlobal: "blurp" 
};

fichier fonctionnality.js:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
var Application = window.Application || {};
var Application.Fonctionnality = (function(){
    //private var with default settings
    var _settings = {
        rootElement : element,
        booleanDummySetting : false
    }
 
    //dummy private method (not returned in the property)
    function dummyPrivate() {
        if(_settings.booleanDummySetting === true) {
            alert("blu");
    }
 
    //init method which will be public thanks to the return statement
    function init(obj) {
        //code here to merge the default settings with the option object
    }
 
    //return in which public methods have to be put in order to be public
    return {
        init:init
    }
})();

Bonnes pratiques JavaScript [Débat]

JavaScript

Discussions similaires

Partager

Partager