JSON c’est hype

J’en ai marre de voir du JSON partout. J’ai même vu des gens proposer de remplacer du XML par du JSON juste parce que c’est plus moderne, plus léger et plus compatible. « JSON is the new XML » est un effet de mode, un mauvais effet de mode. On va se retrouver comme avant avec des gens qui vont se réveiller dans quelques mois/années avec des formats de données pas du tout adaptés à leur usage.

Coupons un peu dans le tas :

JSON n’est pas vraiment plus simple à lire par un humain

Pour un petit fichier en volume comme en hiérarchie, le JSON a un léger avantage sur le XML mais ce n’est pas franchement significatif.

Pour un gros fichier ou avec beaucoup de hiérarchie, le JSON devient complètement illisible à suivre au niveau des imbrications.

JSON n’est pas plus simple à écrire par un humain

JSON est un peu moins verbeux mais plus propice aux erreurs : facile d’oublier une virgule en fin de ligne, ou d’en mettre une par erreur à la dernière ligne. Sur les gros fichiers les niveaux d’imbrication seront eux aussi un écueil à l’écriture.

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.

La différence de poids n’est pas significative

JSON est plus léger que le XML d’environ un tiers (pour des fichiers fortement structurés, beaucoup moins pour les autres). À moins de 1,5 Ko une fois compressé en gzip (donc 6 Ko non compressé) ça tient dans un paquet TCP/IP et 500 octets de moins ne changent strictement rien. Sur disque on compte de toutes façons au moins par paquets de 4K.

Pour faire une différence significative de 10 Ko sur le réseau 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.

JSON n’est pas plus natif que XML

XML est natif sur tous les outils, langages et navigateurs depuis des années là où JSON n’a d’API native que sur les navigateurs récents, certains langages et quelques outils.

JSON est en fait natif en javascript via eval(), mais ça n’est pas plus performant. Pour une même donnée, lire du XML via DOM est 30% plus rapide que lire du JSON avec eval(). Pour avoir sécurité et fiabilité en lecture, ou pour faire de l’écriture JSON, il faudra une biblothèque pas native du tout sur IE7 ou Safari pour iPhone 3.2. Elle fera au moins 5 Ko et ne sera donc rentabilisée par rapport au XML natif que si on transfert au moins 15 Ko de JSON.

JSON n’est pas vraiment extensible ou évolutif

JSON permet souvent d’ajouter de nouvelles clefs sans modifier casser la compatibilité. Si on souhaite ajouter une date de mise à jour à une liste de chaînes de caractères, il faudra toutefois modifier le format, 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 XML on a la possibilité d’insérer des méta-données dans des attributs, ainsi que de mixer différents concepts ou formats à l’aide d’espaces de noms. Ce sont des fonctionnalités qui ont leurs limites, mais qui ont prouvé apporter un peu de souplesse et d’évolutivité aux formats créés.

Compatible avec l’existant

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.

Sur l’existant XML j’ai des concepts de signature, des mapping XML-Objet en Java, des outils qui font du filtre ou du routage, de la validation, des compositions entre données XML.. tout ça n’existe simplement pas en JSON. Quand (si) j’en aurai besoin, il faudra réinventer la roue.

Hype, mode et trucs de jeunes développeurs innovants

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à.

Ensuite s’est rendu compte que pour la fiabilité et la sécurité il fallait du code en plus. Faire des petites fonctions qui lisent du XML simple pour créer des objets javascript natifs aurait été plus simple, plus performant et moins lourd mais c’était trop tard : c’était « hype ». Du coup on a utilisé des bibliothèques d’analyse de 10 Ko de pur javascript pour lire des JSON de moins de 1 Ko et annoncer que ces derniers étaient moins lourds que le XML correspondant. Allez comprendre.

Depuis on a des fonctions natives dans les navigateurs récents et un peu plus de support dans les outils récents (c’est la mode, il a bien fallu faire avec et supporter le nouvel usage) donc ça a du sens pour quelques usages (échange de petites données structurées avec un navigateur récent) mais la mode prend encore trop le pas sur des grilles de comparaison argumentées et factuelles et même dans les usages les plus adaptés, le bénéfice sur le XML est rarement très significatif.

