JavaScript : faut-il privilégier les transformations XML à JSON et aux Frameworks ?
Partagez vos avis

Le , par Nothus, Membre confirmé
N.B. Cet article est en partie un billet « d'humeur », destiné à provoquer le débat et n’est pas dénué de second degré et est donc réservé à ceux qui en disposent. Si par ailleurs vous connaissez déjà des déploiements pour le type d’orientation que je développe, merci de me l'indiquer en commentaire par un lien, ça m’intéresse. D’avance merci



Vous êtes à l’affût des dernières tendances de Vue.js ? Vous êtes incollable sur Angular ? Vous trouvez que vraiment, les applications XML c’est juste bon pour de vieux engins et quelques rares applications métier ? Le JSON est votre meilleur ami ?

À tort ! Les frameworks JavaScript c’est le mal – ou au moins l’utilisation bien souvent abusive des jQuery et autres ReactJS… Et le JSON – pardonnez-moi par avance si je heurte votre intelligence et vos pratiques – c’est gentil, mais c’est juste pour gérer quelques variables simples : un vrai jouet pour bambins.



Spoiler : j’en rajoute (beaucoup) dans mon introduction certes. Pour autant le propos de fond n’est pas éloigné de ma pensée et il y a parfois confusion entre les possibles et l’intérêt des outils entre eux.
Ainsi lorsque je vois un code avec du HTML « formaté » en JSON et dans l’attente d’être généré, je me dis que le monde est moche, vraiment. Car JSON est l’équivalent d’un dictionnaire : une paire clé/valeur. Pas d’attributs. Un manque, car vous devez passer du moins riche au plus riche en termes de données. Les astuces, avec l’utilisation de clés particulières renvoyant à des objets faisant office d’attributs, restent crades et peu pratiques (soyez de bonne foi !).

Alors pourquoi ne pas directement utiliser du XML dont hérite le HTML fut-il de version 4 ou 5... ? D’où vient cette manie de séparer la richesse du XML de nos si chères pages Web ? Une Web Application est-elle condamnée à (virtuellement) ne pas les utiliser ?!

Ne touche-t-on plutôt pas ici aux pratiques des développeurs, aux modes et à – peut-être – une forme de paresse, voire de méconnaissance de certains développeurs web qui ne jurent que par les plaquettes com’ de certaines firmes et écoles ? Je crois sincèrement l’heure venue d’avoir un débat, car, progressivement, les choses se décantent pour le web, son inusable JS et indirectement pour la pratique du XML sur le Web.

Tout d’abord un tour d’horizon de ce qu’apportent les Workers au doux et riche monde du XML, à l’heure où, pour le monde du Web mutualisé dans les grands opérateurs d’hébergement, le PHP devient ringard, dépassé et NodeJS toujours aussi instable… en nous demandant si parfois, l’orientation de pages disponibles hors ligne – base des applications Web – n’était pas la pierre qui manquait dans le mur du XML moderne.

Ce qui change tout : les Workers

Vous connaissez cette astuce qui prévoit de mettre du HTML dans une balise style au sein de votre body ? Une fois récupéré par le biais d’un querySelector, mais jamais pris en compte dans le HTML de la page, cela permet de faire des transformations locales (replace + parse) puis de réintégrer les éléments générés dans une page.

Plus propre qu’un display : none, la pratique séduit par sa relative réutilisation – pour la génération de listes complexes par exemple.

Pour autant le web se heurte à plusieurs inconnues/problématiques majeures qui dominent toujours les forums et nos pensées. En voici un résumé très personnel :
– la séparation données/présentation ou comment le JS s’est orienté vers MCV à défaut de pouvoir parfois continuer à générer des pages « toutes prêtes » et personnalisées côté serveur ;
– l’organisation de la page elle-même : représenter du HTML et sa richesse (attributs notamment) autrement que par du HTML, ce n’est pas si facile (et propre). Sauf si l’on utilise son parent le XML ;
– disposer d’un DOM facilement manipulable avant qu’il soit disponible et affiché par le navigateur, pour disposer des écouteurs d’événements ou faire des manipulations diverses et variées. Cela donnera, pour le cas de rafraîchissements très fréquents (et très bloquants pour l’usage de la page…), le cas des DOM virtuels. Des DOM virtuels qui doivent être plutôt détachés de l’exécution de la page elle-même, pour éviter d’être bloquants par effet de bord.

