Atom is technically substantially superior to RSS. RSS is riddled with ambiguities which lead to inconsistency of interpretation, and being outright unable to express some useful things.
My favourite is the format of all content: is it HTML or text? RSS doesn’t care, and leaves you to guess. So people added a namespace to fix that up, and you end up with what I think is normally spelled <content:encoded> to replace <description> or whatever it is—but there’s no equivalent for other content fields like titles. And because you can’t trust that tool will use <content:encoded>, now you need both. (And when you get to podcasts, the theme of the day is having the same field expressed in four or five different namespaces for different tools, in some cases for things that Atom has but RSS lacks.)
I have an article on my blog entitled <_>::v::<_>. I expect that a few RSS readers would mangle it if I served an RSS feed, but I serve an Atom feed, so I can express the title correctly:
(Bet you didn’t anticipate the <code> wrapping of that title! Now try that in RSS!) Anyway, NewsBlur got it right, and if any other client gets it wrong I can point to it and say that it is unequivocally a bug, whereas with RSS… eh, there’s enough ambiguity to drive a spaceship through, so what does “bug” even mean?
I hate the way that feeds are so commonly generically called “RSS”, because it gives mindshare to the bad and inferior product.
The only reason you should ever use RSS feeds is because you’re dealing with podcasts, because Apple sadly ignored the emerging Atom format when they did podcasts in iTunes in 2005, and annoyingly froze things in time there and then, and everyone else stupidly followed them, so that most of the major podcast things don’t support Atom… even if they sometimes claim to. (Like validation tools that allege that Atom is fine, butcher it completely if you give it to them, and report false results like that this RSS feed is fine or whatnot.)
I am a paying NewsBlur customer and like it very much.
It is, however, too picky about atom/rss - if you have a feed with some wrong entries (e.g. the one from freshcode.club) it will discard the problem items without a warning while still showing the valid items.
My favourite is the format of all content: is it HTML or text? RSS doesn’t care, and leaves you to guess. So people added a namespace to fix that up, and you end up with what I think is normally spelled <content:encoded> to replace <description> or whatever it is—but there’s no equivalent for other content fields like titles. And because you can’t trust that tool will use <content:encoded>, now you need both. (And when you get to podcasts, the theme of the day is having the same field expressed in four or five different namespaces for different tools, in some cases for things that Atom has but RSS lacks.)
I have an article on my blog entitled <_>::v::<_>. I expect that a few RSS readers would mangle it if I served an RSS feed, but I serve an Atom feed, so I can express the title correctly:
(Bet you didn’t anticipate the <code> wrapping of that title! Now try that in RSS!) Anyway, NewsBlur got it right, and if any other client gets it wrong I can point to it and say that it is unequivocally a bug, whereas with RSS… eh, there’s enough ambiguity to drive a spaceship through, so what does “bug” even mean?I hate the way that feeds are so commonly generically called “RSS”, because it gives mindshare to the bad and inferior product.
The only reason you should ever use RSS feeds is because you’re dealing with podcasts, because Apple sadly ignored the emerging Atom format when they did podcasts in iTunes in 2005, and annoyingly froze things in time there and then, and everyone else stupidly followed them, so that most of the major podcast things don’t support Atom… even if they sometimes claim to. (Like validation tools that allege that Atom is fine, butcher it completely if you give it to them, and report false results like that this RSS feed is fine or whatnot.)