Publié

12 mai 2011

dans

Développement web

par

Éric

Étiquettes :

Commentaires

15 réponses à “JSON c’est hype”

naholyr

12 mai 2011

Que tu n’aimes pas un format est une chose mais je crains que le réflexe anti-hype n’ait pris le pas sur l’objectivité et l’ouverture d’esprit.

JSON n’est pas fait pour être validé, ce n’est pas un langage de description de données, mais un langage de serialisation. Comme yaml par exemple. Ce ne sont pas les mêmes objectifs.

Or ici tu appuies ton argumentaire justement sur une mauvaise utilisation de cette syntaxe: ceux qui cherchent à valider du json se sont trompés, si validation il y a elle n’est pas faite sur le document, mais au moment d’utiliser son objet désérialisé.
On n’écrit pas un schéma pour du JSON, on écrit de la documentation…

Enfin, tes arguments sur la lisibilité sont extrêmement subjectifs et pour la majorité c’est bien plus simple à relire dans *toutes* les conditions (pas besoin d’un logiciel dédié).

Ah et pas de lib dédiée? Tu fais quoi de « json_encode » de php et ces équivalent dans les autres langages? C’est pas natif ça? Et vu qu’on ne parle pas de document mais d’objet sérialisé, exit la notion de schéma ou de validation, c’est « out of the box » (et natif)

Répondre
Éric D.

12 mai 2011

je ne dis pas que je ne l’aime pas, juste qu’il est utilisé à tort et à travers pour n’importe quel usage qui n’y est pas adapté.

Alors parlons objectif et factuel. Comme j’ai l’impression que c’est ta réponse qui est dans l’affectif je vais tenter d’en dépiler le contenu pour le discuter sur des faits.

– JSON n’est pas fait pour être validé ? C’est toi qui le dit. Personnellement je ne vois pas de raison pour laquelle telle ou telle grosse boite pourrait avoir envie de valider les flux venant des API Facebook par exemple.

Mais soit. Acceptons. Tu viens de retirer un usage au JSON là où XML passe bien.

– JSON est un format de sérialisation et non de description ? Je ne sais pas bien s’il y a une différence fondamentale vu que ce que tu sérialises c’est bien la description d’une donnée. Pour ma part json.org parle de « format d’échange », ce qu’est aussi XML.

Mais soit, acceptons. Tu viens de retirer un usage au JSON mais comme XML est utilisé depuis des années pour faire de la sérialisation, je ne vois toujours pas d’usage avantageux pour le premier.

– Il ne faut pas faire la validation sur le document mais sur l’objet au final ? J’en suis étonné vu que l’objet de la validation des messages c’est généralement d’éviter d’injecter des erreurs dans le code et d’arriver à l’objet avec des données malformées, ou au moins de pouvoir vérifier que l’erreur vient du document et pas du code objet.

Mais soit, acceptons. Avec quoi fais tu cette validation de l’objet ? tu as des outils ? des standards ? des façons de faire classiques ? des aides ? Si tu me dis qu’il s’agit de refaire une roue spécifique à chaque fois tu ne fais que donner de l’eau à mon moulin.

– Sur JSON on n’écrit pas de schéma mais de la documentation ? J’en suis étonné. Les deux ont des objectifs différents qui ne se recoupent aucunement et qui ne sont pas exclusifs. L’un n’a jamais remplacé l’autre.

Mais soit. Là aussi tu viens de retirer un usage du JSON mais je pense que tu accepteras que rien n’empêche de faire de la doc pour du XML donc là non plus je ne vois pas trop l’avantage.

Pour la lisibilité c’est effectivement purement subjectif mais quand il y a plein d’accolades fermantes et que les ouvrantes ne sont pas devant les yeux, il est souvent difficile de savoir où on en est. Ce n’est pas propre à JSON, les codes de programmation sont bien les mêmes. On trouve d’ailleurs plusieurs guides de style de programmation qui recommandent de mettre des commentaires en face des accolades fermantes pour repéter l’instruction d’ouverture histoire de s’y retrouver.