C’est là où intervient un nouveau venu : un travailleur JS. Corvéable à merci, il est un parfait esclave de nos exigences numériques (rien de répréhensible hein !).

Les Workers disposent de trois principales familles (voir ici et ici), héritées d’un même prototype d’objet et disponible par JavaScript. Tout d'abord un Web Worker de base (d’où le nom de Web Worker) simple et efficace, limité à la page qui l’appelle, qui dialogue avec elle et ne dispose pas d’accès au DOM du document. Pour du calcul bloquant, ou gérer certains appels, c’est parfait. C’est un « processus » à la sauce thread en Python par exemple.

Le Worker « au-dessus », c’est la même chose, mais il peut être partagé avec d’autres fenêtres/onglets : le Shared Worker. Une forme de multiprocessing dont les pipes sont limités en accès et qui répond toujours au domaine appelant (limitations CORS), et tourne en fond de tâche tant qu’il n’est pas tué ou qu’il reste au moins un onglet ouvert quelque part et qui fait appel à lui.

Enfin il y a le Service Worker, qui lui aussi répond à un domaine appelant (même s’il peut, sous condition et avec pas mal de restrictions, faire appel à des ressources hors des limites théoriques du CORS). La différence notable c’est qu’il ne tourne pas en fond de tâche : il est appelé pour un temps court (et sera tué s’il ne respecte pas certaines règles de bienséance numérique), pour « traiter » un lien appelé par une page. Il existe en dehors de l’existence des pages (sa création le rend indépendant des pages présentes et futures). Il a accès et lui seul, à un espace réservé qui est un cache local, pouvant charger moult fichiers en tout genre (CSS, JS, images, textes, HTML, JSON, XML, MP4, ZIP, que sais-je…). En interceptant les requêtes, il peut les modifier (un peu) et répondre par autre chose s’il le veut (souvent).

L’intérêt c’est qu’il peut servir de « préserveur » en stockant localement des fichiers. Ceux-ci peuvent être disponibles de lui seul (le fameux cache local) ou au travers d’IndexedDB (le pire truc que la terre ait jamais enfanté depuis le comportement effroyable de mon ex-voisine du haut). Il peut aussi servir du HTML généré… ou du XML…

Et si c’est trop lourd à transformer, un Shared Worker ou un Web Worker peuvent traiter des tâches pour lui…

Et une requête POST (sur une URL fantôme, interceptée, type /void) a un corps de requête qui peut contenir des données à mettre en cache pour resservir après…

Hum hum…

La trame que je propose (attention, étape aspirine)

De ces réflexions que je travaille ces deux dernières semaines, en voici le schéma général :
– réception de la requête par le serveur, en fonction de règles de redirection ;
– importation d’un premier XML, transformé par un XSL, produisant un code HTML5 valide → un cadre global adapté ;
– le navigateur exécute la page HTML produite et le JavaScript contenu inscrit un Service Worker qui procède dès que possible au téléchargement de tous les XSL disponibles en les intégrant dans une base locale, qui gérera par ailleurs les appels directs vers le serveur (le cache est une sorte préAPI de redirection) ;
– toute nouvelle ressource appelée par le biais d’un lien (renvoyant vers un XML) passera par le cache au travers du Shared Worker (SW) sans nouvel appel au serveur pour les XSL (étant déjà disponibles en cache). Ce ne sera donc pas directement la page qui procède à la transformation, mais un SW, qui communiquera le cas échéant au cache une ressource transformée à garder pour la suite (requête interceptée POST) ;
– les transformations par JavaScript permettent de ne pas avoir à rafraîchir toute une page, en modifiant à la volée certaines parties du HTML produit par la transformation. Soit le parcours suivant : appel de la page vers le SW => le SW fait une demande éventuelle auprès du cache => le cache vérifie s’il doit le télécharger => le SW fait éventuellement les transformations nécessaires de la réponse du cache et renvoie à la page le résultat => le JS de la page dispose d’un nouveau document – fragment – où piocher les éléments DOM à intégrer (remove simple ou par clone).

