« L’article n’est pas du tout orienté comme ça et je m’en tiens à contester ce qui me parait faux. »

Et à la relecture je me dis que tu as raison, il était difficile pour le lecteur de voir que ce qui me tenait à coeur c’était cette question. Notes que je ne reproche pas du tout de discuter des points précis, au contraire. Juste qu’au final ça me frustre parce que pour moi ce n’était pas ça l’important et l’utile.

« Alors qu’en XML ça n’arrive jamais je suppose. »

Ca arrive, mais avoir la balise fermante avec son nom au lieu d’une accolade aide beaucoup.
Les IDE aident pour les accolades mais au mieux ça demande des manip pour aller sur la fermante, faire un raccourci pour voir l’ouvrante, un autre pour revenir à la fermante, puis aller sur la suivante et refaire la même manip. La plupart de ceux que j’ai vu se contentent de surligner l’ouvrante et de permettre de réduire le bloc, mais quand elle est deux pages plus haut ça reste super chiant. C’est peut être lié à la façon dont je gère mon éditeur mais je t’assure que c’est du vécu et non de la mauvaise foi, et que je l’ai lu chez d’autres plusieurs fois.

« Le fait d’avoir des acolade pour ouvrir et fermer des blocks est tellement illisible qu’il est repris dans les principaux langages de programmation (y compris les plus vieux), qui sont, nous le savons tous fait de sorte à ce qu’il deviennent illisibles. »

Du coup justement, tous les guides de style que je connais proposent de limiter la taille des méthodes et des blocs (pas que pour ça, mais ça entre en compte). Dans un format d’échange c’est plus difficile vu que c’est simplement lié au volume de donnée échangé.

« Sauf qu’oublier la balise fermante il faut le vouloir […] Les balises fermantes ont ça de bien que justement on les ferme tout le temps. »
Alors qu’une accolade fermante on fait expré de ne pas la mettre… Soyons sérieux.

Je parle de la virgule en fin de ligne. Qui n’est pas toujours systématiques.

« Je suppose que tu ajoutes régulièrement des virgules après le dernier argument de déclaration de tes fonctions…. »

Là c’est toi qui est de mauvaise foi. Parce que moi j’ajoute/supprime/réordonne souvent des items dans des listes, je le fais rarement dans les arguments de fonction. Sans compter que mes listes sont présentées ligne à ligne, bien différemment de mes arguments de fonction, et que le volume est lui aussi très différent.
C’est au point où certains navigateurs/langages autorisent une virgule après le dernier item d’une liste. Ils ne l’ont jamais fait pour les arguments d’une fonction. Je n’invente rien là, c’est au point où on a fait évolué la grammaire pour gérer le problème.

« Et, ben ce n’est pas lié au format à proprement dit. »

C’est lié au format dans le sens où si je choisis le format ça entraine ces désavantages. Savoir si en interne c’est du au moteur, à la grammaire, aux IDE, je m’en moque un peu. C’est peut être vrai mais ça ne retire pas le critère de ma grille de choix et de ses implications.

« C’est le fait de partir du fait qu’un JSON « lourd » est forcement illisible et d’en faire une vérité génrale comme si c’était admis qui me choc, »

J’ai quand même le droit d’avoir mes opinions mais là aussi je ne le sors pas de mon chapeau, je l’entends et vis assez souvent.

« pour ce qui est des stats, on a beau retourner le problème dans tous les sens, JSON est plus performant à lire/écrire/transférer que du XML, et ce sont des amateurs qui n’ont pas du tout des problèmes de performances qui le disent comme Google (voir communiqué de presse concernant protocole buffer) ou Twitter (qui a abandonné XML pour ses API au profit du JSON) »

Sauf que 1- Google a des contraintes très différentes de la plupart des gens 2- Twitter l’a abandonné « parce que JSON était plus utilisé » et pour ne pas maintenir les deux (j’ai vérifié) et pas pour des questions de perf. Je veux bien le lien du communiqué google ceci dit.

Oui, si tu t’appelles Google une différence de poids peut faire une grosse différence au final. Pour l’essentiel des gens, y compris les très gros, les échelles que je donne ne sont pas significatives par rapport aux autres critères. Pour les différences de perf côté navigateur, entre une analyse DOM et un eval(), le DOM est plus performant. J’avais aussi fait les tests pour des lib JS de parsing JSON, mais il faudrait les refaire, les moteurs JS ayant bien changé depuis.

« Et en comparrent pas natif vs pas natif et natif vs natif, JSON s’en sort toujours haut la main, et même en JSON pas natif vs XML natif, je ne pense pas trop me mouiller en disant que JSON n’a pas à palir ne srait-ce que du fait de la RAM consommée car plus léger (et oui). »

Tu te trompes. J’ai fait des tests (il y a pas mal de temps, je l’avoue) et ça concorde avec les autres tests que j’ai lu chez d’autres.

« Encore une fois, tu prends un exemple bien précis, dans un langage bien précis et sur des outils obsolettes. »

Je prends un exemple qui représente plus de 15% du parc, parce que le choix que tu fais implique ceux là aussi, que tu les juges obsolètes ou non. Sur les autres la différence me parait négligeable.

Je peux sortir un equivalent pour XML mais j’ai l’honetteté intelectuelle de ne pas le faire.

Très bien. Montres moi un langage ou un navigateur de ce niveau d’importance sur le marché qui ne peut pas gérer XML mieux que ça.

Ensuite, je le répète, le problème est identique du côté DOM puisque, je le répète aussi, chaque navigateur et chaque version de ce dernier à son lot de bugs / différence d’implémentation que des librairies tel que Mootools, jQuery, YUI et conssort s’appliquent à effacer (querySelector, getElementByName/Id buggé etc.)

Hum, pas sur la base d’interprétation. Les bugs dont tu parles sont sur le DOM de la page initiale sur des API que tu n’as même pas en JSON de toutes façons. Pour parcourir un message et récupérer les valeurs en JS, je te mets au défi de me trouver des problèmes.

« 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. »
C’est pourtant ce que tu fais en XML.

C’est bien ce que je te dis. Dans des cas concrets, la façon de faire en XML t’ouvre plus d’opportunités.

On l’a déjà le support, Dieu merci, on a pas attendu de convaincre les gens avant de profiter des avantages de JSON.

Quels avantages ?