Ceci dit je prends le point, c’est effectivement subjectif.

Pour la lib dédiée oui, json_encode existe depuis PHP 5.2 donc encore inaccessible pour une grande partie des installations (entre autres toutes les Redhat entreprise). En Ruby par exemple c’est du code utilisateur et il y a plusieurs implémentations. En javascript je crois que j’en parle dans le corps de l’article.

Mais parlons objectivement vu que ce que tu dis globalement c’est « oui, mais ce que ça ne fait pas ce n’est pas fait pour » alors .. c’est quoi les usages pour lesquels JSON est adapté et que XML ne fait pas mieux ou au moins à peu près aussi bien ? À part les premiers usages dont je parle dans la dernière section de ce billet, je ne vois pas bien.

Répondre
Pierre Bertet

12 mai 2011

Je rejoins l’avis de @396445b6e14727dcb6b3d6a66d52b567:disqus : JSON et XML ne proposent pas les mêmes fonctionnalités, et faire une comparaison sur le poids, la lisibilité ou les errreurs de syntaxe possibles (?) me paraît un peu léger.

XML est souvent comparé à JSON (notamment pour les APIs), parfois à tort, et c’est peut-être ce qui a motivé l’écriture de cet article, mais entrer dans ce jeu de petites comparaisons ne me paraît pas très constructif.

Je précise que j’utilise régulièrement XML / XPath / XSLT (j’utilise Symphony CMS qui repose entièrement dessus), et évidemment JSON quand c’est nécessaire. En fait, je ne comprends pas ce besoin de « défendre » le XML face au JSON. Le second remplace le premier dans certains cas et c’est tant mieux, XML n’est simplement pas adapté à toutes les situations. Mais il n’a jamais été question de remplacer le XML par du JSON dans toutes les situations, ce serait de toute façon techniquement impossible !

En lisant cet article, je vois surtout des arguments très faibles face à JSON (pas un mot sur l’écosystème XML, juste une comparaison de syntaxe), et tout ceci laisse penser que l’auteur a simplement du mal à accepter le « changement ».

Répondre
Éric D.

12 mai 2011

C’est pourtant le fond du billet dans lequel je tente de balayer les fonctionnalités et les avantages. « entrer dans ce jeu de petites comparaisons » c’est justement ce qu’on fait quand on veut challenger ce qui parait de l’affectif pour se fonder sur de l’objectif : on tente de trouver les critères et on les évalue.

« JSON et XML ne proposent pas les mêmes fonctionnalités ». « et
évidemment JSON quand c’est nécessaire ». « XML n’est simplement pas
adapté à toutes les situations ».

J’en profite parce que c’est ça l’objectif.

– Quelles sont les fonctionnalités proposées par JSON et non proposées par XML ?

– Quels sont les cas où JSON est « nécessaire » ?

– Dans quels cas JSON est plus adapté que XML et bien entendu, pourquoi ?

« Le second remplace le premier dans certains cas et c’est tant mieux »

C’est pourtant bien ce que je contexte, je vois de plus en plus JSON remplacer partout XML, dans quelques cas où c’est à peu près équivalent ou du domaine du gout, et dans pas mal de cas où pourtant il n’y a que des désavantages. Le seul endroit où je vois encore du XML sans JSON c’est dans les API internes des SI et les échanges SOAP (et encore, là certains pensent que passer à REST implique forcément de passer à JSON).

Moi je veux bien accepter un changement si j’y vois un bénéfice. Il est où ce bénéfice ? c’est ce que j’attends de vous si vous contestez le jugement que je tente de poser sur des bases objectives.

Répondre
Karl

12 mai 2011

Le problème de vos argumentations des deux côtés, c’est qu’elles sont théoriques et donc sujets au conflit. Plus constructif est de prendre des cas concrets rencontrés sur le net et de voir quels sont les avantages et les inconvénients d’utiliser une méthode ou une autre.

Répondre
Vincent

12 mai 2011

Je suis tout à fait d’accord sur l’intérêt du XML par rapport à JSON dans une API. Il est souvent mieux supporter, plus rapide et finalement bien mieux connu par une majorité de développeurs. Selon moi, c’est encore la référence en matière d’API et cela va rester encore quelques années.

