Citation :Quant à la practicité, les API DOM sont parfaitement fonctionnelles pour ça, donc perso, je trouve que se palucher des brouettes de dépendances/FW pour essayer vainement cascader magiquement l'état des variables JS dans le DOM, c'est bien plus lourdingue que de considérer que le DOM fait foi et d'aller piocher ses infos dedans. Après, ça dépend sûrement des jeux, mais pour ceux que je vois passer ici (et pour 99% des sites du web environ), c'est largement suffisant, fiable et simple.
Non, juste non. Pour avoir bossé sur une appli ou le DOM était utilisé pour stocker l'état de la page, à base d'attributs foireux, d'input hidden ou de formulaires complets masqués, quand le DOM fait foi c'est généralement dégueulasse : les mecs stockaient les arrays sous forme de listes à virgules, les booléens sous forme de "yes" "no" "trUe/fAlsE", pour des maps c'était plusieurs inputs, etc.
J'ai développé des modules sur cette appli en stockant mes données dans un objet JS et en mettant à jour le DOM en fonction des données, sans avoir à "lire" le DOM.
Et comme par hasard ça prenait 10 fois moins de temps à maintenir, débugger, évoluer ; notamment parce que beaucoup plus court. Et ce, sans aucune dépendance JS hormis quelques helpers MooTools (un jQuery-like qui était présent sur toutes les pages), pas de packages npm, de compilation ou de framework qui dicte comment organiser ton code.
C'est pas un problème de perfs mais d'hygiène, et ça peut se faire nativement. Invoker la lourdeur des frameworks est hors-sujet.
Je me suis simplement inspiré (très largement) de d3js, bien avant que Facebook sorte Flux et prétende l'avoir inventé
Alors oui les autres devs n'étaient pas très bons (sans me la péter) et auraient pu mieux faire tout en gardant le DOM comme stockage de l'état, mais pour moi ça reste une solution simpliste. Par exemple quand tu as des données que tu ne veux pas représenter tu vas commencer à mettre des display none, des input hidden, ce genre de trucs, c'est vraiment moche.