… Vous trouvez mon orientation, ma trame un poil compliquée ? Avez-vous déjà vu le fonctionnement théorique d’un DOM virtuel ? Le casse-tête des appels asynchrones que les Promises tendent de résoudre, des problématiques de portée de variables ? La sécurité des sessions pour des requêtes HTTP nécessairement stateless à l’heure où augmente le nombre de scripts extérieurs au site… ?

Si vous n’êtes toujours pas convaincu que cette solution n’est pas ni la pire ni la plus complexe au regard de toutes les autres (Churchill…) et répond à certaines problématiques bien actuelles, je vous conseille de lire rapidement la documentation d’implémentation du WebAssembly – particulièrement si vous n’avez jamais développé avec des langages de plus bas niveau… voilà ce qui vous attend.

Bref.

Dans la trame que je présente, le serveur distant pour la « lecture » seule des données se comporte comme un simple fournisseur de fichiers. Évidemment cela ne vaut pas dans deux cas non exclusifs l’un de l’autre :
– pour l’enregistrement des logs qui se fait également lors de l’appel des ressources indépendamment du logiciel de serveur (par exemple, avoir d’autres logs que seulement ceux d’Apache, Lighttpd, etc.) ;
– pour la vérification des droits d’accès au XSL/XML/… ou de certaines mises à jour (mon XML est-il à jour ?).

Un tel schéma d’échanges de XML/XSL est bien évidemment compatible côté serveur avec des bases NoSQL – particulièrement celles qui ont des orientations documents ou tous les systèmes distribués en règle générale –, mais plus surprenant (inusité ?), aussi avec certains systèmes SQL comme MariaDB qui supporte des colonnes au format texte/XML (au travers de fonctions disponibles telles que ExtractValue ou UpdateXML).

Quelques limitations cependant : si le site dispose de nombreux XSL ou que les données sont variées en structure, le cache localement peut être important, voire difficile à « résolver » (résoudre) totalement côté serveur. Cependant même pour des sites aussi « lourds » que peuvent être par exemple ceux des GAFA, la rationalisation des éléments affichés peut produire des portions de XSL faciles à maintenir et à intégrer dans une page (principe des gabarits/« template »).

Quand utiliser les uns ou les autres ?

Une conclusion en ouverture : quand savoir raisonnablement utiliser les différentes technologies utiles à votre projet et à vos ambitions ? Tout d’abord savoir où vous êtes à l’aise : le débogage, les vérifications de sécurité sont toujours plus simples, moins fastidieux, plus efficaces lorsque les outils utilisés sont connus. Le développement lui-même est plus aisé et rapide – ce qui réduit de manière non négligeable le coût.

Le schéma que je propose ici est particulièrement adapté lorsque le niveau d’exigence en termes de rafraîchissement reste raisonnable et que les transformations XSL sont correctement développées, comprises, gérables. De plus cela ne résout pas le problème de mise à jour « permanente » du contenu, des événements (scroll, etc.) comme du feed-back plus généralement : dans ce cas, l’utilisation de JS et des facilités offertes par les frameworks est particulièrement évidente et totalement indéniable. Bref pas le choix !

Pour un site « Internet » ou en intranet, qui se rapproche d’une utilisation type blog ou wiki, qui reste « relativement » statique, la « gabarisation » – car c’en est une – grâce à XML est probablement la meilleure approche (la moins coûteuse en termes de matériel, particulièrement si vous êtes sur des serveurs mutualisés où la ressource logicielle est rare). Idem si vous disposez déjà de ressources XML considérables (ouvrages, fichiers de configuration, de données, génération provenant des capteurs, etc.).