Mais soyons précis, JSON reste intéressant. Ne serait-ce que par le JSONP qui permet d’intégrer un service web directement dans une page sans passer par XHR, ni proxy côté serveur. C’est une solution bien plus simple pour intégrer un service web dans une page web, pas forcément la plus élégante, mais ça n’a jamais été le but.

La meilleure solution reste encore de s’adapter. Selon moi, un service se doit de fournir de l’XML, pour faciliter l’intégration avec un maximum de languages et de plateformes, mais s’il y a un besoin d’utiliser le service sur web, fournir également un format JSON(P) n’est pas beaucoup plus compliqué et facilitera énormément le travail d’intégration, surtout quand le service se destine au (quasi) grand public, je pense ici aux services de Google par exemple.

Répondre
Christophe Jean

12 mai 2011
« 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 ;)
Répondre
Éric D.

13 mai 2011

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

Répondre
Éric D.

13 mai 2011

Ah, j’abonde pour JSONP, c’est effectivement une raison d’utiliser JSON qui me semble justifiée. Elle pose d’autres problèmes de sécurité mais bon, j’utilise discus donc je ne peux pas trop me la ramener là dessus.

OK pour ça.

Répondre
Éric D.

13 mai 2011

Ok, effectivement, j’avais vérifié deux scripts sur json.org, le dernier lien est bien plus petit (mais ne fait que la lecture et ne gère aucun cas d’erreur)

Répondre
Christophe Jean

13 mai 2011

« sur quels usages le JSON est-il plus pertinent que le XML et pourquoi ? »
L’article n’est pas du tout orienté comme ça et je m’en tiens à contester ce qui me parait faux.

« 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. »
Alors qu’en XML ça n’arrive jamais je suppose. Le fait d’avoir une arborescence qui prend 2 pages est intimement lié à JSON n’est-ce pas. Tout bon editeur IDE permet de sauter rappidement d’une balise/acolade ouvrante à une fermante et vis vers ça et il propose bien souvent en sus la possibilité de réduire/développer une arborescence donc ton problème est plus de la mauvaise volonté (foi ?) qu’autre chose.

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.

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

« 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. »
Je suppose que tu ajoutes régulièrement des virgules après le dernier argument de déclaration de tes fonctions….

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

« 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 »
Et il n’a pas à le faire (comme @naholyr l’a dit). Et encore une fois, si tu écris du JSON/XML à la main, you do it wrong.

« voilà mon calcul. »
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, 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)

« C’est encore plus vrai quand le JSON est transféré après le chargement initial de la page. »
Dans le cas contraire, il n’a pas besoin d’être parsé puisque c’est un subset de Javascript.

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

« 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 :) »
Encore une fois, tu prends un exemple bien précis, dans un langage bien précis et sur des outils obsolettes.
Je peux sortir un equivalent pour XML mais j’ai l’honetteté intelectuelle de ne pas le faire.

« Que XML. Euh, ce n’est pas assez clair dans le billet que je compare les deux ? »
Dans le même genre : une banane est plus performante qu’une tomate. Il me faut un plus de détail, merci.

« Navigateurs obsolètes c’est vite dit. Si tu ne veux pas jeter IE7 ou
iPhone 3.2 il faut le prendre en compte. »
Oui, le fait est qu’avoir deux versions de retard rend un navigateur obsolette.

« C’est quoi la bonne méthode
pour toi là dessus ? »
N’utiliser des rustines que si necessaire. Tes 2,5Ko (http://ge.tt/4NILmby?c) ne concernent que des cas particuliers, il ne faudra les utiliser que dans ces cas particulier. Je ne pense pas que l’idée de faire bien les choses en ne chargeant que ce qui est nécessaire est lié à JSON.

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.)

« Qualifies « bien » ? »
Ce qui est avantageux ou utile à une fin donnée. Ce qui possède une valeur morale, ce qui est juste, honnête, louable.
Mon exemple ne t’a pas suffit ?

