RSS vs Atom vs JSON Feed vs h-feed vs Whatever

The feed wars are not returning

https://indieweb.org/RSS_Atom_wars

The RSS Atom wars (or syndication wars) were a toxic plumbing debate about the merits of using Atom vs RSS that dragged in and distracted numerous high level web technologists from 2003-2007 while social silos (Facebook, Flickr, Twitter, etc.) emerged, rapidly innovated UX, and thus gained popular adoption.

Bickering feed war geeks probably harmed the open web during that period.

Anyway, back to the present. When I see discussions about RSS at Hacker News in recent years, I consider the term "RSS" to be an umbrella term that represents feeds and feed readers.

I'm not picky about the feed format, whether it's XML, JSON, HTML, or plain text. I support them all somewhere. They all have their pros and cons.

When pushed against a wall and forced to make a choice, I might prefer email newsletters to feeds.

Since at least 25 percent of all websites are managed by WordPress/Automattic software that automatically offers feed files, then feeds should be around for a while even if most web users don't realize that they exist.

Maybe the open web will gain some traction from the masses in the 2020s, which would include significantly more feed productions and consumption. If the open web is supported more, then I don't care if the most popular feed format is RSS, Atom, or JSON Feed.

The open internet would include websites, feeds, and email.

Unfortunately, for producing and consuming content, many internet users believe that the open internet tech stack is harder to use than siloed social media services, such as Facebook, Twitter, and Instagram. Sigh. Apparently, the silos built better mousetraps than what the open web offers.


RSS3

If I had to pick a feed format, I would choose the jokey but useful RSS3 plain text format.

August 2018 IndieWeb chat: https://chat.indieweb.org/2018-08-19

10:49 Zegnat The things you sometimes learn randomly: RSS 3.0 stopped being XML based.

10:57 [kevinmarks] That was a parody

10:58 [kevinmarks] RSS was at 0.92 or so, and the RDF fans did an iteration, made it RDF, and called it 1.0

10:59 [kevinmarks] Dave Winer didn't like the RDF version, so did a few changes from 0.92 and called it 2.0 montag4511 joined the channel

11:00 [kevinmarks] Aaron Swartz then parodied Winer's post and made up RSS 3.0 as plaintext (which is ironically closer to json feed)

This is Aaron Swartz's post from 2002 about his humorous RSS3 proposal.

http://www.aaronsw.com/weblog/000574

I support RSS3 at my test website http://sora.soupmode.com.

http://sora.soupmode.com/rss3.txt - This is easy for humans and computers to consume.

At my simple web-based feed reader site, http://finch.soupmode.com, I support RSS3, along with RSS and Atom. I don't think that my app supports JSON Feed, and I don't support h-feed.


h-feed

My second favorite feed format would be h-feed, espoused by the https://indieweb.org. It's an HTML-based feed that uses Microformats. Since websites create HTML pages for users to read, then the IndieWeb community believes that instead of creating separate files that use formats meant to be created and consumed by computer programs and not humans, it would better to make an HTML page double as the feed file.

Many personal website authors display content on their homepages in the traditional blog-style format with posts organized from youngest to oldest. These homepages could also be the feeds if Microformats were incorporated within the HTML.

At sawv.org, I create an h-feed file as a sidefile.

http://sawv.org/mft.html - I should rename that file to match what I use at my Sora test site.

http://sora.soupmode.com/hfeed.html - That uses a more intuitive name.

I discuss feeds and what's important to me in this post.

http://sora.soupmode.com/info.html

A few feed readers can parse h-feed files. This saves a publisher the trouble of creating feed files in RSS, JSON, Atom, and whatever else gets proposed. Since a website is creating HTML for humans to read, then by adding Microformats, the same HTML page can be processed by computer programs.

That's the theory espoused by the IndieWeb. But since most feed readers do not support the h-feed format, then h-feed is slow to catch on.

This is a cool service, created by an IndieWeb user.

https://granary.io

I only need my Sora code to produce one feed format: h-feed. I can remove the code that creates JSON feed because Granary can read h-feed files (HTML Microformats) and create Atom or JSON feeds.


JSON Feed

I prefer to process JSON over XML in my computer programs. If a JSON format exists along with the XML version, I choose JSON.

Reece and Simmons released JSON Feed in the spring of 2017.

https://jsonfeed.org

Soon afterwards, multiple well-known feed readers added JSON Feed support. When I use a "real" feed reader, I use the web-based feeding reading app https://theoldreader.com. The Old Reader supports JSON Feed.

In my opinion, the only social network worth using is micro.blog, creatd by Manton Reece. micro.blog supports multiple IndieWeb and open web concepts, including feeds and Webmentions. Naturally, it supports JSON Feed, along with the XML feed formats.

