3 ms·

Is there a convincing argument for RSS over Atom in 2020 or the other way around?

jjjbokma 6y ago
There is also JSON: https://jsonfeed.org/ https://jsonfeed.org/ When I wrote my own static site generator [0] I added JSON first because it's dead simple to do so. Later I added RSS and it was quite some work to get it right ([1][2]), as in I wanted both the Perl and the Python version to output an identical feed. Last time(s) I checked, they do validate for my tumblelog [3] [0] https://github.com/john-bokma/tumblelog https://github.com/john-bokma/tumblelog [1] http://johnbokma.com/blog/2019/10/09/hand-coding-an-rss-2-0-feed-in-python.html http://johnbokma.com/blog/2019/10/09/hand-coding-an-rss-2-0-... [2] http://johnbokma.com/blog/2019/10/09/hand-coding-an-rss-2-0-feed-in-perl.html http://johnbokma.com/blog/2019/10/09/hand-coding-an-rss-2-0-... [3] https://plurrrr.com/ https://plurrrr.com/
- ectoplasmaboiii 6y ago
  Interesting posts, looking to make an RSS feeder myself, but in a more bizarre language! By the way, your personal website (if it's yours) is fantastic. Just the right amount of styling to make it look good.
  - feiss 6y ago
    Agree, the website is brilliant...
dgellow 6y ago
For a reader what matters is what is used in the wild.
avhon1 6y ago
I use RSS because it is very easy to write RSS 0.90 by hand. https://www.rssboard.org/rss-0-9-0 https://www.rssboard.org/rss-0-9-0
chrismorgan 6y ago
Atom is technically substantially superior. RSS is an awful hack that leaves far too much to chance, such as in not specifying the format of fields that could be HTML or text. Probably the most significant thing is that Atom encodes whether a field is text or HTML. If you want your feed item’s title to contain things that could be parsed as HTML (e.g. “how to use the <hr> tag”), you’re in for a miserable time: some feed readers will treat it as plain text; some will treat it as HTML (and then probably strip out the <hr>); some may even double-encode it (“how to use the <hr> tag”). If you use Atom, you can specify that the title is plain text, so that the intent is clearly conveyed, and any client that mangles it in any of the aforementioned ways (and I’m not going to rule that out, though I’ve observed fewer problems with handling of Atom feeds) is clearly and definitely wrong. You can also use this to deliberately write HTML in your titles, e.g. <strong>, <em>, <code>. I like to do that, especially for <code>. Most readers will probably subsequently strip the HTML (which is a bit of a shame for inline formatting), but the idea is nice anyway, and more importantly it makes it clear what the correct way of handling it is, rather than leaving it unspecified and hoping for the best. For normal feeds, I recommend developers use Atom every time. No need to subject yourself to the pain RSS engenders. However, there’s one place where you still need to use RSS: podcast feeds. Most podcast software doesn’t support Atom, despite the fact that at the time when all that software was written RSS had been obsoleted by Atom. The industry just doesn’t seem to have realised Atom exists, which is stupid: they all just keep on copying one another instead, and adding their own namespace both to add their own fields and to fix the shortcomings of RSS, so that if you follow all of the recommendations from Apple, Spotify, &c. &c. you’ll end up with most of the fields written out in 3–6 different ways (e.g. <foo>…</foo>, <itunes:foo>…</itunes:foo>, <spotify:foo>…</spotify:foo>, <something-else:foo value="…"/>, that kind of thing). Pretty much all progress in feeds happened between about 2002 and 2007. Roughly no documentation or review of the situation has been published since then. It’s a very unhealthy ecosystem. Summary: RSS for podcast feeds, Atom for everything else.

There is also JSON: https://jsonfeed.org/ https://jsonfeed.org/ When I wrote my own static site generator [0] I added JSON first because it's dead simple to do so. Later I added RSS and it was quite some work to get it right ([1][2]), as in I wanted both the Perl and the Python version to output an identical feed. Last time(s) I checked, they do validate for my tumblelog [3] [0] https://github.com/john-bokma/tumblelog https://github.com/john-bokma/tumblelog [1] http://johnbokma.com/blog/2019/10/09/hand-coding-an-rss-2-0-feed-in-python.html http://johnbokma.com/blog/2019/10/09/hand-coding-an-rss-2-0-... [2] http://johnbokma.com/blog/2019/10/09/hand-coding-an-rss-2-0-feed-in-perl.html http://johnbokma.com/blog/2019/10/09/hand-coding-an-rss-2-0-... [3] https://plurrrr.com/ https://plurrrr.com/

ectoplasmaboiii 6y ago
Interesting posts, looking to make an RSS feeder myself, but in a more bizarre language! By the way, your personal website (if it's yours) is fantastic. Just the right amount of styling to make it look good.
- feiss 6y ago
  Agree, the website is brilliant...

dgellow 6y ago

For a reader what matters is what is used in the wild.

avhon1 6y ago

I use RSS because it is very easy to write RSS 0.90 by hand. https://www.rssboard.org/rss-0-9-0 https://www.rssboard.org/rss-0-9-0

chrismorgan 6y ago

Atom is technically substantially superior. RSS is an awful hack that leaves far too much to chance, such as in not specifying the format of fields that could be HTML or text. Probably the most significant thing is that Atom encodes whether a field is text or HTML. If you want your feed item’s title to contain things that could be parsed as HTML (e.g. “how to use the <hr> tag”), you’re in for a miserable time: some feed readers will treat it as plain text; some will treat it as HTML (and then probably strip out the <hr>); some may even double-encode it (“how to use the <hr> tag”). If you use Atom, you can specify that the title is plain text, so that the intent is clearly conveyed, and any client that mangles it in any of the aforementioned ways (and I’m not going to rule that out, though I’ve observed fewer problems with handling of Atom feeds) is clearly and definitely wrong. You can also use this to deliberately write HTML in your titles, e.g. <strong>, <em>, <code>. I like to do that, especially for <code>. Most readers will probably subsequently strip the HTML (which is a bit of a shame for inline formatting), but the idea is nice anyway, and more importantly it makes it clear what the correct way of handling it is, rather than leaving it unspecified and hoping for the best. For normal feeds, I recommend developers use Atom every time. No need to subject yourself to the pain RSS engenders. However, there’s one place where you still need to use RSS: podcast feeds. Most podcast software doesn’t support Atom, despite the fact that at the time when all that software was written RSS had been obsoleted by Atom. The industry just doesn’t seem to have realised Atom exists, which is stupid: they all just keep on copying one another instead, and adding their own namespace both to add their own fields and to fix the shortcomings of RSS, so that if you follow all of the recommendations from Apple, Spotify, &c. &c. you’ll end up with most of the fields written out in 3–6 different ways (e.g. <foo>…</foo>, <itunes:foo>…</itunes:foo>, <spotify:foo>…</spotify:foo>, <something-else:foo value="…"/>, that kind of thing). Pretty much all progress in feeds happened between about 2002 and 2007. Roughly no documentation or review of the situation has been published since then. It’s a very unhealthy ecosystem. Summary: RSS for podcast feeds, Atom for everything else.