Reste qu’une telle méthodologie, approche, orientation – appelez cela comme vous le souhaitez – est compatible avec d’autres pratiques récentes comme les JSON Web Token (JWT), dont vous trouverez d’excellents exposés un peu partout –, et son orientation plus « tendance » et sécurisée (et disponible) que nos éternels cookies de session, qui obligent à un load balancer très efficace ou un cache de sessions distribué lorsque l’on dépasse un unique serveur.

Preuve que la modération et l’ouverture d’esprit dans le domaine technique comme dans d’autres, est souvent la meilleure manière d’être le plus efficient : XML+XSL représente, transforme et organise des données complexes ; le couple JS+JSON traite des variables, des appels et des requêtes désormais majoritairement de manière asynchrone.

Chacun chez soi et Linux pour tous.

Et vous ?

Qu'en pensez-vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster un commentaire

Avatar de blbird blbird - Membre éprouvé https://www.developpez.com
le 01/03/2018 à 13:35
Le JSON et le XSL n'ont pas grand chose en commun.

Pour ma part, en ayant fait beaucoup, le XSL est à bannir depuis de nombreuses années : c'est une techno verbeuse, totalement illisible dès qu'on dépassé les quelques dizaines de lignes, aucune possibilité de débogage.

De la même manière, hormis pour décrire un DOM, je privilégié largement le JSON au XML pour le transport de données vers des sites Web. Dans l'écrasante majorité des cas, si ce n'est tous, pas besoin de décrire les données qu'on transporte, une structure claire suffit : économie de taille, de temps de traitement, et même de lisibilité.

Alors de là à combiner XML et XSL pour générer des sites Web, l'ayant déjà expérimenté aussi, je le déconseille fortement. Très très mauvaise expérience sur ces technos.

Je ne vois pas comment on peut conseiller de revenir en arrière sous prétexte que certains utilisent des technologies plus récentes plus ou moins incorrectement.

VUEJS est une des toutes meilleurs techno JS du moment, je le conseille par contre fortement.
Avatar de Nothus Nothus - Membre confirmé https://www.developpez.com
le 01/03/2018 à 18:22
J'insiste : comparer JSON et XML pour "confectionner des pages" n'a pas de sens car la finesse dans l'information n'est pas égale. Quand tu parles de structures claires, je te rejoins : sous JSON, ça reste une clé arbitraire comme une autre. L'un va prendre telle clé, un autre une autre.

Je ne nie pas que le JSON peut avoir du sens, mais pas pour construire une page, pour donner sa structure. L'intégration de XML, de ses transformations est natif aux navigateurs. JSON est hérité parce que JS le supporte et que le JS est l'habitude d'usage sur les pages.

Bien sûr que XML est verbeux : à proportion égale, il contient bien plus de données. Quand au débuggage, tu n'as pas plus de difficultés que du JSON où il y aura un caractère manquant. Les logiciels dédiés, s'ils sont bien fichus, indiquent les fautes de grammaire en plus des fautes de syntaxe. Et est-ce si "grave" d'avoir une grammaire respectée ? Ne souffre t-on pas justement d'avoir parfois du HTML qui prend un peu tout et n'importe quoi, qui reste souvent très (trop) laxiste ? Au point que chacun fait son petit hack, à tous les niveaux ?

Sur le transport : change ton API, tu es bon pour garder des anciennes versions le temps d'une migration. L'aspect positif du verbeux, c'est qu'il est aussi compréhensible par l'humain. Que le XML "syntaxique" - c'est-à-dire sans grammaire derrière pour le formalisme de l’arborescence, est parfaitement lisible.

Tu parles de revenir en arrière : je te propose au contraire de comprendre pourquoi on ne sort pas du HTML pour "créer" du Web et pourquoi le HTML est tellement associé au XML.