sawv.org JSON Feed: http://sawv.org/feed.json.

I also produce a JSON Feed at my Sora test site.

http://sora.soupmode.com/feed.json.


RSS and Atom

I have seen arguments that give reason why the Atom feed format is better than RSS. To me, it seems that Atom is more complex. RSS can be used simply.

I support RSS at sawv.org.

http://sawv.org/rss.xml

I created my own web reading app to consume content produced by the Toledo Blade. I'm a subscriber to the Blade, but I do not use any of the Blade's digital products because they are too woeful. The Blade's website is an insult to humane web design. My Blade web reading app consumes RSS feeds, offered by the Blade. The Blade gives a snippet of the article content in the feed.

I don't care if feeds contain the entire article or only a snippet. I'm fine with clicking through to read the entire article. Personally, I prefer titles or a single sentence, creation date, and a link. That's about all that I need in feeds.


Markdown feed

Hey, why not another format.

This is my Markdown-only test website.

http://md.soupmode.com - This is the only HTML page. It explains the point of this test site.

This is the real homepage: http://md.soupmode.com/md.

When I create or update a post, I write in Markdown, and that's all the CMS saves: the markdown. My CMS does not create HTML versions of the posts. No CSS nor JavaScript is downloaded from the server.

Only text/plain Markdown (CommonMark) is downloaded from the server. It's up to the client (the reader) to display the content however the reader desires.

I don't think that Markdown web browser exists, therefore I rely on web browser extensions to convert Markdown into a formatted display. The extensions permit me to upload custom CSS, or I can choose one of the themes, included with the browser extensions.

For such document-style websites, a feed would be nice to have, and it would need to be Markdown.

This proposed Markdown feed format is like or similar to RSS3. This version would be easier to text-process.

http://md.soupmode.com/feed2a.md

I like this proposed Markdown feed format better, since it's nicer for human consumption too, but it should be relatively easy to text-process.

http://md.soupmode.com/pheed.md

Maybe the simple, lightweight NetSurf web browser could be modified to support Markdown processing too. For non-technical users who don't know CSS, it would be nice to provide point and click menu options to manage the typographical features.

My md.soupmode.com emphasizes reader control in typography. No more HTML, CSS, JavaScript, nor all of the other crap and cruft associated with the modern web would be downloaded. Only text/plain CommonMark markup would be downloaded.

Here's another Markdown test website.

http://scaup.org/home.md

scaup.org is hosted at an Amazon Web Services S3 bucket. I create the Markdown files locally with MY preferred editor. Then I log into my AWS account. I use the AWS S3 web interface to upload my post to the website through the browser.

Within the AWS admin console, however, I have to change the content type of the .md file to be text/plain. If I uploaded .txt files, then this mod step would not be needed. But I like .md extension because it's intuitive. It tells me that it's probably a Markdown file.

I could use the command line tool to upload the .md file from my local computer to my leased S3 bucket, but I'm trying to make it simple for non-geek users. The step about changing the content type is a bet technical.

The beauty of this setup is that no CMS is needed. Files can be organized and backed up locally. Users can optionally store files at a cloud service, such as Dropbox. That would mean the files would exist at three locations. Many non-geeky users are familiar with editing files locally and with storing files at Dropbox.


Winer's Nov 4, 2019 post

JsonFeed after two years

Excerpts from Dave's post:

A couple of years later, I've yet to see a JsonFeed in the wild.

I have seen other websites support JSON Feed. Since XML and JSON are plumbing tech, it's possible that JSON Feed is being used by others for non-public functions.

Many people use podcasts, and I think that most podcasting services and apps use RSS under the hood. In my opinion, that does NOT make those podcast users RSS users. Most podcast users have no idea that their podcast apps are consuming RSS.

A feed user is someone who uses a feed reader and knowingly subscribes to feeds of websites. This represents a tiny percentage of web users.

More from Dave about JSON Feed:

There was, provably, no reason to do this. At this point, is there a language or environment that doesn't have an open source library for reading feeds?

From my experience, I have encountered too many broken XML-based feeds. It must be a pain in the ass for feed reading app developers, such as The Old Reader. Sometimes, the Blade's RSS feeds are malformed and thus broken. The RSS/Atom/XML libraries that I use choke. I have modified my Blade web reading app to account for the Blade's occasional malformed feeds. I correct the mistake within my app before processing the XML.

Malformed JSON files can occur too, but my personal preference is to process JSON. When I create CRUD web apps, my API code receives and returns JSON, not XML.

