I hate RSS. It’s a bad format that developed organically in all the worst ways, and it should have died completely in favour of Atom by about twenty years ago. I started a draft describing some of the problems that actually matter (thing that can’t be represented reliably in RSS, and such) in <https://chrismorgan.info/atom%3Erss>.
And so I wish people would stop calling feeds RSS, because it continues to compound the problem. Let RSS die! More than once I’ve seen people implement RSS feeds, at great pain and often with errors, simply because they hadn’t heard of Atom.
(I still need to decide which spec I hate more, RSS or OpenGraph. Hmm… RSS had more excuses for being bad, OpenGraph was just a spectacularly bad thing thrown over the wall by a company that should have known better. I drafted something examining how comprehensively bad it was some years ago, I should put it onto my new site and continue it at some point.)
Having structured feeds of any kind is already a niche and much appreciated when it happens. How to call them correctly technically based on some specs is not the hill to die on.
We call them RSS feeds, RSS reader apps even if it might be implemented as an Atom feed.
The reason I think it matters is that, because people keep on using the name of the wrong format, people keep on using that wrong format when they want to implement feeds. Where if they had known about Atom, or that podcast feeds are the only reason not to use Atom, they would gladly have used Atom.
Flashback to a memorable bug report complaining that "the JPEGs I'm uploading don't work" but upon further investigation, they were trying to upload HEIC photos. The field was explicit about the formats supported, but to this user, "JPEGs" just meant "images".
I have trouble seeing how that helps anyone. It’s not like ‘RSS’ is a widespread term the way ‘Word’ or even ‘Mastodon’ are (and even there I’d argue it’s worthwhile to use technically more correct terms). Why not just use ‘news feed’ as the general term? If you don’t care about the protocol in the first place, that’s far more descriptive and correct, no?
Because if you say "News feed" people are thinking Facebook or Twitter feed. RSS is widely known as it was already integrated in browsers before as a "RSS" button if the site advertised that in the html head.
I should think that’s a pretty niche memory among people who browse the internet nowadays, but then I only have anecdotal evidence, so I could be underestimating it. Even so, I think conflating a general type with a format specification is not a good idea overall.
RSS is the only widespread enough name for this thing. Where you're correct is that it's silly to argue about the name of the format used by approximately three people.
I'm not too serious here but even many news media publications are just dropping it, or separate into dozens of unconnected feeds.
I don't think this is helpful. The last statistic I saw put RSS at 77% of the web feed market share, higher than Atom. In the web feed market it isn't a protocol on the way out, its the dominant protocol.
While RSS is tricky to parse in practice, many of the challenges are due to invalid feeds, which Atom is not invulnerable to. Its very likely that there is a well-tested feed parser for your favorite programming language, so most developers using feed programmatically don't need to handle those challenges themselves.
For concerns like title encoding or summary vs full text description, you can handle those using namespaces. If you don't like any of the existing namespaces that do that you can create your own.
Thank you; that was a fun read! I had read that Atom was generally regarded as the technically superior format, but your article (and the links you helpfully provided therein) made it much more apparent why that is the case. :-)
Wow, what timing. Not to shill, but I'm also nearly done building a directory of RSS feeds. It stemmed from a frustration of outdated and broken RSS feed collections, and the long slow death of the orange RSS subscribe button across the web. I'm not officially launched yet but I would love some feedback and maybe some of the RSS feeds that land in your directory can be added to mine.
Pardon the dust. There's an app tie-in that I'm almost done with too, a widget-first app that shows your RSS feed collections on your phone's home screen. It would really be great if we could start to bring about an RSS renaissance!
Make a possibility to batch suggest feeds - a lot of people have opml xml exports from Google Reader so they can give it to you. Processing info would be nice so I as a supplier would immediately know how useful I was.
Move explanatory part of RSS to some other part than homepage.
"White or almost white text would be better." -- There is some white text, headers and headlines mostly. Did you find the lack of contrast difficult to deal with?
"Make “Add” button visible on homepage." -- you mean like in the search results? That's a fine idea.
"Make a possibility to batch suggest feeds" -- I've been toying with how to handle OPML imports. Definitely a feature to come on the app, but I fear with mass submission on the vault I would be inundated with feeds, and the curation aspect would suffer. I want quality over quantity. But maybe there's a happy middle ground somewhere.
"Move explanatory part of RSS to some other part" -- yeah I guess this might be helpful to someone who doesn't know what RSS is, but then they probably aren't visiting anyway lol I'll give it some thought.
Yes, with several months of iteration. I've wanted to build this for years but to get it to the point where it's a quality destination is an effort beyond the time I would have been able to contribute.
Im going to be doing this again without an agenda. I am recovering from using AI to write thoughts because now I see and hear the patterns which are becoming obnoxious.
Yeah, I've been writing software that provides feeds for RSS, but I exclusively use Atom. It's just a better format. It does create ambiguity when using a site like this because I'm not sure if my sites will qualify as having an RSS 2.0 feed or not.
It's great to see someone else using FeedLand. While it has some quirks, is has some clever ideas, like that blogroll feature.
My favorite part of FeedLand is that you can see who subscribes to a blog and where else they subscribe. This makes RSS feel social, without the algorithmic tricks of traditional social media. Here's the listing for my blog, for example: https://feedland.com/?feedurl=https%3A%2F%2Falexsci.com%2Fbl...
It was designed that way, patterned after social media, where you share all that info. I wanted to see if it would work in RSS, and it came out pretty good.
We're going to have a new version pretty soon, hooking it up with RSS.chat.
Surprisingly cool site. I've seen lots of sites for RSS feeds but they aren't any good because they just dump their mountain of every feed that was ever known to exist, and there's not really any aspects of curation or discovery. RSS feeds themselves embody the exact way I think the internet should work, where the internet itself is the platform. However it's very nice to get some help finding new stuff.
I'm always surprised how many people who read my blog do so over RSS. It's probably one of my biggest traffic sources. (Definitely due to my niche topic and small reach, but still)
I don't really use RSS myself anymore, though; not since I stopped using Google Reader a few months before they pulled the plug. Wouldn't even know where to start nowadays.
I only have a fairly basic understanding of encodings, but is this one by any chance in one of the smaller “standard” character sets and not in the huge Unicode “emoji” set?
There's not really a "standard" character set and an "emoji" one. There is an emoji block (U+1F600 to U+1F64F), and this heart (U+2665) is not in that. But this heart is an emoji, in that the data file emoji-data.txt for contains `Emoji=Yes` ("=Yes for characters that are emoji", —UTS #51) for this character. However, this heart has `Emoji_Presentation=No`, which "=Yes for characters that have emoji presentation by default" (—UTS #51).
So basically, it should present, by default, in its non-emoji appearance. (Though there seem to be a number of readers for whom that isn't true. I think that's macOS being badly behaved.) There are some characters that can flip/flop between a "text" (normal monochrome) presentation and an emoji presentation; all of the card suit characters are. Unadorned (e.g., just U+2665 alone) then, you have to follow the emoji default presentation rules. In some contexts, such as web pages, that's "just do what that Emoji_Presentation flag says" for those characters, but see [§Presentation Style](https://www.unicode.org/reports/tr51/proposed.html#Presentat...) for exceptions to the rule. (HN is not an exception.) But you can also follow the character with a variation selector, to try to force either text (U+FE0E) or emoji (U+FE0F) presentation.
There are a number of what I'd call "yeah that's definitely an emoji" outside the Emoji block, too. Like U+2705 "white check in green box" (which HN disallows me posting); that one is Emoji=Yes but also Emoji_Presentation=Yes)
(IDK if Emoji=Yes Emoji_Presentation=Yes is HN's filter … but that'd be what I would do, if I wanted to filter out emoji like HN does.)
It may not be in the Emoji character block formally, but casually speaking it’s not wrong to call it an emoji, since emoji is basically just a picture character, and this is no less a picture character than what’s formally codified as ‘Emoji’ in the Unicode standard.
In addition to this, what I meant to convey is that it does show exactly like the iOS/iPadOS emojis, in color, with details, etc. Not the non-emoji font unicode character
They've always been stripped for me as well. This "emoji" actually appears black for me however.
I think the reason its not stripped is because it's actually "U+2665 : BLACK HEART SUIT {valentine}" which predates the emojis. Lots of fonts and OSes will render these older unicode symbols as emojis
Maybe you love being the consumer of RSS feeds, but you certainly wouldn't love being the poor bastard who has to parse them.
Even though it's a simple standard that's been around for decades, there are still many sites which serve their feeds with a subtly wrong format. When something doesn't work, users come knocking on your door saying "it works in X reader but not in yours", so now you have to handle that and contribute to the ever growing list of out of spec edge cases that feed readers need to account for.
What sort of punishment should the monopolist google execs who destroyed blogs undergo? A fair punishment might be clawback of all wages and stock options and about five years in a minimum security prison with a permenant felony on their record. I think that's fair.
Small tech and individuals will never be able to take as much advantage of these standards as a multi-billion dollar data center is. 99% of them wouldn't ever even find these feeds
One of the downsides I saw when evaluating JSON Feed was that it doesn't use GUIDs, which can cause problems when the same post is present in multiple feeds (I.E. syndication).
When I last looked I found that every feed reader supporting JSON feeds also supported RSS/Atom and every website with a JSON feed also had an RSS or Atom feed, so it seems easiest to ignore the JSON Feed format.
And so I wish people would stop calling feeds RSS, because it continues to compound the problem. Let RSS die! More than once I’ve seen people implement RSS feeds, at great pain and often with errors, simply because they hadn’t heard of Atom.
(I still need to decide which spec I hate more, RSS or OpenGraph. Hmm… RSS had more excuses for being bad, OpenGraph was just a spectacularly bad thing thrown over the wall by a company that should have known better. I drafted something examining how comprehensively bad it was some years ago, I should put it onto my new site and continue it at some point.)