« JSON n’est pas vraiment plus simple à lire par un humain »
Pas très factuel. JSON n’est pas plus compliqué à lire par un humain que du XML. Et encore, je suis volontairement gentil avec XML en occultant les CDATA, les namespaces, les entitées XML et autres joyeusetés. Puis que ça soit le XML ou le JSON, ce n’est de toute façon pas le but. Petite question qui me turlupine, tu écris tes programmes avec une syntaxe proche d’XML ou ces derniers sont illisibles ?
« Pour un gros fichier ou avec beaucoup de hiérarchie, le JSON devient complètement illisible à suivre au niveau des imbrications. »
C’est pour ça qu’on a inventé l’indentation, c’est d’ailleur cette même indentation qui fait qu’un XML est lisible par un humain. Dans les deux cas, passé une certaine limite, quelqu’un de normal utilisera un assistant qui réduira/développera une arborescences selon les besoins d’exploration.
« JSON n’est pas plus simple à écrire par un humain »
« facile d’oublier une virgule en fin de ligne, ou d’en mettre une par erreur à la dernière ligne. »
À peu prêt aussi facile que de ne pas fermer une balise ou de faire une faute de frappe dans le nom d’une balise (deux fois plus de risque puisque présente deux fois)
« Sur les gros fichiers les niveaux d’imbrication seront eux aussi un écueil à l’écriture. »
Et c’est bien pour ça qu’il n’est pas indiqué de gérer de gros fichiers à la main mais qu’on les génère
« En comparaison la verbosité d’XML rend difficile les erreurs et le disponibilité de fichiers grammaire permettent de faire de l’aide à la saisie voire de valider en tems réel le contenu. »
Si tu as besoins d’un assistant pour détecter les erreurs de syntaxes, c’est dans le domaine de l’IDE ou de l’éditeur.
« La différence de poids n’est pas significative »
« il faut une donnée de 160 Ko avant compression. Ça concerne d’autant moins de monde qu’à ce volume le JSON n’est plus du tout lisible. »
Wait… What ? oO JSON n’est pas plus natif que XML
« XML est natif sur tous les outils, langages et navigateurs depuis des annéeslà où JSON n’a d’API native que sur les navigateurs récents, certains langages et quelques outils. »
Comment dire… Non. Pour ne prendre qu’un exemple, en C, que ce soit en XML ou en JSON, il te foudra passer une lib tierce. Mais dans les deux cas, ça ne pose pas de problèmes vu que ces librairies existent justement (et que dans le cas du JSON, c’est pas étonnant car implémenter un parser se fait en quelques lignes).
« JSON est en fait natif en javascript via eval() »
Pas que…
« mais ça n’est pas plus performant. »
Pas plus performant que quoi ?
« Pour une même donnée, lire du XML via DOM est 30% plus rapide que lire du JSON avec eval(). »
Donc si je résume, si on utilise une mauvaise méthode sur un langage en particulier (Javascript) sur des logiciels obsoletes (vieux navigateurs), parser du JSON est plus lent que parser du XML. Admettons (et encore ça reste à prouver car je serais curieux de savoir d’où sort ces chiffres)
« Elle fera au moins 5 Ko »
2.5Ko sur le site officiels (JSON.org), le tout avec une plétore de tests tenant compte des n différentes implémentations de Javascripts. Tu sais quel poid font les librairies JS pemettant de parcourir un DOM de la même façon sur tous les navigateurs ? Je parle même pas du fait que c’est sans doute déjà intégré dans la lib que tu utilises pour pouvoir faire de l’AJAX de la même façon sur ces mêmes n navigateurs.
« JSON n’est pas vraiment extensible ou évolutif »
« JSON permet souvent d’ajouter de nouvelles clefs sans modifier casser la compatibilité. »
En effet, au passage, c’est ce qui correspond au X de XML (eXtentible Marktup Language).
« Si on souhaite ajouter une date de mise à jour à une liste de chaînes de caractères, il faudra toutefois modifier le format. »
Pas si on s’y prend bien.
Sans les dates :
<liste>
<chaine>a</chaine>
<chaine>a</chaine>
</liste>
liste: [
{chaine: 'a'},
{chaine: 'a'}
]
Avec les dates
<liste>
<chaine date="2011-10-10">a</chaine>
<chaine date="2011-10-10">a</chaine>
</liste>
liste: [
{chaine: 'a', date: "2011-10-10"},
{chaine: 'a', date: "2011-10-10"}
]
pas de différences notoires donc.
« mettre à jour tous les outils concernés. Si on souhaite mixer des formats différents là ça devient vite un casse-tête et des solutions bidouille. »
En pousant le vis, je peux même décider que ces chaines ont plusieurs auteurs sans modifier ma façon de parcourir le document
liste: [
{
chaine: 'a',
date: "2011-10-10",
auteurs:[
{nom: "Jean", prenom: "Christophe"},
{nom: "Jean", prenom: "Luc"}]
},
{
chaine: 'a',
date: "2011-10-10",
auteurs: [
{nom: "Jean", prenom: "Christophe"},
{nom: "Jean", prenom: "Luc"}
]
}
]
Comment tu fais en XML ? Et si j’étais encore plus méchant pour XML, j’aurai nommé ma propriété « les auteurs ».
« En XML on a la possibilité d’insérer des méta-données dans des attributs »
En JSON, ces « méta-données » peuvent être composées (exemple de l’auteur ci dessus)
« Outre le concept de « natif », beaucoup d’outils, d’applications, de progiciels ou de chaînes de traitement sont adaptés à l’exploitation ou à l’exportation de données XML. Côté JSON les plus récents savent faire de l’export, tout le reste est à traiter en spécifique. »
Outre le fait que c’est pas vraiment vrai, c’est exactement ce que les gens se disaient pour le XML face à leur CSV
Dieu merci, tout le monde n’est pas refractaire au nouveau, et bien que Hype, le XML a peu à peu fait sa place.
« JSON était simple au départ parce qu’on utilisait eval(), que ça renvoyait immédiatement sur un objet javascript sans demander au développeur client de faire des manipulations complexes ou de charger une bibliothèque de plus. Ça a permis d’ouvrir quelques API à des gens qui auraient eu du mal autrement. C’est indéniablement positif sur ce point là. »
JSON n’a pas été réfléchi de cette manière, mais bien plus dans la philosophie DRY, tout comme son frère YAML (qui offre bien plus de possibilités au passage).
« Ensuite s’est rendu compte que pour la fiabilité et la sécurité il fallait du code en plus. »
Ca c’est clairement une réinterprétation arbitraire de l’histoire. Le reste du poste que je ne vais pas citer également.
« Du coup on a utilisé des bibliothèques d’analyse de 10 Ko de pur javascript pour lire des JSON de moins de 1 K »
Et on passe de librairies de 2.5Ko (vraie valeur) à 5Ko puis maintenant 10Ko…
A moins d’être encapsulé dans du XML, il n’y a pas de raison que le chiffre évolue de la sorte ;)