Do you prefer RSS or Atom?

[Saif]

I maintain both an RSS and Atom feed for reasons unknown to even myself, but something I've noticed is that Atom feeds are just not popular at all from what I've seen.

I think the reason why is because there's a surprising lack of anything that talks about Atom feeds or explains how to make one besides using a static site generator. It makes me pretty sad because Atom feeds support relative URLs which is a huge plus for me!

The only tutorial I could find used invalid markup as an example which made my feed unusable, and the other page I could find was the W3C page about it, which is nice, but it'd be really nice to also see more cool guides about how to make an Atom feed, which I did make one, but still. :'(

I do admit that RSS is easier to use overall, though. You dont have to create a specific type of ID, and then try to figure out the weird format you have to use for the date, and stuff like that. There also aren't as many tools like RuSShdown for Atom (or I haven't seen any. Sigh.)

Anyways, enough rambling. Let me know your thoughts! If I had to choose between the two, I'd say Atom.

[schlime9k]

It's all a matter of preference, but for simplicity sake, I prefer standard RSS, though Atom is generally considered a better, more "standardised" protocol.

The thing is, around 99% of readers (very fake percentage) all read both RSS and Atom perfectly, so it doesn't matter in the slightest which one you use on the consumer side of things. So whichever one you wanna use, go 'head! It's probably a good thing Atom is very strict when it comes to validation, because my RSS is, unsurprisingly, not up to RSS validation standards :(

[lakes]

I only know how to code standard RSS. So when it comes to my personal website, I just use that. But if I'm subbing to a feed and it lets me select between Atom and RSS or even those 2 and RDF, I always choose Atom.
It doesn't matter too much. But I hear it's more secure so * shrugs *

[Dan Q]

Atom is the better-written standard. RSS is the better-established standard.

I don't think it matters much nowadays. Readers tend to be agnostic. Pick one for your site; both only if you're using an SSG or CMS!

[Xyphien]

I've grew up with RSS so I'll always prefer that to be honest!

[Saif]

Yeah, it doesn't really matter in the end, but Atom feeds are pretty nice. I'll always have love for RSS in my heart, too. :-)

Pick one for your site; both only if you're using an SSG or CMS!

Sigh... I might have to forfeit my RSS feed after all, haha.

[candycanearter07]

i dont really care, if a site has both i basically just flip a coin to see which one i actually add

[xwindows]

which I did make one, but still.

That URL gives 404 error though; please update it to point to the one on your new site, so people could actually read that.

Atom feeds are just not popular at all from what I've seen.

there's a surprising lack of anything that talks about Atom feeds or explains how to make one

One big part of the reason is because people often conflate "web feed" with "RSS feed" (effectively burying Atom in their conversation); and I had to remind them every time that they are not the same thing.

RSS, while being the first, is also the hackiest one-- and definitely not the one you should choose by default when making a new feed for reasons I'll get to below.

to figure out the weird format you have to use for the date

Not for me: I live in 24-hour-time country, and ISO 8601/RFC 3339 (especially its space-separated "YYYY-MM-DD HH:mm:ss +ZZZZ" variant (0) ) is actually my preferred date-time format for all computer-related works.

create a specific type of ID

It is actually a feature, not a bug. The requirement of unique ID is actually what makes many Atom feeds avoid the most basic "beginner's mistake" plaguing many RSS feeds (1); and I would argue that shoehorning "tag:" URI there, like in your article, is basically repeating RSS' mistake.

Use real opaque UUID instead (the `urn:uuid:`-prefixed one). As I live on path of the Free and use GNU/Linux, I simply run `uuid -v4` on command line, and copy-paste whatever it output as a UUID of my new entry. I actually configured my preferred graphical text editor to have a hotkey to insert such value too.

Do you prefer RSS or Atom?

When creating feed and I have choice, I always use Atom; always.

And if you hand-craft your feed, I will even go as far as saying: you must use Atom, else you would end up hating yourself down the line. All feeds I have on my websites are hand-crafted; I say it from experience.


RSS is full of pitfalls and hackiness. Its hackiness would come to bite you (1) as soon as you started doing anything more advanced than bare-minimum headings+dates. Because you know: RSS cannot distinguish between summary-only feed and full-content feed.

The official RSS spec, even the latest 2.0 one, supports just summary-only feed. As a result, there is no real facility to support full in-feed content; let alone rich text/HTML content there. Absolutely none, I'm serious. There was nothing to say that the entry's "summary" was actually a summary or rather full content; and nothing to distinguish that the inside was actually text, HTML, or any other exotic thingamajig.

