IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

nothus

[Actualité] Halte au JSON et aux frameworks : vive les transformations XML pour les sites !

Noter ce billet
par , 28/02/2018 à 15h32 (3039 Affichages)
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 ?

Envoyer le billet « Halte au JSON et aux frameworks : vive les transformations XML pour les sites ! » dans le blog Viadeo Envoyer le billet « Halte au JSON et aux frameworks : vive les transformations XML pour les sites ! » dans le blog Twitter Envoyer le billet « Halte au JSON et aux frameworks : vive les transformations XML pour les sites ! » dans le blog Google Envoyer le billet « Halte au JSON et aux frameworks : vive les transformations XML pour les sites ! » dans le blog Facebook Envoyer le billet « Halte au JSON et aux frameworks : vive les transformations XML pour les sites ! » dans le blog Digg Envoyer le billet « Halte au JSON et aux frameworks : vive les transformations XML pour les sites ! » dans le blog Delicious Envoyer le billet « Halte au JSON et aux frameworks : vive les transformations XML pour les sites ! » dans le blog MySpace Envoyer le billet « Halte au JSON et aux frameworks : vive les transformations XML pour les sites ! » dans le blog Yahoo

Mis à jour 01/03/2018 à 12h08 par ClaudeLELOUP

Catégories
HTML / CSS , Javascript , Développement Web , Programmation

