Le format XML serait meilleur que JSON pour la mise en page d'interface utilisateur
Selon Adam Stepinski, directeur de l'ingénierie chez Instawork
Le 2019-10-31 13:13:53, par Bill Fassinou, Chroniqueur Actualités
Les formats JSON et XML sont deux des formats de fichiers les plus utilisés dans la programmation. L’un est orienté données (JSON) et l’autre est orienté documents (XML) et ils peuvent tous les deux être utilisés pour recevoir des informations (données) d’un serveur. Selon Adam Stepinski, directeur de l’ingénierie chez Instawork, JSON peut se montrer plus utile et un meilleur choix que XML dans plusieurs domaines, mais s’il y a un domaine dans lequel XML est de loin le meilleur choix, c’est la mise en page des interfaces utilisateurs.
JSON signifie JavaScript Object Notation. C'est un format de fichier standard ouvert utilisé pour les communications navigateur-serveur. C'est un format de données indépendant du langage. XML signifie Extensible Markup Language. XML représente un ensemble de règles qui aident les utilisateurs à coder des documents dans un format lisible par l'homme et par la machine. Pour cette dernière raison, Adam Stepinski, directeur de l’ingénierie chez Instawork et son équipe pensent que le format XML est le meilleur choix dans la conception des interfaces utilisateurs.
Stepinski et son équipe ont développé Hyperview XML (HXML), un nouveau format hypermédia basé sur XML et un client React Native pour le développement d'applications mobiles pilotées par serveur. Hyperview XML est un format hypermédia utilisé pour définir les écrans (interfaces utilisateurs) d'applications mobiles. HXML fournit un ensemble de balises et d'attributs qui permettent de définir la disposition d'un écran, le style et les interactions utilisateurs disponibles. Les comportements en HXML définissent les actions qui doivent se produire dans l'application.
Ces actions sont une réponse à un déclencheur basé sur l'utilisateur. Les comportements peuvent être spécifiés soit comme attributs sur d'autres éléments HXML, soit comme un élément enfant <behavior>. Selon l’équipe de développement de l’outil, sur le Web, les pages sont rendues dans un navigateur en récupérant le contenu HTML à partir d'un serveur. Avec HXML, les écrans sont rendus dans votre application mobile en récupérant du contenu Hyperview XML depuis un serveur. La conception de HXML reflète l'interface utilisateur et les modèles d'interaction des interfaces mobiles d'aujourd'hui.
Selon Stepinski, chaque format permet de faire des compromis en matière de codage, de flexibilité et d'expressivité pour répondre au mieux à un cas d'utilisation spécifique. Autrement dit, un format optimisé pour la taille utilisera un encodage binaire qui ne sera pas lisible par l'homme, un format optimisé pour l'extensibilité prendra plus de temps à décoder qu'un format conçu pour un usage restreint et enfin un format conçu pour des données plates (comme CSV pour Comma-separated values) aura du mal à représenter des données imbriquées.
Outre les propriétés intrinsèques d'un format, Stepinski explique aussi que des facteurs externes peuvent influencer ses cas d'utilisation pratique, tels que la popularité du format auprès des développeurs cibles ou le support des bibliothèques dans les langages de programmation souhaités. « Lorsqu'ils choisissent un format de fichier à utiliser dans un projet logiciel, les ingénieurs en logiciel choisissent celui qui présente le meilleur équilibre entre les caractéristiques et les facteurs externes pour la situation », a-t-il déclaré dans un billet explicatif.
Pour Stepinski, JSON représente un meilleur choix que XML dans l’utilisation des listes. Le format XML est plus utile pour exploiter les arbres
D’après Stepinski, par exemple, JSON représente un meilleur choix que XML dans l’utilisation des listes. Par contre, le format XML sera plus utile pour exploiter les arbres. Il estime que JSON est bien plus adapté que XML pour représenter des listes d'objets aux propriétés complexes. La syntaxe clé/valeur de l'objet JSON facilite les choses. En revanche, la syntaxe des attributs XML ne fonctionne que pour des types de données simples. L'utilisation d'éléments enfants pour représenter des propriétés complexes peut entraîner des incohérences ou une verbosité inutile.
Pour lui, JSON excelle dans la représentation d'une collection d'objets homogènes, où les propriétés des objets peuvent être des types de données composites. D’un autre côté, XML excelle dans la représentation d'arbres avec des objets hétérogènes, où les propriétés des objets sont des types de données simples. Dans ce cas de figure, lorsque l’on voit les interfaces utilisateurs comme des arbres, Stepinski dit que XML est le format de représentation le mieux adapté. Selon Stepinski, les dispositions de l'interface utilisateur sont des arbres.
Adam Stepinski
C’est la raison pour laquelle ils ont conçu Hyperview en se basant sur le format XML existant. Stepinski a expliqué que les arborescences de composants sont le meilleur moyen de représenter les mises en page de l'interface utilisateur et que tous les principaux frameworks d'interface utilisateur utilisent une arborescence de composants. D’après lui, Xcode fournit même une vue 3D éclatée qui met réellement en évidence l'arborescence sous-jacente d'une interface : chaque composant a un composant parent, et tout se transforme en un composant racine partagé.
« Les structures de l'interface utilisateur sont représentées sous forme d'arbres de composants. Et XML est idéal pour représenter des structures arborescentes. C'est un mariage fait au paradis ! En fait, les frameworks d'interface utilisateur les plus populaires dans le monde (HTML et Android) utilisent la syntaxe XML pour définir les modèles », a déclaré Stepinski. Il donne l’exemple de React, le framework de composants graphiques de Facebook, qui recommande aussi de définir l'interface utilisateur des composants à l'aide de JSX, un format semblable à XML.
D’après lui, même si l'utilisation de JSX nécessite l'apprentissage d'une nouvelle syntaxe non-JS et l'ajout d'une étape de transplantation au processus de compilation, les concepteurs de la bibliothèque estiment que cela vaut la peine d'utiliser XML. « Les arbres sont une représentation puissante pour les agencements d'interface utilisateur. Ils fournissent naturellement des regroupements de composants, permettant aux concepteurs et aux développeurs d'utiliser des abstractions de plus haut niveau », a-t-il expliqué, dans son billet.
« Lorsque nous avons besoin de cacher, afficher ou animer une section de l'écran, nous n'avons pas besoin de changer l'état de chaque composant de la section. Nous pouvons plutôt changer l'état du composant parent unique qui contient chaque élément de l'interface utilisateur de la section. Lors de la modification d'un composant, nous n'avons qu'à nous préoccuper de ce qui se trouve dans son sous-arbre, et non de ce qui se passe à des niveaux supérieurs », a-t-il conclu.
Source : Adam Stepinski
Et vous ?
Quel est votre avis sur le sujet ?
Que pensez-vous des arguments de Stepinski ? Êtes-vous du même avis ou pas ? Pourquoi ?
Quel type de format préférez-vous et pourquoi ?
Voir aussi
JavaScript : faut-il privilégier les transformations XML à JSON et aux Frameworks ? Partagez vos avis
React : la version 16.8 de la bibliothèque JavaScript est disponible et embarque une version stable des Hooks
Une interface utilisateur évidente est souvent la meilleure interface utilisateur. Concevez des interactions claires plutôt qu'intelligentes et les utilisateurs suivront, conseille Google Design
Google Chrome apporte des modifications à l'interface utilisateur de son navigateur, les changements sont disponibles sur Chrome Canary
JSON signifie JavaScript Object Notation. C'est un format de fichier standard ouvert utilisé pour les communications navigateur-serveur. C'est un format de données indépendant du langage. XML signifie Extensible Markup Language. XML représente un ensemble de règles qui aident les utilisateurs à coder des documents dans un format lisible par l'homme et par la machine. Pour cette dernière raison, Adam Stepinski, directeur de l’ingénierie chez Instawork et son équipe pensent que le format XML est le meilleur choix dans la conception des interfaces utilisateurs.
Stepinski et son équipe ont développé Hyperview XML (HXML), un nouveau format hypermédia basé sur XML et un client React Native pour le développement d'applications mobiles pilotées par serveur. Hyperview XML est un format hypermédia utilisé pour définir les écrans (interfaces utilisateurs) d'applications mobiles. HXML fournit un ensemble de balises et d'attributs qui permettent de définir la disposition d'un écran, le style et les interactions utilisateurs disponibles. Les comportements en HXML définissent les actions qui doivent se produire dans l'application.
Ces actions sont une réponse à un déclencheur basé sur l'utilisateur. Les comportements peuvent être spécifiés soit comme attributs sur d'autres éléments HXML, soit comme un élément enfant <behavior>. Selon l’équipe de développement de l’outil, sur le Web, les pages sont rendues dans un navigateur en récupérant le contenu HTML à partir d'un serveur. Avec HXML, les écrans sont rendus dans votre application mobile en récupérant du contenu Hyperview XML depuis un serveur. La conception de HXML reflète l'interface utilisateur et les modèles d'interaction des interfaces mobiles d'aujourd'hui.
Selon Stepinski, chaque format permet de faire des compromis en matière de codage, de flexibilité et d'expressivité pour répondre au mieux à un cas d'utilisation spécifique. Autrement dit, un format optimisé pour la taille utilisera un encodage binaire qui ne sera pas lisible par l'homme, un format optimisé pour l'extensibilité prendra plus de temps à décoder qu'un format conçu pour un usage restreint et enfin un format conçu pour des données plates (comme CSV pour Comma-separated values) aura du mal à représenter des données imbriquées.
Outre les propriétés intrinsèques d'un format, Stepinski explique aussi que des facteurs externes peuvent influencer ses cas d'utilisation pratique, tels que la popularité du format auprès des développeurs cibles ou le support des bibliothèques dans les langages de programmation souhaités. « Lorsqu'ils choisissent un format de fichier à utiliser dans un projet logiciel, les ingénieurs en logiciel choisissent celui qui présente le meilleur équilibre entre les caractéristiques et les facteurs externes pour la situation », a-t-il déclaré dans un billet explicatif.
Pour Stepinski, JSON représente un meilleur choix que XML dans l’utilisation des listes. Le format XML est plus utile pour exploiter les arbres
D’après Stepinski, par exemple, JSON représente un meilleur choix que XML dans l’utilisation des listes. Par contre, le format XML sera plus utile pour exploiter les arbres. Il estime que JSON est bien plus adapté que XML pour représenter des listes d'objets aux propriétés complexes. La syntaxe clé/valeur de l'objet JSON facilite les choses. En revanche, la syntaxe des attributs XML ne fonctionne que pour des types de données simples. L'utilisation d'éléments enfants pour représenter des propriétés complexes peut entraîner des incohérences ou une verbosité inutile.
Pour lui, JSON excelle dans la représentation d'une collection d'objets homogènes, où les propriétés des objets peuvent être des types de données composites. D’un autre côté, XML excelle dans la représentation d'arbres avec des objets hétérogènes, où les propriétés des objets sont des types de données simples. Dans ce cas de figure, lorsque l’on voit les interfaces utilisateurs comme des arbres, Stepinski dit que XML est le format de représentation le mieux adapté. Selon Stepinski, les dispositions de l'interface utilisateur sont des arbres.
Adam Stepinski
C’est la raison pour laquelle ils ont conçu Hyperview en se basant sur le format XML existant. Stepinski a expliqué que les arborescences de composants sont le meilleur moyen de représenter les mises en page de l'interface utilisateur et que tous les principaux frameworks d'interface utilisateur utilisent une arborescence de composants. D’après lui, Xcode fournit même une vue 3D éclatée qui met réellement en évidence l'arborescence sous-jacente d'une interface : chaque composant a un composant parent, et tout se transforme en un composant racine partagé.
« Les structures de l'interface utilisateur sont représentées sous forme d'arbres de composants. Et XML est idéal pour représenter des structures arborescentes. C'est un mariage fait au paradis ! En fait, les frameworks d'interface utilisateur les plus populaires dans le monde (HTML et Android) utilisent la syntaxe XML pour définir les modèles », a déclaré Stepinski. Il donne l’exemple de React, le framework de composants graphiques de Facebook, qui recommande aussi de définir l'interface utilisateur des composants à l'aide de JSX, un format semblable à XML.
D’après lui, même si l'utilisation de JSX nécessite l'apprentissage d'une nouvelle syntaxe non-JS et l'ajout d'une étape de transplantation au processus de compilation, les concepteurs de la bibliothèque estiment que cela vaut la peine d'utiliser XML. « Les arbres sont une représentation puissante pour les agencements d'interface utilisateur. Ils fournissent naturellement des regroupements de composants, permettant aux concepteurs et aux développeurs d'utiliser des abstractions de plus haut niveau », a-t-il expliqué, dans son billet.
« Lorsque nous avons besoin de cacher, afficher ou animer une section de l'écran, nous n'avons pas besoin de changer l'état de chaque composant de la section. Nous pouvons plutôt changer l'état du composant parent unique qui contient chaque élément de l'interface utilisateur de la section. Lors de la modification d'un composant, nous n'avons qu'à nous préoccuper de ce qui se trouve dans son sous-arbre, et non de ce qui se passe à des niveaux supérieurs », a-t-il conclu.
Source : Adam Stepinski
Et vous ?
Voir aussi
-
defZeroMembre extrêmement actif
Le mec trouve XML plus adapter que JSON parce que son équipe vient de créer un UI Engine qui prend du XML pour faire du rendue dynamique/interprété, c'est tout, il n'y a pas à débattre 3 ans.
Chacun peut bien utiliser l'outil qui convient le mieux à son projet.
P.S. : Et dire qu'en 95 on utilisés principalement Delphi pour définir une interface en "client lourd"*.
C'était typer, compiler et juste ça fonctionnait bien.
Maintenant les gens utilise XML/JSON/YAML/...etc pour décrire leurs interfaces et interpréter le contenue à chaque utilisation.
Je vois ça comme une régression, pas un progrès.
* Vous remarquerez le "client lourd" entre guillemet parce qu’un client léger de 2019 pèse facile dans les 100-200MB.le 31/10/2019 à 22:44 -
KulvarMembre éclairéJSON n'est pas faire pour présenter les données.
XML (et HTML) si, encore heureux qu'il soit meilleur à ça.le 31/10/2019 à 15:29 -
kbadacheMembre averti
Sauf que dans tes exemples tu mélanges données et meta-données.
En xml, les attributs sont fait pour les méta-données, les données sont dans les balises, mais ça devient plus verbeux que du json.
En json, il n'est pas possible d'avoir des méta-données.le 31/10/2019 à 17:13 -
PyramidevExpert éminentCe serait bien de citer plus d'exemples de l'article original.
Exemple où JSON bat XML
Code propre en JSON :
Code JSON : 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18[ { "first_name": "Michael", "last_name": "Scott", "favorite_movies": [ "Diehard", "Threat Level Midnight" ] }, { "first_name": "Dwight", "last_name": "Schrute", "favorite_movies": [ "The Crow", "Wedding Crashers" ] }, { "first_name": "Pam", "last_name": "Beesly", "favorite_movies": [ "Legally Blonde" ] } ]
Code naze en XML : on encode une liste à la main avec la virgule comme séparateur.
Code XML : 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15<Users> <User first="Michael" last="Scott" favoriteMovies="Diehard, Threat Level Midnight" /> <User first="Dwight" last="Schrute" favoriteMovies="The Crow, Wedding Crashers" /> <User first="Pam" last="Beesly" favoriteMovies="Legally Blonde" /> </Users>
Code correct mais verbeux en XML :
Code XML : 1
2
3
4
5
6
7
8
9
10
11
12
13
14<Users> <User first="Michael" last="Scott"> <Movie>Diehard</Movie> <Movie>Threat Level Midnight</Movie> </User> <User first="Dwight" last="Schrute"> <Movie>The Crow</Movie> <Movie>Wedding Crashers</Movie> </User> <User first="Pam" last="Beesly"> <Movie>Legally Blonde</Movie> </User> </Users>
Exemple où XML bat JSON
Arborescence concise en XML :
Code XML : 1
2
3
4
5
6
7
8
9<Employee name="Michael Scott" title="Regional Manager"> <Employee name="Dwight Schrute" title="Ass. Regional Mgr" /> <Employee name="Jim Halpert" title="Head of Sales"> <Employee name="Andy Bernard" title="Sales Rep" /> <Employee name="Phyllis Lapin" title="Sales Rep" /> </Employee> <Employee name="Pam Beesly" title="Office Administrator" /> </Employee>
Arborescence en JSON, plus verbeuse à cause de l'indentation canonique :
Code JSON : 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
26
27
28
29{ "name": "Michael Scott", "title": "Regional Manager", "reports": [ { "name": "Dwight Schrute", "title": "Ass. Regional Mgr" }, { "name": "Jim Halpert", "title": "Head of Sales", "reports": [ { "name": "Andy Bernard", "title": "Sales Rep" }, { "name": "Phyllis Lapin", "title": "Sales Rep" } ] }, { "name": "Pam Beesly", "title": "Office Administrator" } ] }
le 31/10/2019 à 16:22 -
PyramidevExpert éminentUn des avantages de JSON sur XML est qu'il est plus facile à lire par un programme.
Pour la lecture par un humain, comme l'a montré l'auteur de l'article original, ça dépend des cas.
J'en profite pour souligner que, parmi les formats les plus utilisés pour structurer des données arbitraires, il y a aussi le YAML qui est une extension du JSON qui, par rapport à JSON, est plus facile à lire par un humain, mais moins facile à lire pour un programme.
Prenons l'exemple du JSON suivant :
Code JSON : 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
26
27
28{ "name": "Michael Scott", "title": "Regional Manager", "reports": [ { "name": "Dwight Schrute", "title": "Ass. Regional Mgr" }, { "name": "Jim Halpert", "title": "Head of Sales", "reports": [ { "name": "Andy Bernard", "title": "Sales Rep" }, { "name": "Phyllis Lapin", "title": "Sales Rep" } ] }, { "name": "Pam Beesly", "title": "Office Administrator" } ] }
Voici une réécriture en YAML :
Code YAML : 1
2
3
4
5
6
7
8
9
10
11
12
13
14name: Michael Scott title: Regional Manager reports: - name: Dwight Schrute title: Ass. Regional Mgr - name: Jim Halpert title: Head of Sales reports: - name: Andy Bernard title: Sales Rep - name: Phyllis Lapin title: Sales Rep - name: Pam Beesly title: Office Administrator
le 31/10/2019 à 20:16 -
LeBressaudMembre confirméSur un forum ça passe presque inaperçu, évite de dire ça en réunion avec des gens qui s'y connaisse un minimum..
JSON contient vaguement des données, formater n'importe comment dans un type totalement inconnu. Aucun rapport avec des méta-donnéesle 01/11/2019 à 0:53 -
PyramidevExpert éminentJSON distingue plusieurs types de données. Par exemple, les booléens ne sont pas des nombres qui ne sont pas des chaînes.
De base, dans du JSON, tout comme dans du XML, on peut mettre n'importe quoi n'importe comment.
Et si on veut écrire un schéma de validation pour restreindre ce que l'on a le droit d'écrire, tout comme il existe des schémas XML, il existe aussi des schémas JSON.le 01/11/2019 à 2:11 -
PyramidevExpert éminentJe suis d'accord avec ce passage.
Avoir plus de meta-données que de données serait bizarre. Les données normales, ce sont les données principales que l'on veut stocker. Les meta-données, ce sont des informations complémentaires. Et il n'y a aucune raison qu'il y en ait plus en JSON qu'en XML.
Au début de l'article original, on peut lire :
When demoing Hyperview to new engineers, there’s one comment that frequently comes up about the HXML data format:
“XML, really? It’s bloated and outdated. Why not use JSON? It’s the future.”
Sauf que, dans les cas où le XML peut être plus lisible que le JSON, il faut tirer profit des attributs.
Si on réserve les attributs aux méta-données, alors on se retrouve avec du XML très verbeux comme ça :
Code XML : 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<?xml version="1.0" encoding="UTF-8" ?> <root> <name>Michael Scott</name> <title>Regional Manager</title> <reports> <name>Dwight Schrute</name> <title>Ass. Regional Mgr</title> </reports> <reports> <name>Jim Halpert</name> <title>Head of Sales</title> <reports> <name>Andy Bernard</name> <title>Sales Rep</title> </reports> <reports> <name>Phyllis Lapin</name> <title>Sales Rep</title> </reports> </reports> <reports> <name>Pam Beesly</name> <title>Office Administrator</title> </reports> </root>
Code JSON : 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
26
27
28{ "name": "Michael Scott", "title": "Regional Manager", "reports": [ { "name": "Dwight Schrute", "title": "Ass. Regional Mgr" }, { "name": "Jim Halpert", "title": "Head of Sales", "reports": [ { "name": "Andy Bernard", "title": "Sales Rep" }, { "name": "Phyllis Lapin", "title": "Sales Rep" } ] }, { "name": "Pam Beesly", "title": "Office Administrator" } ] }
le 01/11/2019 à 14:04 -
SodiumMembre extrêmement actifHeu ben oui... idéalement avec du XML itérant sur des données JSON d'ailleurs comme c'est le cas d'Angular ou Vuejs (je ne parlerai pas de React car c'est sale).
Il y avait un doute à ce sujet ?le 31/10/2019 à 14:46 -
pdevilleMembre à l'essaiJSon est parfaitement adapté à la gestion des données structurées et fournit un format peu verbeux.
XML bien que plus verbeux permet de representer des données non structurérs avec CDATA.le 31/10/2019 à 18:42