Je réponds, long, en dessous, MAIS encore une fois, visiblement je n’ai pas la réponse à la question principale : sur quels usages le JSON est-il plus pertinent que le XML et pourquoi ?

« JSON n’est pas plus compliqué à lire par un humain que du XML »

Je pense que pour les gros fichiers, si. En tout cas pour moi, oui. L’indentation ne résoud qu’une partie du problème. Quand ton ouverture d’indentation est ouverte deux pages plus haut, savoir si pour passer où se situe la section suivante que tu cherches est parfois une galère sans nom. Je n’ai peut être pas le bon assistant mais les miens il faut remonter les deux pages pour fermer le bloc, puis après continuer à explorer les parents du blocs suivants jusqu’à trouver ce que tu cherches, et parfois c’est assez pénible. C’est du vécu. Les balises fermantes du XML aident beaucoup à ce niveau.

« à 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) »

Sauf qu’oublier la balise fermante il faut le vouloir, ça te saute à la figure quand même. La virgule c’est rarement le cas. C’est encouragé par le fait qu’il faut une virgule entre deux éléments mais pas sur le dernier, donc quand tu retires le dernier, ou que tu le déplaces, il est très facile de laisser ou oublier de rajouter la virgule.

Les balises fermantes ont ça de bien que justement on les ferme tout le temps. Le fait que ça soit systématique diminue les erreurs. D’ailleurs ça faisait partie des avantages que tout le monde trouvait à XHTML dans le temps. Je n’invente rien.

« 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. »

Et ? je ne vois pas en quoi ça fait disparaitre le problème. Qu’il soit au niveau de l’éditeur ou pas, j’ai là des aides en XML que je n’ai pas en JSON. Et non, ça vient aussi du format puisqu’il n’y a pas de DTD ou équivalent en JSON donc l’éditeur aurait du mal à l’inventer.

« Wait… What ? oO »

160K avant compression = environ 40K après compression pour du texte (25%)
40K mis en JSON plutôt qu’XML c’est environ 12K de JSON. voilà mon calcul.

Sur toute une page, qui en général dépasse les 700K, en dessous je trouve ça peu significatif. En tout cas tant que c’est de l’asynchrone. C’est encore plus vrai quand le JSON est transféré après le chargement initial de la page.

« 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 »

Dans d’autres langages il y a une différence entre ce qui est natif et ce qui ne l’est pas. Mais je ne t’apprends rien ici.

« JSON est en fait natif en javascript via eval() »
« Pas que.. »

Pas que, mais je crois que je l’ai abordé dans le billet non ? Ca demande quand même de charger 5K de js dans le navigateur pour avoir une interprétation non native (tu vois, ça a une influence de ne pas être en C :)

« Pas plus performant que quoi ? »

Que XML. Euh, ce n’est pas assez clair dans le billet que je compare les deux ?

« 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) »

Navigateurs obsolètes c’est vite dit. Si tu ne veux pas jeter IE7 ou iPhone 3.2 il faut le prendre en compte. C’est quoi la bonne méthode pour toi là dessus ?

Lib ou eval sont tous les deux lents. Tu peux chercher « xml + json + performance » sur ton moteur de recherche, tu devrais trouver des comparaisons.

« 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. »

Je suis surpris, j’avais vérifié et j’avais trouvé plus de 5K justement. J’irai vérifier une seconde fois.

« Tu sais quel poid font les librairies JS pemettant de parcourir un DOM de la même façon sur tous les navigateurs ? »

Parcourir le DOM ? non, je ne sais pas parce que justement c’est du natif dans tous les navigateurs, même IE6.

« 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. »

Soyons factuels : ça ne l’est pas. (j’utilise YUI, le module JSON est séparé).

« Pas si on s’y prend bien. »

Qualifies « bien » ?

Dans ton exemple tu as sur-architecturé au départ. Si on te demande une liste de prix tu aurais vraiment dans ton json mis liste: [ {prix: 3}, {prix: 5} ] ? je parie ma chemise que non.

« Outre le fait que c’est pas vraiment vrai, c’est exactement ce que les gens se disaient pour le XML face à leur CSV »

Si ton argument c’est que dans 5 ans ça ne sera plus vrai. Je veux bien y croire. N’empêche que maintenant ….
Le fait que dans 5 ans on aura du support n’est pas pour moi un argument pour choisir maintenant un format.

« Dieu merci, tout le monde n’est pas refractaire au nouveau, et bien que Hype, le XML a peu à peu fait sa place. »

Je râle toujours autant contre la sur-utilisation de XML à des endroits où c’est stupide notes bien ;)

« Et on passe de librairies de 2.5Ko (vraie valeur) à 5Ko puis maintenant 10Ko… »

La 10Ko je l’ai trouvée sur json.org justement maintenant que tu le dis (comme quoi j’avais bien regardé). C’est laquelle la 2.5K ? A moins d’être encapsulé dans du XML, il n’y a pas de raison que le chiffre évolue de la sort