Commentaires

  1. Avatar de blbird
    • |
    • permalink
    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.
  2. Avatar de Nothus
    • |
    • permalink
    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
    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.
  3. Avatar de Lcf.vs
    • |
    • permalink
    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é
  4. Avatar de stailer
    • |
    • permalink
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    { 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 - Visualiser dans une fenêtre à part
    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.
  5. Avatar de eclesia
    • |
    • permalink
    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...

  6. Avatar de psychadelic
    • |
    • permalink
    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é
  7. Avatar de Nothus
    • |
    • permalink
    (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
    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é
  8. Avatar de Nothus
    • |
    • permalink
    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
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    { 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 - Visualiser dans une fenêtre à part
    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.
  9. Avatar de Nothus
    • |
    • permalink
    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
    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...

  10. Avatar de Nothus
    • |
    • permalink
    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
    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é
  11. Avatar de Lcf.vs
    • |
    • permalink
    Citation Envoyé par Nothus
    (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.
    L'aspect énergétique n'est pas le seul, certes, mais il devrait primer sur l'économique. Sérieusement, si ton projet, quelle qu'en soit sa taille, commence à faire ramer ton serveur, optimise et change/ajoute de(s) serveur(s), ça a un coût anecdotique par rapport à ce que ça rapporte et par rapport à l'économie que tes utilisateurs feront.

    Citation Envoyé par Nothus
    (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 ?
    En fait, la notion de fragments, j'en use et abuse... mais pas en embarqué, directement dans la page (en display none ou en templates), cela alourdit les pages en question, même si l'utilisateur n'en a pas besoin, cela nuit au référencement et cela peut poser des problèmes de cache utilisateur.

    À la place, je laisse le serveur fournir ces fragments, tout en lui laissant le contrôle du comportement du site ou de l'application, car le déportage vers le poste client pose un autre problème : la segmentation de l'intelligence logicielle.

    Citation Envoyé par Nothus
    (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.
    Sur l'aspect des performances, je ne parlais que de celles de build/parsing de la structure.

    Citation Envoyé par Nothus
    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...
    Revenons encore à plus simple : éviter de sérialiser des objets... zieute les démos et sources de démos d'anticore, tu verras la légèreté et la simplicité du développement front, le tout, sans charger un dinosaure obèse du genre de jquery, même si un jour anticore devenait une bibliothèque pesant des To de données... ton dist ne contient que ce que tu utilises réellement.
  12. Avatar de stailer
    • |
    • permalink
    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 défaut non mais tu trouveras facilement des librairies JS capables d'imiter notamment Linq de .net pour faire du requêtage sur des objets JSON. Et là c'est beaucoup plus simple et puissant que du querySelector.

    Exemple : https://github.com/neuecc/linq.js
  13. Avatar de Jitou
    • |
    • permalink
    Malheureusement les applications web ne sont pas encore rentrées dans l'ère moderne. Il y a 20 ans j'étais persuadé que le javascript serait mort et enterré et que des langages modernes associés à de véritables API orientées composant verrai le jour pour construire nos future application web et ... je me suis trompé !

    Pourquoi 20 ans plus tard est ton encore à chercher comment coder un bête tableau navigable et triable ? Pourquoi chercher encore certains composants de base comme les sliders ? Pourquoi faire du routage de page est encore aussi compliqué ? etc ... Faire une appli web consiste encore à faire de la cuisine et le plus souvent a faire fonctionner des composants non standards qui reposent parfois sur des technologie concurrentes. Je me rappelle au siècle précedent ou débutant sous Lotus Notes et Java je ne me posait pas toutes ces questions car j'avais a disposition toutes la richesse des composants de la plateforme pour faire à la fois du client serveur ou du web. Toute l’énergie était alors dédiée pour implementation du métier au coeur de l'application et non la mise au point des composants de base.

    La conséquence est que le coût des projets a explosé alors que la complexité des IHM n'a quasiment pas progressé.
  14. Avatar de Jitou
    • |
    • permalink
    Malheureusement les applications web ne sont pas encore rentrées dans l'ère moderne. Il y a 20 ans j'étais persuadé que le javascript serait mort et enterré et que des langages modernes associés à de véritables API orientées composant verrai le jour pour construire nos future application web et ... je me suis trompé !

    Pourquoi 20 ans plus tard est ton encore à chercher comment coder un bête tableau navigable et triable ? Pourquoi chercher encore certains composants de base comme les sliders ? Pourquoi faire du routage de page est encore aussi compliqué ? etc ... Faire une appli web consiste encore à faire de la cuisine et le plus souvent a faire fonctionner des composants non standards qui reposent parfois sur des technologie concurrentes. Je me rappelle au siècle précedent ou débutant sous Lotus Notes et Java je ne me posait pas toutes ces questions car j'avais a disposition toutes la richesse des composants de la plateforme pour faire à la fois du client serveur ou du web. Toute l’énergie était alors dédiée pour implementation du métier au coeur de l'application et non la mise au point des composants de base.

    La conséquence est que le coût des projets a explosé alors que la complexité des IHM n'a quasiment pas progressé.
  15. Avatar de Nothus
    • |
    • permalink
    Pour ceux qui sont intéressés, j'ai continué mes "recherches" afin de prendre en compte vos différents retours et me remettre en question... question de caractère !

    Pour ceux qui répugnent au XML par sa nature, pas grand chose à faire : une question de goût et d'opportunités.

    Pour ceux par contre qui y trouvent davantage de défauts que de qualité et n'y sont pas totalement réfractaires, un article sur les avancées XSLT 2 et 3 est disponible et très accessible :
    https://www.xml.com/articles/2017/02...using-xslt-30/

    Le nombre de fonctions désormais nativement supportés en très forte augmentation, l'approfondissement de certains concepts (multi-arborescences, transformation depuis et vers CSV ou JSON, etc), ainsi que l'amélioration globale des performances devraient retenir notre attention.

    A la suite de nos échanges et de mes lectures, je reste persuadé que XSL pourrait devenir à la longue un langage de pré-processing pour le gabarit et les opérations de base dans certains contextes très courants...

    Merci à tous !
  16. Avatar de SylvainPV
    • |
    • permalink
    Je ne comprends pas bien l'intérêt du débat XML vs JSON. Quand il s'agit de structure de document, on utilise toujours HTML ou autre langage de balisage parce qu'ils sont conçus pour. Et quand il s'agit de données, on utilise JSON parce que c'est plus léger et plus facile à parser en JS.

    Bien sûr que XML est verbeux : à proportion égale, il contient bien plus de données
    Je ne saisis pas bien ce que tu veux dire par "à proportion égale", mais gageons que pour une même structure de données, sa représentation en JSON sera toujours plus légère que sa représentation en XML. Je veux bien qu'on me montre un contre-exemple.

    @Lcf.js: je pense au contraire que le généré côté client présente un avantage énergétique. La migration d'une appli utilisant des JSP vers une single page app et API REST s'est traduite par une grosse diminution du trafic réseau. Comme les vues et la logique sont complètement décorélées des données, on peut les mettre en cache plus longtemps et plus efficacement. Seules les données circulent sur le réseau et sous la forme la plus légère possible. Certes les vues sont générées côté client et JavaScript consomme un peu, mais les échanges réseau consomment encore plus sur un mobile. Et c'est sans compter les gains sur toute la chaîne du client jusqu'au serveur, qui mis bout à bout doivent compter beaucoup également. En revanche, un site statique sera effectivement moins énergivore si on met en cache les pages complètes. Mais faire un site statique avec un framework JS, c'est aussi gâcher l'énergie du développeur
  17. Avatar de Nothus
    • |
    • permalink
    Quand tu as une valeur JSON, tu la lis facilement et celle-ci peut contenir d'autres valeurs. En gros, un document JSON, c'est un tableau - ou dictionnaire, ou marginalement une string seule -, qui contient d'autres valeurs, etc.

    Pour rejoindre l'aspect XML et par convention (j'insiste là dessus : une convention dépend de l'implémentation), tu indiques que telle clé va contenir des attributs et le reste est l'arborescence. Ainsi pour chaque élément, c'est une cascade de tableaux :

    Code json : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    {"arbre": { 
    "_att" : { "id": "truc", "style": "yenapas" }, 
    "item1": { "_att" : { "id": "machin", "style": "yenatoujourspas" }, 
    ...
    }}

    Sur une page complète, tu aurais donc l'imbrication de dizaines de tableau les uns dans les autres. Pour du gabarit de site (qu'est l'objet de l'article initialement), et encore une fois non pas pour passer une variable à la volée ou du texte, ou quelques choses qui ne soit pas une arborescence complexe, XML est davantage adapté que JSON. Quand aux attributs, XML les gère nativement et donc tu n'as pas à te soucier d'avoir des clés différentes pour les stocer en fonction de l'outil utilisé : le XML cadre ces sujets nativement.

    Pour une arborescence complexe, c'est plus simple à lire (à mon sens j'en conviens) et à maintenir quelque chose de léger :

    Code xml : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    <arbre id="truc" style="yenapas"> 
    <item id="machin" style="yenatoujourspas" /> 
    ...
    </arbre>

    Le problème a été de confondre à mon sens le transport de données simples - où est plus performant JSON - à des données d'arborescence complexe, dont hérite le DOM du navigateur. Je ne dis pas que XML est supérieur partout, mais pour une structure de page web, c'est tout de même le plus adapté car le plus proche de ce qui sera fait.

    De fait les transformations XSL sur le XML découle de ce constat (traiter du XML par l'outil le plus adapté pour générer un HTML) et XSL est géré par du binaire sur une navigateur -> c'est infiniment plus rapide que de charger un JS qui va traiter du JSON. D'où ma remarque initiale sur WebAssembly, qui vient virer JS qui est particulièrement lent (d'où son orientation de plus en plus asynchrone pour résoudre la problématique de performance) pour la suite de ce que saurait être le web.

    Je ne sais pas si je suis plus clair mais j'ai essayé

    Citation Envoyé par SylvainPV
    Je ne comprends pas bien l'intérêt du débat XML vs JSON. Quand il s'agit de structure de document, on utilise toujours HTML ou autre langage de balisage parce qu'ils sont conçus pour. Et quand il s'agit de données, on utilise JSON parce que c'est plus léger et plus facile à parser en JS.


    Je ne saisis pas bien ce que tu veux dire par "à proportion égale", mais gageons que pour une même structure de données, sa représentation en JSON sera toujours plus légère que sa représentation en XML. Je veux bien qu'on me montre un contre-exemple.

    @Lcf.js: je pense au contraire que le généré côté client présente un avantage énergétique. La migration d'une appli utilisant des JSP vers une single page app et API REST s'est traduite par une grosse diminution du trafic réseau. Comme les vues et la logique sont complètement décorélées des données, on peut les mettre en cache plus longtemps et plus efficacement. Seules les données circulent sur le réseau et sous la forme la plus légère possible. Certes les vues sont générées côté client et JavaScript consomme un peu, mais les échanges réseau consomment encore plus sur un mobile. Et c'est sans compter les gains sur toute la chaîne du client jusqu'au serveur, qui mis bout à bout doivent compter beaucoup également. En revanche, un site statique sera effectivement moins énergivore si on met en cache les pages complètes. Mais faire un site statique avec un framework JS, c'est aussi gâcher l'énergie du développeur
  18. Avatar de Nothus
    • |
    • permalink
    L'objet de l'article était de faire le lien entre XSL/XML et framework JS/JSON justement. Je ne crois pas que ça soit si "clair" parfois, notamment lorsque je vois l'orientation de Vue.js justement, où les transformations sont faites côté client en JS. Quant aux autres framework, notamment l'utilisation d'un DOM virtuel, cela me semble justement fantastiquement compliqué pour pas grand chose. Et finalement pas très efficace.

    Derrière, c'est bien la question de la pertinence des outils qui se posent.

    Effectivement les commentaires se recoupent mais il restait quelques incompréhensions...

    Citation Envoyé par SylvainPV
    Mais tout le monde est d'accord avec toi: pour du gabarit de site, du template, de la structure du document, on utilise encore et toujours du HTML ou d'autres langages dérivés du XML. Rien n'a changé avec les frameworks JavaScript modernes, même JSX peut être considéré comme un dérivé de XML à la limite. Utiliser JSON ou une structure JS pour ça, à la manière de domjs, est complètement marginal et pas pratique du tout.

    En revanche, ça fait longtemps que JSON a remplacé XML dans le transit de données pures. Historiquement le X de AJAX est pour XML mais dans les faits, c'est du JSON qui circule en AJAX la plupart du temps. C'est normal, toutes les web app modernes manipulent les données en JS pour composer les vues côté client ; et JSON est bien plus facile à parser et manipuler en JS qu'un arbre XML.

    C'est pour ça que je ne comprends pas le débat, les deux langages coexistent et sont à leur place naturelle depuis des années. Les frameworks n'ont pas changé cet état de fait.