Yet, people have long abused it by shoehorning not just full text content, but full HTML content in there (complete with XML entities escape "fun"); and feed reader had to do heuristic "guess" which kind of content type the entry was supposed to have, in order to parse and display. Doesn't that horror sound familiar? (2)

And with nothing differentiating summary vs. full content in RSS: this deficiency leads to UI compromises in feed readers down the line, like always having to show button offering to "Load full content" when the feed was RSS, even in the occasion that what's displayed was already a full content that webmaster shoehorned in. Feed readers will also have to provide a per-feed configuration toggle for user to manually choose between displaying in-feed entry as-is or always load and display from permalink URL, because the feed reader was none the wiser when the feed was RSS.

This also lead to confusion and mental toll on user's side too; because for every in-feed RSS entry he sees in the feed reader, he can't always be sure if what's displayed was a actual content: he had to scroll to the end of entry to check; every, single, time.

In Atom? If you wanna tease, write `<summary>`. If you wanna throw full content, write `<content>`; and not just explicitly-declared text and HTML: there are even proper way to include binary content of arbitrary MIME type, in-feed, or via external payload file. If you wanna let user decide which one to view in-reader, write both; behaviors are defined, predictable; allowing feed readers to Do the Right Thing (TM) with sane defaults.


And remember what I said about: complete with XML entities escape "fun"? I will argue that this is the part that makes a lot of people absolutely hate handcrafting RSS feed (and ultimately lead to them omitting feed from their sites); because writing in-entry content/summary with entity-escapes (or even CDATA hacks) is just gnarly. Validation also can only be checked with specialized tool that specifically handled RSS, and editor's syntax highlighting won't work with the escaped/CDATA'd payload. It's just terrible to write non-bare-minimum RSS by hand.

But in Atom? You just declare XHTML as entry content type, put in `<div>` with a correct `xmlns=` attribute, and then type or paste your HTML body content (3) in as-is. Regular XML validation tools, as well as your editor's syntax highlighting will also continue to work with Atom, down to the inside of each entry's content.

And if you ended up editing your page, you just copy-paste new HTML body content into the feed entry (replacing the old one); update timestamp of the entry and the feed; save and upload. No lengthy re-escaping work.

Choosing Atom means doing away with those nastiness and hacks in RSS; and developers of every feed reader software will thank you for doing so.


Also, niche area: have you ever offered extra downloadable goodies in your feed entry? I have.

Both RSS and Atom support file attachment in feed entry (called "enclosure" in the literature). If you use RSS however, there is another catch: RSS only officially supports maximum 1 attachment per entry. The support was even there at all just to allow attaching audio/video file for podcasting.

There is no such limitation in Atom; you can add any number of extra DLC you want to a single feed entry, and this is exactly what I do on my art site. If your feed was an audio/video podcast, it meant you could provide multiple audio/video formats too, without having to provide separate feed for each of them. This is another area that Atom is just simply better.


(0) And this (YYYY-MM-DD HH:mm:ss) is the date format I actually hacked MelonLand forum to show whenever I logged in. I said hacked, because it's not officially supported, and I had to go under the hood to add that in as my own PHP `date()` escape string.

(1) RSS' hackiness would even bite you long before adding in-feed content/summary, if you renamed any entry/page and its associated SEO-friendly URL that is/was previously appeared in your feed. Unlike Atom; RSS doesn't force you to put a real unique ID in the feed, so feed reader couldn't track that this was the same old entry that was simply renamed-- such renamed page would simply appear to your followers as a brand-new RSS entry; wasting time and killing anticipation of everyone involved.

(2) In the olden days of late 1990s-2000s, web server assigning wrong MIME type to HTTP response was a relatively common occurrence; so browsers (especially Internet Explorer) would guess the actual MIME type from the file data in response body and disregard what the server said in the HTTP header. It goes without saying that eventually, cracker crooks got ideas to start exploiting these guessworks.

Code

https://www.adambarth.com/papers/2009/barth-caballero-song.pdf

(3) You have to write to HTML page with XHTML tag-closing style though (which HTML5 does allow), in order to use this least-effort copy-paste shortcut.

[nobo]

RSS, while being the first, is also the hackiest one

IMO you have to pick your battles. You're not wrong, and lack of consistency across feeds requires you to have to do all kinds of parsing and handling special cases for how different people do their feed.

But at some point you have to admit, writing that code to handle all those cases is more realistic and easier than the uphill battle of trying to get people to not use RSS.

I have a feed reader for my website. It's very simple.

Code

