In practice, the differences between the syndication formats don't really matter. Today even less than when they were created, as a solution for most of the differences is just a prompt away.
In my humble opinion, JSON feed (https://www.jsonfeed.org/version/1.1/) is the most practical format. By a small margin, but still...
- it's really simple and doesn't use XML
- it doesn't allow stupid things like HTML in titles (which I guarantee >50% of all implementations can't handle correctly)
- JSON Feed allows feeds to have a <favicon> and a (square!) <icon>, which is a very practical thing for readers. You can use the <favicon> in lists of feeds, and the <icon> to present a single feed. Atom has a small square icon and a <logo> which is supposed to use a 2:1 aspect ratio. 2:1 is completely useless. No site has a logo in 2:1. It's also useless for most full-name logos, like 'New York Times'. (RSS is, of course, even worse; it doesn't even recommend an aspect ratio, practically guaranteeing that RSS readers can look bad)
You can see that JSON feed has been designed from a feed consumer's point of view: what does an RSS reader need to make a feed look good? While Atom and RSS have been written from an abstract publisher's point of view, making everything possible and allowing maximum flexibility. Especially RSS, which has shown its flexibility in becoming the de facto format for podcasts. And both Atom and RSS are really old, written at a time when it probably wasn't clear how RSS would eventually be used.
In the end, no matter which format a feed uses, users won't notice any difference (as long as publishers are smart enough to use square images!). So any feed is a win, no matter whether RSS, Atom, or JSON feed.
We accept that sentences can have formatting, and headings can have formatting, so why shouldn’t titles? When you look at titles that get used on platforms like YouTube, there’s obviously a desire for formatting. People use Unicode shenanigans to work around the deficit frequently. (And they do so in ways that are mostly only available for the English script, quite inequitable for other scripts.) Even if you were to restrict it to ASCII, people GLEEFULLY abuse capital letters FOR EMPHASIS!!!!1!
Especially once you get to coding topics, titles need to support <code>, which is important semantics.
(My biggest disappointment with Atom is that text constructs are single-type-only. I wish you could provide distinct text and HTML representations, like email does with the multipart/alternative MIME type. In some places where I use <code> in titles, I’d just drop the <code>…</code> wrapping, in other places I’d turn it into `…`.)
I will write a proper article about all this some time soonish, encouraging people to use markup in titles.
1. Because there are things you can obviously not put in a headline. Like a large image, a YouTube video, or a paragraph. Defining an HTML subset would make it somewhat usable. But letting each consumer of the Atom feed decide which subset they support will make such a title look bad on at least those renderers that don't support the same subset. No renderer can allow it completely (<script>...). HTML sanitation/injection becomes a much bigger problem when it's not limited to a text body that can be relatively easily sandboxed.
2. If you allow every feed to define its own font style or even color, that makes a list of posts look like a 2005 MySpace page. :)
It is producing bad UIs. Renderers can't really render it as plain text, as they might lose a part of the meaning. But they also can't really allow it because it might make their output look like trash. In the end, that would force renderers to develop complex heuristics of which elements and styles to allow, which to modify (do your HTML titles support dark mode? accessibility?), and which to filter out.
3. I don't see the practical value of having <code> in a headline. If it shouldn't be rendered in a different way for obvious reasons, and XML is not designed for human consumption, what is it good for? Who is the consumer of the <code> tag? AI?
(Not that I want to defend RSS. In early versions valid RSS wasn't necessarily even valid XML. It is very poor.)
The issue with RSS of course is that there is a lot of really crappy and ancient code out there that should have died a long time ago written in languages like PHP, Ruby, etc. by people who did not really care about details. Details like having unambiguous time stamps (what do you mean, you don't live in my time zone?), or details like "this text is not encoded in UTF-8 but in my unspecified locale specific ASCII variant" (why?!). Or indeed "this description contains malformed tag soup with some of the tags escaped".
Also, while most modern RSS and Atom parsers are pretty decent, it's not that hard to find feeds that still have parsing issues despite these frameworks giving it their best effort. Part of the reason is that the code that generates these feeds is a lot less well covered by frameworks. Lots of content management systems out there that use some wonky templating, home grown scripts, or other improvised shit to generate their feeds. That always was the biggest problem.
Over-polling is also a problem with both formats.
But the Local-First Fediverse is evolving. https://share.gemini.google/NHjiUHtpRTiJ
That's important and will break the walled gardens, and will change money flows I suspect as advertising revenue is more equitably shared with content providers, who themselves can be better paid for content produced and content promised. It's the 'ol centralization <> decentralization swinging back and forth again.
> Your client does not have permission to get URL /share/d8748f435799 from this server. That’s all we know.
What's this link meant to be about?
Even (especially?) as a person that appreciates Lisp, Lisp losing this fight twice is kind of funny.
Wonder if it’s going to happen an nth time with Guix vs Nix
After that, I was afraid to ask him to remove me too! I think I finally just moved on to another email address.
There's supposed to be a mailing-list-name-REQUEST email address just for administrative questions like that, but so many people now don't even know or support that, and just send removal requests to the whole list. Instead of complaining about people asking the whole mailing list to be removed, there's a much better passive aggressive strategy:
My favorite instance of emergent mailing list behavior was when a trouble maker named GUMBY created a "PLEASE-REMOVE-ME" mailing list, just for people who sent email to another entire mailing list asking to be removed from it, instead of sending their request to the administrator at mailing-list-name-REQUEST.
Whenever somebody would make that faux-pas, he'd add them to the PLEASE-REMOVE-ME mailing list, and the emergent behavior was that those people would discuss amongst themselves the fact that they really wanted to be removed from the PLEASE-REMOVE-ME mailing list, until they eventually learned that the way to get removed from a mailing list was to simply send email to PLEASE-REMOVE-ME-REQUEST, instead of the entire mailing list.
Worked like a charm!
Though you might be upset about RSS being used when your reader screws up with it, because some things are difficult to interpret. Of course, you won't know why it screws up, and you'll probably blame the person who wrote the feed, not the format itself.
It is XML, so not all HTML5 is allowed. You would have to convert your HTML5 to XHTML5. Possible but harder than string-concatenation.
It requires full self links, so you must put your domain name in there as relative links would be an error. When using a static generator, why should I care where the files are published?
My website has valid Atom feeds. Still, it's an annoying format to me.
I suspect you've been making your lifeIfe difficult for no good reason.
> why should I care where the files are published?
You don't, but those consuming your feed do. You do it for their benefit.
Apart from iTunes, as the article said.
It has been 20+ years I do hope someone on HN can now spills the beans as to why.
I liked thought the article as I never deep dived in the differences
The content of that notorious discussion went on and off and on and off for weeks, giving all the netizens of the RSS community blogosphere terrible headaches, with people's entire blogs disappearing and reappearing every second, until it finally reached a flashing point, when Dave Winer humbly conceded that it wasn't the user's fault for being an idiot, and maybe just maybe there was tiny teeny little design flaw in RSS, and it wasn't actually such a great idea to allow HTML tags in RSS titles.
This would give us some kind of leader that shows the way. It would make it easier for developers if people were more focused on fewer standards and there would be a well defined point in time when we would upgrade to the new set of standards.
For those of you who are familiar with RISC-V, it would be like the RVA23 spec: one big collection of things to use that can be targeted and talked about as one thing with one name, rather than everyone having their own collection of extensions that they use.
- what is the best way to store rss data inside postgres
- will you store it as raw xml directly? or will you process it and store it?
- what format will you store it as if stored inside postgres?
- how will you handle updates to the feed? rss doesnt do websocket push as far as i can tell so you have to poll which gives you the entire feed with a few items removed and a few new items added in the best case scenario. how do you diff this for storing?
Entries in feeds should have a guid you can use to detect updates/entries you have already seen. RSS readers typically don't delete entries that disappeared from the feed - entries disappear from feeds to limit their size.
You can get live updates to some RSS feeds using WebSub.
I get that ATOM is better in terms of being more consistent and the way it handles full content.
Is it true that RSS is simpler, and of you’re not publishing full html articles and other rich content, you don’t need the extra complexity?
Even the trivial case of trying to include "&" in a title is ambiguous and different clients will handle it differently.
TIL, I never questioned encoding >
Try putting a Betamax tape into a VHS VCR and see if you can watch it.
Atom can do < or & in titles, and offer both a summary and the full text.
Some podcast apps (Apple Podcasts) don't support Atom, so then plain RSS is better.
So it doesn't really matter that much.
Apple Podcasts stopped supporting Atom (sadly) a few years ago:
* https://podcasters.apple.com/4115-technical-updates-for-host...
Not sure why they decided to do so (lack of volume/traffic?).
https://en.wikipedia.org/wiki/JSON_Feed
Not every programming language I use can output RSS/Atom/XML by default, but pretty much all of them can output JSON natively, no library needed, just fine. The spec is short and easy to understand, to the point it’s little effort to manipulate the feeds, adding to them or consuming them even without a dedicated reader if need be.
To consume other people’s feeds, I mostly don’t care what format they are as long as my reader can understand them. To generate my feeds, I always use JSON. Most of them are for personal use, but even for those which aren’t, I never had any complaints (most feed readers seem to be able to read those just fine).