Quant aux technos, j'en rajoute une fois encore, mais pour la création de page où la plupart du temps et des sites, la page est "statique", c'est vraiment le marteau pour une vis à mon sens.

Citation Envoyé par blbird Voir le message
Le JSON et le XSL n'ont pas grand chose en commun.

Pour ma part, en ayant fait beaucoup, le XSL est à bannir depuis de nombreuses années : c'est une techno verbeuse, totalement illisible dès qu'on dépassé les quelques dizaines de lignes, aucune possibilité de débogage.

De la même manière, hormis pour décrire un DOM, je privilégié largement le JSON au XML pour le transport de données vers des sites Web. Dans l'écrasante majorité des cas, si ce n'est tous, pas besoin de décrire les données qu'on transporte, une structure claire suffit : économie de taille, de temps de traitement, et même de lisibilité.

Alors de là à combiner XML et XSL pour générer des sites Web, l'ayant déjà expérimenté aussi, je le déconseille fortement. Très très mauvaise expérience sur ces technos.

Je ne vois pas comment on peut conseiller de revenir en arrière sous prétexte que certains utilisent des technologies plus récentes plus ou moins incorrectement.

VUEJS est une des toutes meilleurs techno JS du moment, je le conseille par contre fortement.
Avatar de Lcf.vs Lcf.vs - Membre averti https://www.developpez.com
le 01/03/2018 à 19:44
Le JSON a un avantage indéniable sur le XML, les performances !

Par contre, quelle que soit la méthode, dès que c'est du généré côté client, cela a un coût énergétique astronomique !

En effet, chaque utilisateur va utiliser de l'énergie pour générer chaque noeud, sans bénéficier de cache serveur, ni cache navigateur.

En revanche, le stateless côté client n'a pas trop de sens.

