Article publié sur : https://www.geekzone.fr/2017/05/23/json-feed-un-successeur-pour-le-rss/
Manton Reece et Brent Simmons en avaient assez de voir certains développeurs Web pester contre le RSS et son formatage XML. Pire, ils avaient peur que la disparition des flux RSS s’accélère à cause de ce problème. Au lieu de pleurer sur Twitter, ils ont fait un truc rare de nos jours : ils ont…
4 « J'aime »
Et of course, je vais faire en sorte d’avoir ça en place pour GZ très vite. 
Tu veux dire que @MisterP va devoir renoncer à une de des nuits de débauche ? 
1 « J'aime »
J’attends que ça arrive sur le repo WP en fait. 
#flemme
J’ai du mal à croire que sortir un nouveau format incompatible soit la solution pour sauver RSS. Surtout que de ce que j’ai compris, l’abandon progressif de RSS est plus du à des raisons économiques que techniques. Et qu’on trouve des parsers XML dans a peu près tout les frameworks maintenant. Et je dis ça alors que suis normalement plutôt du genre à pester constamment contre l’emploi du XML pour tout et n’importe quoi!
Mauvaise bonne idée… XML est un bon outil pour les standards d’interopérabilité (grâce à XSD). JSON en revanche n’est pas mûr pour ce genre d’usage, voire même pas fait du tout pour ça à la base. JSON c’est fait pour porter des données peu structurées, et peu standardisées.
La “mode” du JSON issue de son usage naturel en JavaScript n’en fait pour autant pas un bon outil de description des données pour RSS. Ce que les devs Web/JS vont gagner d’un côté (et encore… parser du XML en JS c’est pas comme si c’était dur), les devs natifs vont doublement le payer de l’autre (les parseurs JSON c’est un peu la galère vu qu’il n’y a pas de notion rigide de schéma).
Je fais sûrement vieux con, mais je souhaite du courage aux gens qui vont vouloir maintenir ça sur plus de 3 versions différentes, avec 14k paquets NPM pour juste afficher une pauvre liste de news.
Je suis à peu près du même avis (même si les schémas JSON ça existe aussi).
Le gain espéré me paraît extrêmement faible au vu de l’objectif qui consiste quand même à remplacer un standard extrêmement bien établi.
D’autant que l’usage que ce nouveau format est censé simplifier (la lecture du flux directement depuis le JS d’une page web) me paraît assez douteux en terme de design et d’efficacité.
(et pourtant moi non plus je n’ai pas d’amour en trop pour le XML)
Tout pareil que les 2 monsieurs au dessus. RSS c’est pas parfait, mais json c’est pas non plus revolutionnaire.
Ca me rappelle beaucoup ca :
4 « J'aime »
idem que les 3 messieurs du dessus, je n’apprécie pas particulièrement le XML mais on trouve dans tous les langages de quoi le parser efficacement. J’ai vraiment du mal à voir le gain du json dans ce cas là.
La meilleure explication reste encore celle de xkcd 
Amusant vu que le même comics est linké par un des inventeurs du JSON Feed.
Les devs répondent à une demande intéressante d’autres devs, qui peuvent pas voir le XML en peinture. Des devs qui bossent sur ce genre d’outils et manipulent du JSON all day. Ca coute rien, c’est open, ça marche tant mieux, ça change rien tant pis. Les raisons économiques côté RSS ne touchent que qq sites de merde et ça n’empêche pas de faire un flux propre pour les sites avec paywall par exemple. Ce que n’arrivent même pas à faire la plupart des sites du genre. Pire, le RSS peut contenir des pubs. Le JSON aussi. Bref, y’a plein d’options, mais c’est des “démarches”. Et ça serait bien que les webdevs s’en occupent…
Au moins, au lieu de râler et rien faire, ils avancent. Vu l’estime que j’ai pour ces mecs depuis des années et les premiers suiveurs, je pense que c’est une excellente idée. Also, double URL possible :
C’est bien d’avancer, mais c’est mieux de le faire dans une direction qui sert à quelques chose. 
Effectivement il ne font de mal à personne.
On est juste quelques uns ici à penser que le problème qu’ils cherchent à résoudre n’existe pas vraiment et que leur solution n’est que marginalement meilleure que l’existant.
L’excuse du « on ne veut pas parser du XML » est réellement bidon, sans rire.
Sauf à vouloir le faire en Javascript, mais là, encore une fois, je veux bien qu’on m’explique le use case qui le justifie.
Je ne suis pas codeur, je ne peux que juger via les retours de la communauté concernée (ceux qui codent des softs pour vous) et de mecs avec des CV qui font le taf. Eux trouvent ça cool. Sans parler de l’historique des 2 créateurs. Vu les merdes que je vois tous les jours dans mes feeds (côté code), me soutenir qu’il n’y a pas de problème ne fonctionne pas.
Ensuite et sans vexer personne, vu que certains commentent sans lire les news, je sais pas si vous avez vraiment lu et creusé les specs, du coup.
Pourquoi, qu’est-ce qu’on a dit comme bêtise qui était contredite par les specs ?
(tu peux y aller, on est là pour discuter, pas pour se vexer)
Ah je sais pas justement, cette remarque est en relation avec le premier paragraphe de ma réponse précédente.
Update :
hop, Inoreader est aussi dans le coup.
Donc oui, y’a plein de trucs dans les specs a priori :
JSON is lighter and much more resilient to errors when compared to XML. To you, the user this translates to faster operation and much less failing feeds. If you take a look at the screenshot above, you will notice that I have a folder « Feeds with issues ». That’s because everyday we have to debug broken XML feeds… I really hope that someday this will be history.
JSON Feed also aims to fix a century-old problem - The Clone Wars by making the item id mandatory. We salute this decision! I am sure everyone has seen it in every RSS reader when an item repeats itself over and over again or a whole feed dumps its last 20 items as new. Yep, we want that to become history too.
Dans les contre rss et atom font deja un tres bon boulot.
Rajouter un troisieme format quand presque plus personne utilise le rss c est tendus …
Dans les positifs certains sites dont reddit ont une api en json qui permet de recup des datas facilement et c est quand meme bien pratique …
Wait and see …
Aucun risque pour ma part, c’est juste que je cherche à comprendre (voire à être convaincu).
En cherchant un peu plus :
- La simplicité du format permet une meilleure lecture à l’œil nu / débogage
- Il y a pléthore de fonctions pour transformer tout type de structure de données en json (et inversement)
- Rendre l’Id obligatoire, je ne savais même pas qu’il ne l’était pas dans les specs rss/xml ^^; Donc là c’est clairement un gros plus oui
- Et surtout : les specs lèvent également quelques limitations du rss/xml, genre plusieurs « attachments » au lieu d’un seul, et un typage(ce n’est pas le bon mot, mais je ne trouve pas mieux) de certains objets comme les icones, favicon, images pour éviter de passer par des astuces pour contourner la limitation rss/xml, mieux adapter aux pratiques modernes
Donc effectivement, j’ai été trop vite dans ma réponse, my bad.
2 « J'aime »
Les deux derniers points vont dans le bon sens, je suis entièrement d’accord, mais ils pouvaient tout aussi bien se faire par une évolution mineure de la norme existante.
Il y a sur Hacker News un thread extrêment intéressant où de nombreux argument pour et contre ce passage au JSON sont explicités en détail: JSON Feed | Hacker News
A lire pour comprendre un peu mieux l’historique et le contexte. C’est un peu technique mais même un « plumitif non-codeur » devrait y trouver des choses intéressantes.
1 « J'aime »
Les critiques qui pointent du doigt les problemes avec une nouvelle spec n’ont pas tord:
- Ca fait une spec en plus
- Ca fait genre “les hipsters ils aiment pas l’XML parce que c’est vieux, et comme c’est vieux c’est nul”, ce qui est une facon de penser assez commune et regrettable chez les devs web de nos jours (il suffit de voir l’evolution des frameworks JS, c’est a la fois hilarant et triste)
- etc.
Mais pour moi ces critiquent passent a cote du point le plus important, la facilite a developper, et de ses (potentielles) consequences.
D’abord, c’est bien joli de dire que tous les languages ont des bons parseurs XML. Oui, c’est vrai, mais il faut voir ce que ca vous crache derriere. Premierement, ca vous donne un arbre d’objets a naviguer avec des nodes, de attributs, etc. Y’a les namespaces qui foutent le boxon dans toutes vos queries parce que ca change le nom des nodes… ah, vos extensions pour Atom ou RSS qui permettent de mettre des attachements ou des infos supplementaires ne marchent pas? Est-ce que vous avez la bonne URI pour les namespaces d’extensions? Est-ce que vos requetes XPath sont foirees? Et j’en passe… serieux, 80% des errors de flux sont a cause d’XML malforme.
En comparaison, le JSON dans tous les frameworks, c’est un appel de fonction et vous recuperez un dictionnaire. Y’a un seul moyen de le consommer, parce que c’est rien de plus que ca. Apres oui le manque de schema ne va surement pas empecher de generer des JSONFeeds malformes non plus, mais les questions a se poser se resumeront plus ou moins seulement a “est-ce que c’est le bon nom de clef?”.
C’est pas un hasard que les devs de lecteurs RSS implementent tous le support pour JSONFeed aussi rapidement: d’abord, c’est tellement facile que ca leur coute rien. Mais aussi, c’est parce qu’ils esperent tous pouvoir passer leurs journees a faire autre chose que d’ecrire des hacks pour gerer du XML moisi.
Mais c’est la qu’on arrive a l’idee interessante de JSONFeed. Vous savez pourquoi les 99% des tutorials de dev sont: une TODO list, un blog, ou un client Twitter? C’est parce que c’est facile a faire, et que ca semble vaguement utile. Maintenant, que va-t-il se passer si un quart de ses tutorials devenaient un client JSONFeed basique? Ca pourrait potentiellement remettre ce genre de truc dans l’esprit de la prochaine generation de codeurs et, du coup, faire lentement remonter le nombre de gens qui s’y interessent.
Est-ce que ca va marcher? J’en sais rien mais franchement on s’en fout vu que, justement, ca prend meme pas 5 minutes de rajouter un JSONFeed sur son site, et, apparemment, pas bien plus pour le rajouter dans une app de lecture de flux. Grosso-modo, ca prend plus de temps de raler dessus que de le faire et de croiser les doigts.
Apres, si vous avez d’autres idees pour stopper la centralisation rampante du web, je suis preneur aussi, hein.
6 « J'aime »
Amour et brohugs
1 « J'aime »
Dans mes bras…
Dans le genre « le saviez-vous » le RSS dit que dans la balise « author » il faut mettre un mail
https://validator.w3.org/feed/docs/rss2.html#ltauthorgtSubelementOfLtitemgt
et que le nom de l’auteur doit être dans « dc:creator » mais il faut le namespace adéquat parceque c’était pas prévu à la base
Sauf que tu te retrouves avec des RSS où les mecs mettent juste un nom dans « author » sans mettre de « dc:creator »
Tu as ceux qui le mettent au bon endroit mais ne déclarent pas le namespace (GZ via Feedburner par exemple)
Et puis ceux qui ne mettent pas d’auteur du tout.
C’est juste un exemple tout con hein. Des cas particuliers comme ca tu en presque partout dans un rss. Bref, c’est le bordel et les parsers que tu trouves (magpie, simplepie, etc…) ont tous des manières différentes de gérer ça.
Avoir une alternative qui essaye de normer ce bordel qui s’est construit au fil des ans avec pleins d’ajouts successifs c’est pas plus mal.
/my 2 cents de pas dev
3 « J'aime »