RSS is Awesome

RSS is “having a moment” right now, and I’m 100% here for it. Well, maybe folks aren’t explicitly excited about RSS specifically, but an independent and open Web (a Weird Web, even?) is being talked about a lot. Burned by recent trends in [looks around] everything, we’ve realised that having some degree of control over the way our content is distributed is actually quite useful.

We almost lost it

When I wrote a post about RSS in 2021 it felt so off-trend that I added a “yes, it’s still a thing” caveat right in the post’s title. And honestly, I wasn’t super confident that it was still “a thing”. So it’s massive relief to see that something I care a lot about is growing in relevance.

In short, blogs are back! And with the demise of algorithmic feeds (or at least their massively reduced reach) we’re all looking for reliable way to find all this content. And it turns out RSS was pretty much the best tool for the job all along.

Skin in the game

A principle I’ve been trying to live by lately is that if I think something’s important I should be demonstrably involved. In some form or other I should have some skin in the game. To paraphrase a saying tied to musicians’ muscle memory: it’s not just enough to know something “in the head” - if I care about it I should know it “in the hand” too.

• I think podcasting is simply the best medium, so I’ve got a podcast
• I think YouTube is an amazing outlet for the world’s creativity and knowledge, so I’ve got a YouTube channel to share some things I’m super-nerdy about
• I’m excited about the potential of Web Components (maybe we don’t all need React after all?!), so I’ve released one of my open-source tools as a Web Component

My projects are not setting the world alight, but I’m involved. If podcasting or YouTube come up in conversation, I can talk from experience. I can legitimately say “I was there”.

So how does that apply to RSS? Well, for starters I’ve been blogging in some form or other since 2008 so I’ve definitely put my fair share of RSS feeds out into the world. But that feels a bit passive. If I truly want to have some skin in the RSS game, I need to be contributing. I need to give something back, something that helps other folks (not just burdening them with something more of mine to read).

So I’ve built an RSS reader.

Err, don’t we have those already?

True, there are loads of RSS reader apps out there. And some of them are really good, too. But none are exactly what I’m looking for. And what’s the use of being a developer if you can’t build things you like?

Building a thing is the best way to learn a thing.

In classic “how hard can it be?” tradition, I learned a lot while building my app.

• What we colloquially think of as RSS is actually a quite fragmented ecosystem with many flavours (RSS/Atom/JSON/etc.) that all have subtly different specifications. So writing a feed parser that can handle any feed a user might throw at it needs to account for the fact that YOU CANNOT ASSUME ANY “REQUIRED” FIELDS WILL BE PRESENT.
• A properly useful feed reader consumes A LOT of data. I naively assumed that because all I’d be storing would be text content, the payloads would be small. But even with a limited set of test feeds, my local state soon hit tens of megabytes.
• Everyone has a different set of priorities for what makes a “good” feed reader experience. Some people want notifications and statuses up the wazoo, some folks want the most minimal interface possible.

And because RSS has been around for so long, there are a lot of “nice to have” features in pretty much every reader:

• Auto-discovery of feed URLs. Being able to submit a plain ol’ URL for a site and have the reader-app find the feed URLs is table-stakes at this point.
• Once you open the door to auto-discovery of feed URLs, you need your UI to be able to handle sites that have multiple different feeds.
• Resolving relative URLs within feed content (for links, images, etc.). Despite the best practice of making all URLs in feeds absolute, comparatively few feeds actually implement this (so dead links and missing images are super common when browsing a naively-parsed feed).
• Universal import and export via OPML file. OPML is a markup format that allows groups of feed URLs (or podcasts) to be exported and imported into pretty much any mainstream app that deals with RSS.

Prioritising the features I care most about

So building my RSS app was a useful exercise solely from a learning perspective, but I was also able to throw in some features purely because they’re what I’m interested in 😆

An (almost) serverless app.

• No accounts. I (currently) have very little interest in creating a CRUD app or in dealing with all the user-management and server-side shenanigans that come with such an app, so from the get-go my USP for this project was “no accounts”. Users can just hit the homepage and get started using the reader functionality.
• Local storage. So if I’m not running a server and database, where does all the feed content go? The add needs some persistence of data, so naturally the browser’s “local storage” was the first thing I tried. Plain old localStorage turned out to be too small for all the data a feed reader needs to store, so I ended up using localStorage's beefier buddy, IndexedDB (there's an entire database platform built right into the browser. Who knew?!).
• Static hosting. Having no backend means that deploying my reader app is miraculously simple, especially with static hosting platforms like Netlify.
• Edge functions. When I said the app was static and serverless, I lied. Thanks to (perfectly sensible and secure) CORS restrictions, client-side JavaScript can't just go around downloading content from arbitrary URLs willy nilly. And reading content from arbitrary URLs is pretty much the one key feature of an RSS reader. To get around this, the "read the content of the URL" part of my reader app lives on a Netlify "edge function". This is a simple Node.js function that accepts a feed URL, reads it, and returns the data to the client-side JS.

The reading experience I want.

Another big win from a selfish standpoint is that by building my own feed reader app I get to craft whatever esoteric and bespoke reading experience I want.

I've written before about how little styling it takes to make vanilla HTML an excellent way to read content, but I do like to put my own spin on things. Alongside basic typographic best-practices (like sensible line-lengths, line-heights, and font sizes) I appreciate a well-crafted <hr> element and a confidently opinionated <blockquote>.

And then there's the "reader app" specifics around feed management. Can the feeds be organised in groups? Can you drag-and-drop from one group to another? Can you fine tune your "unread" and "new" notifications?

Add to that my (perhaps unusual) preference for monospaced typefaces and loud accent colours in both light and dark themes, my ideal reading experience isn't something I can realistically expect anyone else to create for me.

You can use it too

So now I’ve sung my reader app’s praises, where can you go to actually use it? Well, my final flourish was to find a domain name I thought summed up how I felt about the whole experience:

rssisawesome.com