C'est pourquoi dans ma suite de frameworks, j'ai un webservice (avec qui j'interagis en JSON ou en XML, selon un header) et en façades de ce webservice, j'ai des serveurs de rendu qui, eux, s'occupent de la gestion de vraies sessions (liées à un stateless token), du cache, etc.

Côté client, en JS, je ne fais donc que recevoir des éléments HTML que j'ajoute ou qui en remplacent d'autre, écouter des évènements, ajouter de l'interactivité (UX).

J'étais pourtant un grand fan inconditionnel du tout généré, côté client, il y a près de 10 ans, mais depuis que j'me suis rendu compte des inconvénients, surtout énergétiques, j'en suis revenu.

Puis j'ai imaginé mon anticore et ça a tout simplifié
Avatar de stailer stailer - Membre chevronné https://www.developpez.com
le 01/03/2018 à 20:08
J'ai pas lu tout l'article mais au sujet des attributs XML, et pour répondre à la question :

Alors pourquoi ne pas directement utiliser du XML dont hérite le HTML fut-il de version 4 ou 5... ?
Réponse :

Tout simplement car la plupart du temps le résultat JSON correspond à un objet côté code (classe PHP, C#, JS.. etc).
Une structure de classe, en dehors de ses méthodes et constantes, contient : des propriétés à typage simple, complexe ou des tableaux d'autres objets.

Donc : le XML à travers ses attributs rend complexe la chose. En .net pas de souci, les [XmlAttribute] fournis permettent de dire si c'est l'élément ou l'attribut qui correspond à une propriété de classe donnée... Mais pas forcément aussi simplement dans d'autres langages... Et dans tous les cas ça n'est pas vraiment pratique. Les éléments XML sont pénibles à lire..

Exemple :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
<monTableau>
   <monItem>
        <monNom>moi</monNom>
       <monElement>28</monElement>
   </monItem>
  <monItem>
       <monNom>toi</monNom>
       <monElement>12</monElement>
   </monItem>
</monTableau>
Sera quoi qu'on en dise toujours plus pénible que :

Code : Sélectionner tout
1
2
{ monTableau : [
     { monNom : "toi" , monElement : 28 },
     { monNom : "moi" , monElement : 12 },
]}
A noter aussi que pour un appel HTTP le flux JSON sera plus petit et donc performant qu'un flux XML.

Pour le reste.. A chacun sa façon de voir les choses et de coder quand il a la chance de pouvoir décider

PS : comme je le sens arriver, oui je sais qu'on pouvait faire :

Code : Sélectionner tout
1
2
3
4
5
<monTableau>
   <monItem monNom="moi" monElement="28" />
    <monItem monNom="toi" monElement="12" />
</monTableau>
C'est un peu plus simple en effet... Mais seules des types très simples seront "stockables" de cette manière. Après il faudra passer par l'élément et mixer les 2 méthodes.. Pas sûr que ce soit très propre au final.
Avatar de eclesia eclesia - Rédacteur https://www.developpez.com
le 01/03/2018 à 20:53
Puisse que le ton est au lacher prise, j'offre mon point de vue.

Le Web d'aujourd'hui, que ce soit JSON ou XML/HTML est comme un tracteur, des couches par dessus des couches et encore des couches.
Plus les PC vont vite et ont de la mémoire et plus on en rajoute !
50-100Mo par onglet pour afficher meme une bete page static, c'est n'importe quoi.
Les specs HTML/CSS/WebSocket/etc... sont monstrueuses, nombreuses constament changeantes et bonnes a jeter.

Il faut redescendre plus bas dans les strates, fournir des API simples pour faire des vrai programmes pas des bidouilles, car oui il faut le dire le web dynamique c'est de la bidouille.

La direction a prendre est celle de Zebkit : http://repo.zebkit.org/latest/samples/uidemo.html
On s'appuie sur une API de dessin type Canvas ou OpenVG et on dessine, fin de l'histoire.
Libre a ceux qui aime JSON ou XML de faire leur bibliotheques de widget avec l'un ou l'autre.
Fini HTML, fini CSS, fini Javascript, du bytecode (type webassembly++) et des API, bref une VM.

Combien de temps encore va-t-on encore trainer tous ce foutoir...

Avatar de psychadelic psychadelic - Membre émérite https://www.developpez.com
le 02/03/2018 à 4:45
Pour ce que ça vaut...
XML / XSL, j'en ai soupé; c a été une sorte de rêve fantasmé d'une informatique de partage, etc, et c'est en fait un vrai cauchemar.

JSON,, ben c'est pas les mêmes ambitions, déjà, à utiliser pour des infos utiles, des micro_format à la limite.

Mais maintenant, je commence à lorgner du coté de YAML, question de lisibilité
Avatar de Nothus Nothus - Membre confirmé https://www.developpez.com
le 02/03/2018 à 11:33
(1) Effectivement, le coût est astronomique en terme énergétique pour le rendu du code. Cela dit, en termes économiques car c'est par eux que le monde est monde quoiqu'on en pense :
- "petit" projet : mieux vaut faire "ramer" un téléphone portable de client que d'encombrer mon serveur mutualisé ;
- "gros" projet : un miliseconde de gagnée côté client c'est +200 clients / heures dans le monde, alors je rajoute X serveurs / RAM / trucs divers.

-> la question du coût est étroitement liée à celle du projet. Le curseur n'est pas toujours tout client ou tout serveur.

(2) C'est marrant parce que ta solution ressemble (prisme déformant de ma part ?) à ce que j'évoque : la différence c'est que désormais un pré-cache ou un cache local - peu importe son nom - existe en Javascript et qu'il peut servir avec les Workers pour traiter et fournir une forme de service de rendu local. Afin d'éviter tout le re-calcul justement et les va-et-viens vers le serveur. C'est ma notion de "fragment" de l'article, pour ensuite remplacer ça et là dans la page actuelle ou future des portions du DOM. Qu'en penses-tu ?

(3) Sur les performances JSON/XML, je suis moins convaincu. Parce que JSON pour produire un code HTML correct, a quand même besoin d'un framework qui tourne bien. XML et ses transformations, c'est natif -> on passe d'une logiciel de développement projet à celui de l'utilisation des ressources propres et bien plus rapide (C/C++, etc) du navigateur.

Citation Envoyé par Lcf.vs Voir le message
Le JSON a un avantage indéniable sur le XML, les performances !

Par contre, quelle que soit la méthode, dès que c'est du généré côté client, cela a un coût énergétique astronomique !

En effet, chaque utilisateur va utiliser de l'énergie pour générer chaque noeud, sans bénéficier de cache serveur, ni cache navigateur.

En revanche, le stateless côté client n'a pas trop de sens.

C'est pourquoi dans ma suite de frameworks, j'ai un webservice (avec qui j'interagis en JSON ou en XML, selon un header) et en façades de ce webservice, j'ai des serveurs de rendu qui, eux, s'occupent de la gestion de vraies sessions (liées à un stateless token), du cache, etc.

Côté client, en JS, je ne fais donc que recevoir des éléments HTML que j'ajoute ou qui en remplacent d'autre, écouter des évènements, ajouter de l'interactivité (UX).

J'étais pourtant un grand fan inconditionnel du tout généré, côté client, il y a près de 10 ans, mais depuis que j'me suis rendu compte des inconvénients, surtout énergétiques, j'en suis revenu.

Puis j'ai imaginé mon anticore et ça a tout simplifié
Avatar de Nothus Nothus - Membre confirmé https://www.developpez.com
le 02/03/2018 à 11:39
Ton PS est fort à propos effectivement ! Pas la peine de rajouter de la complexité sans nécessité. Pour les objets vraiment pointus, ni JSON ni XML ne seront le plus adapté quoiqu'on fasse : pour moi je mets une limite à ce deux langues de présentation des données à des choses communes (pas de streams, etc). Je reconnais juste à XML une capacité plus fine dans le type de variable stockée (d'où mon insistance sur les attributs) ainsi qu'une utilisation commune des méthodes du DOM (qui sont pas si mal que ça).

En JSON par contre, va recherche facilement un ID particulier dans une arborescence complexe... pas si évident. Il n'y a pas par exemple de querySelector, etc.

Par contre je te rejoins sur la taille (moins sur la lisibilité : question d'habitude, j'ai tendance à lire aussi facilement les deux) : le JSON gagne clairement la partie.

Citation Envoyé par stailer Voir le message
J'ai pas lu tout l'article mais au sujet des attributs XML, et pour répondre à la question :

Réponse :

Tout simplement car la plupart du temps le résultat JSON correspond à un objet côté code (classe PHP, C#, JS.. etc).
Une structure de classe, en dehors de ses méthodes et constantes, contient : des propriétés à typage simple, complexe ou des tableaux d'autres objets.

Donc : le XML à travers ses attributs rend complexe la chose. En .net pas de souci, les [XmlAttribute] fournis permettent de dire si c'est l'élément ou l'attribut qui correspond à une propriété de classe donnée... Mais pas forcément aussi simplement dans d'autres langages... Et dans tous les cas ça n'est pas vraiment pratique. Les éléments XML sont pénibles à lire..

Exemple :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
<monTableau>
   <monItem>
        <monNom>moi</monNom>
       <monElement>28</monElement>
   </monItem>
  <monItem>
       <monNom>toi</monNom>
       <monElement>12</monElement>
   </monItem>
</monTableau>
Sera quoi qu'on en dise toujours plus pénible que :

Code : Sélectionner tout
1
2
{ monTableau : [
     { monNom : "toi" , monElement : 28 },
     { monNom : "moi" , monElement : 12 },
]}
A noter aussi que pour un appel HTTP le flux JSON sera plus petit et donc performant qu'un flux XML.

Pour le reste.. A chacun sa façon de voir les choses et de coder quand il a la chance de pouvoir décider

PS : comme je le sens arriver, oui je sais qu'on pouvait faire :

Code : Sélectionner tout
1
2
3
4
5
<monTableau>
   <monItem monNom="moi" monElement="28" />
    <monItem monNom="toi" monElement="12" />
</monTableau>
C'est un peu plus simple en effet... Mais seules des types très simples seront "stockables" de cette manière. Après il faudra passer par l'élément et mixer les 2 méthodes.. Pas sûr que ce soit très propre au final.
Avatar de Nothus Nothus - Membre confirmé https://www.developpez.com
le 02/03/2018 à 11:47
Complètement d'accord avec toi : c'est la facilité de se dire "aller, j'ai plein de RAM et mes clients aussi, faisons n'importe quoi". La baisse du coût matériel a eu un impact non pas sur la qualité du code - il évolue dans sa pratique et dépend de celui qui l'écrit -, mais sur la superposition des couches que tu évoques.

Je propose justement de revenir à des choses plus simples : sérialiser les objets à afficher, ne pas partir à charger jQuery parce que c'est l'habitude pour quelques petits trucs à faire en JS, éviter de construire des listes complexes en pseudo-JS dans du code HTML qui va demande 100 ko de bibliothèque pour être traité, etc...

Comme on peut se poser l'opportunité des nombreuses, trop nombreuses requêtes et bibliothèques pour le suivi commercial : la lourdeur des pages c'est le combat de nos politiques de sécurité et de confidentialité locale, du peu de cas des développeurs et chargés de projets pour le respect des navigateurs clients ou du suivi au pixel près le curseur de ce même client. Business as usual...

Pour Canvas et autres effectivement, suite logique. Je dirais même que j'attends avec impatient les WebAssembly pour que les WebApp ne soient pas juste "une grosse page disponible hors ligne" et la possibilité d'accès au disque client, à d'autres type de bases de données (jamais compris pourquoi on tapait autant sur WebSQL), etc.

Mais lorsque le rendu se fera majoritairement par là, beaucoup de développeur qui n'ont jamais quitté leur JS adoré vont avoir mal...

Citation Envoyé par eclesia Voir le message
Puisse que le ton est au lacher prise, j'offre mon point de vue.

Le Web d'aujourd'hui, que ce soit JSON ou XML/HTML est comme un tracteur, des couches par dessus des couches et encore des couches.
Plus les PC vont vite et ont de la mémoire et plus on en rajoute !
50-100Mo par onglet pour afficher meme une bete page static, c'est n'importe quoi.
Les specs HTML/CSS/WebSocket/etc... sont monstrueuses, nombreuses constament changeantes et bonnes a jeter.

Il faut redescendre plus bas dans les strates, fournir des API simples pour faire des vrai programmes pas des bidouilles, car oui il faut le dire le web dynamique c'est de la bidouille.

La direction a prendre est celle de Zebkit : http://repo.zebkit.org/latest/samples/uidemo.html
On s'appuie sur une API de dessin type Canvas ou OpenVG et on dessine, fin de l'histoire.
Libre a ceux qui aime JSON ou XML de faire leur bibliotheques de widget avec l'un ou l'autre.
Fini HTML, fini CSS, fini Javascript, du bytecode (type webassembly++) et des API, bref une VM.

Combien de temps encore va-t-on encore trainer tous ce foutoir...

Avatar de Nothus Nothus - Membre confirmé https://www.developpez.com
le 02/03/2018 à 11:51
Je nie pas les inconvénients du XML... je dénonçais un peu le fait qu'on trouve trop souvent que des avantages au JSON, d'une manière parfois déraisonnable.

YAML : ouaip, on approche du meilleur des deux mondes - même si ça reste perfectible.

Citation Envoyé par psychadelic Voir le message
Pour ce que ça vaut...
XML / XSL, j'en ai soupé; c a été une sorte de rêve fantasmé d'une informatique de partage, etc, et c'est en fait un vrai cauchemar.

JSON,, ben c'est pas les mêmes ambitions, déjà, à utiliser pour des infos utiles, des micro_format à la limite.

Mais maintenant, je commence à lorgner du coté de YAML, question de lisibilité
Contacter le responsable de la rubrique JavaScript