const RSS = {
        RisingThumb: 'https://risingthumb.xyz/Writing/Blog/index.rss',
        dannarchy: 'https://dannarchy.com/en/rss.xml',
        chxshire22: 'https://chxshire22.com/feed.xml',
        punp: 'https://punp.neocities.org/RSS-feed.xml',
        porcupine: 'https://oldkidz-newblockz.neocities.org/rss.xml',
        splashy: 'https://splashy.neocities.org/feed.rss',
        neonaut: 'https://neonaut.neocities.org/feed.atom',
        ritual: 'https://ritual.sh/blog/feed.xml',
        starpelly: 'https://www.starpelly.com/index.xml',
        kepler: 'https://www.zomboid.pro/rss.xml',
        mercerweissx: 'https://www.mercerweissx.com/feed.xml'
};

const OPTIONS = {
        RisingThumb: {
                extractMetadataDescription: true,
        },
        porcupine: {
                latestUpdateOnly: true
        },
        ritual: {
                extractSummary: true
        }
};

You can probably imagine how it works. It's one file. It's easier to just write the code than to idealistically hope for the day when people will use Atom more than RSS.

[Saif]

Thanks for letting me know about the dead link... Totally slipped my mind!

and I would argue that shoehorning "tag:" URI there, like in your article, is basically repeating RSS's mistake.

Hey, don't look at me! I went off of W3C's introduction to Atom, which recommended using "tag:" URIs

Though, it's really good to know there's another way of doing it. I was bored out of my mind making each and every URI for my Atom feed. If only I knew beforehand... Anyway, I'll make sure to add this to my article. Thanks!

I doubt that the average person is going to open up a terminal just to generate a v4 UUID, though. Luckily, there's a bunch of online generators (that are full of ads, but whatever.)

But in Atom? You just declare XHTML as entry content type, put in `<div>` with a correct `xmlns=` attribute, and then type or paste your HTML body content (3) in as-is. Regular XML validation tools, as well as your editor's syntax highlighting will also continue to work with Atom, down to the inside of each entry's content.

I actually had no idea about that! Certain code formatters like Prettier use the XHTML tag closing style by default, so I wonder if i could use that instead of CDATAing everything. But I don't imagine many people use that specific formatter or are willing to modify their code to use XHTML closing tags.

I had no idea RSS had this many quirks, honestly. I did find myself losing my mind often at validation errors that are way too vague to do anything about, but things like the one attachment limit were unknown to me. There being no tag for full content also frustrated me, and the fact you're forced to use absolute URLs for everything.

[xwindows]

As I was tidy-editing my post above, I ended up adding too much stuff in one footnote; so I decided to cut that part out to continue here instead...

It goes without saying that eventually, cracker crooks got ideas to start exploiting these guessworks.

Code

https://www.adambarth.com/papers/2009/barth-caballero-song.pdf

From what I've heard, the exploits on content type guesswork was done by either sandwiching harmful content of format that browser supports, inside innocuous outer file format that the browser doesn't support; or by using polyglot file that can be read as two different file formats at the same time, one format with innocuous content, another with harmful content. CMS would accept such files (because they're apparently in the innocuous format); but once browser received it, the browser would try to check the file for content it supports --which usually end up matching the harmful part-- run it, and pwning the user.

This brings me back to the analog of this specific security issue in RSS feed (and why Atom is more secure)...

I always choose Atom.
It doesn't matter too much. But I hear it's more secure so * shrugs *

As RSS feed requires feed reader to do guesswork to determine in-entry content type; it means RSS feed readers are open to the same kind of security vulnerabilities around such content type guesswork.

For example: suppose there was a computer security blog that gave out a perfectly-valid RSS 2.0 feed, with plain-text summary of each post. Then one day, the webmaster started his post by reprinting `<script>` stanza with JavaScript virus code, as a subject of his autospy. On the HTML side, it was fine; because the thing was tag-escaped and would not run. But when the article got downconverted to plain text to be presented inside RSS entry's summary (1), the virus code was now shown there as-is.

So when one follower of the site opened that entry in his feed reader, the feed reader found such HTML-esque stuff in the summary so it guessed that the summary was likely to be HTML (in spite of the author's intention); and it started an embedded browser to show/run that summary --which was a `<script>` containing virus code-- as HTML... and you know the rest (in pieces); poor guy. And this wasn't even an intentional attack.

If the the feed was Atom, this sort of pwnage would simply not happen, because such plain text summary would be explicitly declared as `<summary type="text">` (2) and never got accidentally interpreted as HTML by feed reader or its embedded viewer/browser; thus the virus script would always get displayed (as the webmaster intended) instead of getting run and harm his follower.


(1) Remember, RSS' entry summary was originally designed just to be plain text. The HTML "support" is just a hand-waved stuff.

(2) Even plain `<summary>` without `type=` is equivalent to `<summary type="text">`; the Atom specification is very specific about this.