Eh? It's not like teams of elves are tripping over hand-coding this stuff. And even if they were, JSON parsers tend to be way more strict than RSS readers (which are actuakly very liberal interpretations of XML). But again, nobody in their right mind is manually generating or templating this stuff. And if you are, there are a dozen RSS-gen libraries for every single language. Let one of those handle it for you.
Doing this in JSON does not suddenly mean you don't need a convention (aka standard) for fields and types. It's data exchange. The reader needs to know what your data means. You still have pubdates, links, titles, descriptions and you still need to label them in a semi-strict way somehow.
All in all, JSON will save you a few bytes but it would just be another standard on the pile, just with no libraries around to write the RSSJSON format.
I'll be honest —and it'll make me sound like an arrogant dbag— but that doesn't pass my sniff test. "jsonfeed" is lighter than equivalent RSS for several small reasons.
Can I see?
(To be clear to anybody reading this out of context: I'm not claiming that JSON is best —far from it— just that I would expect it to be a few bytes lighter in transit.)
Thank you for sharing that. It took me a little while before I noticed it, but your JSON files have more data.
Each item has a id, date_published and tags field which do not feature in the RSS. Together these account for around 250chars per item or 3750chars per 15 item feed. Cut out those fields and the JSON would be 850chars shorter.
Also, you're preserving tab and newline characters around HTML. This affects JSON more because a newline is valid between RSS tags. In JSON a newline becomes two characters "\n", as a tab becomes "\t". Going "spaceless" on output would save you 1372chars from your JSON feed (and half as much from RSS/ATOM).
I will confess, my sniff test didn't account for using quite as many HTML attributes as you do :) Escaping double-quotes costs you 334 in JSON.
The overall difference is much slighter than I had expected.
Doing this in JSON does not suddenly mean you don't need a convention (aka standard) for fields and types. It's data exchange. The reader needs to know what your data means. You still have pubdates, links, titles, descriptions and you still need to label them in a semi-strict way somehow.
All in all, JSON will save you a few bytes but it would just be another standard on the pile, just with no libraries around to write the RSSJSON format.
JSON doesn't fix XML.