I think part of the issue with RSS is the real pain of dealing with XML. I'm mildly cheering for something like https://jsonfeed.org - which would be a big step towards making a decentralized system more of a reality.
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.
This does sound painful, unlike parsing ordinary XML.
RSS: 33,228
Atom: 43,433
JSON: 36,137Can 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.)
http://boston.conman.org/index.atom
http://boston.conman.org/index.json
http://boston.conman.org/bostondiaries.rss
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.
Beyond that, you can use powerful tools like namespacing, schemas, XSL, etc if you want them, and they are also ubiquitous across most major programming language ecosystems. They add complexity, but so do their JSON analogues.
It seems that people often reinvent aspects of the XML ecosystem using JSON. For example, JSON Schema is like XML schema, OpenAPI is like WSDL, JSONPath is like XPath. That's not to say I don't support these efforts - I think it is great that people are developing powerful tools for JSON. However, I think there is a misconception that the XML ecosystem is less "à la carte" than the JSON ecosystem when it comes to these added complexities. You don't need to deal with them unless you need/want to, and then it is nice to have standardised, battle-tested implementations.
RSS: ~20 [3]
Atom: ~25 [3]
JSON: 1
gopher: 7
[2] My blog is also available via gopher, gopher://gopher.conman.org/
[3] Unique user agents---probably not the best metric, but for a quick scan, easy enough to check.
Edit: formatting