In 2013, I created my own local web-based weather app.

http://toledoweather.info

I fetch and process plain text, XML, HTML, and JSON files. The National Weather Service provides a custom XML file for each locale. But the NWS also offers a JSON version. I use the JSON file.

The Storm Prediction Center, however, produces RSS files, which are easy to process. The only XML format that I like is RSS.

More from Dave:

It's just one call in my JavaScript code to take a bit of text that's supposed to be a feed and get back a JavaScript structure with the contents. Couldn't be simpler.

JSON is also easy. After all, JSON means JavaScript Object Notation.

In NodeJS, Perl, and Lua, I prefer to handle JSON over XML. When I have to view the plumbing, JSON is easier for me to read and understand.

Yet I don't think many of those libraries include support for this two-year-old format. So you have to do more work to read it. One of the goals of the new format was that it would be less work.

Huh? It's JSON. What's difficult?

Finally if you were going to invent a new format why not just JSONify an existing feed structure. I did that for RSS in a few minutes. My blog is still available in JSON as well as XML. No need for debates or feature requests. It's RSS but in JSON.

That's why I prefer the IndieWeb's h-feed format over XML and JSON feed formats, since tools exist to JSON-ify and Atom-fy h-feeds. No need to create XML and JSON files. Websites can focus on the main human format HTML, which can act as plumbing too if formatted with Microformats.

Dave said:

I've known both Manton and Brent, the authors of the format, for many years. Nice people. But this was a mistake. Atom, also, was a mistake.

Providing options that do not harm people is NOT a mistake. It's an alternative. Nobody is forcing anyone to use JSON Feed, h-feed, Atom, RSS3, Markdown Feed, YAML Feed, etc.

Again, when my client code communicates with my server code, I rely on JSON not XML and not text/plain. If JSON Feed had been created in the early aughts, then JSON Feed might have won out over all other options in terms of popularity.

In the future, I might use RSS3 for program to program communication in some instances because it's simpler than RSS and JSON Feed, in my opinion.

Dave concluded with:

All the energy should have been focused on a standard that would be supported everywhere, as easily as possible. I did it myself. I had designed a format when RSS came along, from Netscape, and I dropped it in favor of RSS, because one way to do something is better than two no matter how much better the second way is.

One way is better than options??? Since when?

Of the real feed formats that are processed by at least a few real feed readers, h-feed is the best, in my opinion. h-feed makes the most sense because it's HTML. But h-feed is relegated to the IndieWeb community, which has created feed readers that support h-feed, along with other feed formats.

I like having options. This is choice.


The winner among the masses

Only a small percentage of geeks "worry" about feed formats. Many geeks don't care because they have no use for feed formats of any kind.

The general public uses two primary feed formats, and these are not real feed formats.

Apparently, many people believe that their Twitter usage has replaced feeds. Since I don't care about the cesspool of the internet, I won't waste any more time with Twitter.

Email newsletters make sense to me. Email got invented in the early 1970s. It's fairly sturdy technology. I started using email in the late 1980s before the first website appeared. Most people connected to the internet manage at least one email account.

One argument against email newsletters is that some geeks prefer a clear separation between feed-style content and real emails. They don't want the two mixed within the same client app.

But that mixing is also a positive for why many people prefer email newsletters over feeds. I subscribe to email newsletters. I also use feeds too. I like both, and I don't think that I could choose one over the other.

With email newsletters, users do not need to manage another client app (feed reader) nor another password at a web-based feed reading service. I think that many non-technical people believe that it's easier to subscribe to email newsletters than RSS and Atom feeds.

I subscribe to daily, weekly, monthly, and quarterly email newsletters. I also subscribe to personal website publishers who send out an email whenever they post new content, which can be infrequent.

I subscribe to email updates from small businesses. This process would not be called a feed, but it would be like a business updating its blog, and the post appearing in the site's feed that is consumed by a feed reader.

Some small business owners and personal web publishers either do not maintain their own websites that are hosted on their own domain names, or they don't update their websites as often as they update their social media accounts. But these people also offer email newsletter options, and they do send emails regularly.

For non-technical users, managing social media accounts and using an email newsletter service are easier to use than managing personal websites. These people probably realize that they get more bang for their time by sending email notifications and updating their social media accounts versus their own websites.

Since more people probably consume new info via email newsletters than feeds, it's pointless to waste time worrying about new feed formats.

In 2019, Dave Winer started offering a daily email newsletter, and he wished that he had done that sooner. I wonder if he has learned that more people consume his email newsletter than his RSS feed.

My 2016 post: Email Newsletters vs RSS Feeds.

Instead of choosing one over the other, why not use both?

-30-