« Dans ton exemple tu as sur-architecturé au départ. »
J’ai juste transcrit la façon de faire d’XML.

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

Tu veux dire que c’est pas optimisé de répéter 20 fois prix ? C’est marrant, c’est justement ce que je reproche à XML. En JSON, tu choisis une architecture pertinante (ou pas, c’est ton problème) selon le besoin, en XML on t’en impose une lourde).

« Le fait que dans 5 ans on aura du support n’est pas pour moi un argument pour choisir maintenant un format. »
On l’a déjà le support, Dieu merci, on a pas attendu de convaincre les gens avant de profiter des avantages de JSON.

« Je râle toujours autant contre la sur-utilisation de XML à des endroits où c’est stupide notes bien ;) »
Et moi sur les vérités générales établies sur des exemples biaisés.

Répondre
Éric D.

13 mai 2011

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

Répondre
laurentj

13 mai 2011

Si tu aurais dis du mal de YAML, j’aurais applaudi des deux mains, tellement le format YAML est complexe, voire stupide, et même inconsistant dans sa spec, au fil des versions . Mais là au sujet de JSON, je ne suis pas tout à fait de ton avis.

Que ce soit lisible ou pas par un être humain, je m’en fiche royalement dans les deux cas qui nous concerne, car pour moi, JSON et XML, c’est équivalent en terme de difficulté de lisibilité, avec un leger avantage à json (et beaucoup moins pire que YAML avec tout ses caractères spéciaux possibles et inimaginables)

JSON et XML n’ont pas tout à fait le même usage. Et en tant que développeur, je préfère parfois du JSON plutôt que du XML. Pour la bonne et simple raison que c’est beaucoup plus simple à *utiliser*. Coté JS, évidement. Aller chercher une valeur dans une structure JSON est beaaaauucoup plus simple que de manipuler les éléments DOM (et je ne parle pas aussi de la solution parseur SAX avec le XML, mouahahah). Idem coté serveur (ou autre), sachant que les parseurs transforment en général le contenu en objets du langage hôte. En PHP, avec JSON, je n’ai pas à utiliser une lourde API comme DOM pour manipuler le contenu (ne me parle pas de simplexml, on arrive à faire que la moitié des choses, et encore, quand ça bug pas).

Répondre
Christophe Jean

13 mai 2011

« Je parle de la virgule en fin de ligne. Qui n’est pas toujours systématiques. »
Comme dans le cas des arguments de fonctions, d’où la mise en parallèle des deux.

« Parce que moi j’ajoute/supprime/réordonne souvent des items dans des listes »
Moi aussi, mais dans ce cas, tu bouges les éléments, pas les virgules. Et encore, ça c’est encore et toujours quand tu fais tes modifications « à la main » ce qui est pas conseillé, que ce soit en XML ou en JSON.

« 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 »
Non. Je l’ai prouvé dans mes exemples précédents ! JSON permet de faire la même chose également mais ne l’impose pas !

« C’est peut être vrai mais ça ne retire pas le critère de ma grille de choix et de ses implications. »Ben si parce-que moi je n’ai pas ses problèmes là vu qu’on utilise sans doute pas les mêmes outils. Donc si le problème concerne certains outils, ça ne concerne pas JSON en soit. Si j’utilise le bloc note Windows pour modifier le XML et que je dis que XML est pourri parce-que sous le bloc note Windows c’est vite illisible et ça entraîne des problèmes de charset et encoding, il serait injuste d’imputer la faute à XML.

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

Tu as le droit en effet de donner ton opinion, mais pas d’en faire une vérité générale. Dans ceux qui commentent ton billet, je ne vois personne qui trouve le JSON moins lisible que l’XML par exemple.

« Sauf que 1- Google a des contraintes très différentes de la plupart des gens »
Ben si à qualité égale j’ai le choix de faire un truc léger ou lourd, j’aurai tendance à prendre le léger, même si ce n’est pas une obligation.

» 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. »
C’est un choix politique de la part de Twitter, vu qu’ils ont mis fin au support après avoir recommandé aux développeurs d’utiliser JSON (http://groups.google.com/group… ) ce n’est donc pas une conséquence mais une volonté. Mais bon, j’ai pris ces exemples comme j’aurai pu en choisir d’autres comme Freebase, MongoDB etc.

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

Toujours pas.
Pour les vrais tests bien plus précis, factuels, tenant compte du fait qu’il existe différents parseurs (et ne faisant ni la promotion de JSON ni celle d’XML), c’est par ici : https://github.com/eishay/jvm-…

Et encore, c’est en admettant que tu veuilles utiliser le DOM sans autre transformations dans ton code (coûteuse en ressources) et donc accéder à l’information avec ce genre de codes
person.getElementsByTagName(« name »)->item(0)->innerText(); //ou equivalent
plutôt que
person->name;

Mais dans tout les cas, il ne faut pas être un ingénieur pour savoir qu’un fichier plus lourd chargé en mémoire prendra plus de place qu’un fichier plus léger.

« Quels avantages ? »
Souplesse, poids, simplicité, possibilité d’avoir des propriétés composées sans avoir à modifier tous les codes qui en dépendent (voir mon exemples précédent concernant l’ajout d’un auteur)Maintenant que j’ai répondu à ta question, je t’invite à répondre aux miennes (précédemment écrites) à savoir me citer un langage où JSON n’est pas utilisable (et où il faut réinventer la roue comme tu l’as dis) et un moyen de pouvoir ajouter une propriété composée à ta liste de chaines de caractères sans devoir modifier ton code.

Répondre
Éric D.

13 mai 2011

» 2- Mouais. Je vois juste que sur deux sources que tu donnes comme référence d’autorité, une ne parle pas ni de légereté ni de performance ni de souplesse mais juste de « plus utilisé » et l’autre je n’ai pas de lien. Les deux ont un contexte qui est très spécifique par rapport au site moyen (même gros). Autant pour les exemples.

« Toujours pas.Pour les vrais tests bien plus précis, factuels, tenant compte du fait qu’il existe différents parseurs (et ne faisant ni la promotion de JSON ni celle d’XML), c’est par ici : »

Oui, si tout est natif effectivement. Sauf que justement ça ne l’est pas toujours. Dans au moins 15% des cas (en étant conservatif) tu tombes sur du eval() ou une lib d’interprétation js, et là ce n’est pas du tout comparable avec plusieurs analyseurs en JVM. Je compare la réalité, pas la théorie si on était ailleurs que dans le web.

« codesperson.getElementsByTagName(« name »)->item(0)->innerText() »

Parce que ceux qui ont codé des libs js avec un analyseur syntaxique complet pour JSON n’auraient pas été capables de faire une sérialisation/désérialisation en 20 lignes à base de boucles et de getChildren pour ensuite hydrater des objets javascript ?

« Maintenant que j’ai répondu à ta question, je t’invite à répondre aux miennes (précédemment écrites) à savoir me citer un langage où JSON n’est pas utilisable (et où il faut réinventer la roue comme tu l’as dis)’

Dans la vie réelle ? Au moins 15% de implémentations javascript utilisées par exemple (sauf à utiliser eval() mais ça a d’autres conséquences). Environ 30% des installations PHP (5.1 et inférieur). Ruby il n’y a de json ni dans le core ni dans la lib standard, il faut aller chercher des libs tierces dans les gem, et les faire installer si elles ne le sont pas par défaut (cas vécu). Je ne te cite là que les trois langages que j’utilise régulièrement.

« et un moyen de pouvoir ajouter une propriété composée à ta liste de chaines de caractères sans devoir modifier ton code. »

Comme dit dans le billet, ça t’ouvre des portes et ça recule le problème. Tu finiras forcément par butter dessus au bout d’un moment si tu évolues trop. Au pire, ce que tu as fait en JSON reste possible à faire en XML. C’est juste que tant que tu n’arrives pas là, au moins tu as d’autres solutions qui ne demandent rien à modifier.

Mais j’ai l’impression qu’on tourne en rond donc je vais m’arrêter là. On rejoint le billet suivant puisque j’aurai probablement coupé à la hache tous les commentaires sauf celui de JSONP si je m’écoutais.

Répondre