Why reader?

Why use a feed reader library?

Have you been unhappy with existing feed readers and wanted to make your own, but:

  • never knew where to start?

  • it seemed like too much work?

  • you don’t like writing backend code?

Are you already working with feedparser, but:

  • want an easier way to store, filter, sort and search feeds and entries?

  • want to get back type-annotated objects instead of dicts?

  • want to restrict or deny file-system access?

  • want to change the way feeds are retrieved by using the more familiar requests library?

  • want to also support JSON Feed?

  • want to support custom information sources?

… while still supporting all the feed types feedparser does?

If you answered yes to any of the above, reader can help.

The reader philosophy

  • reader is a library

  • reader is for the long term

  • reader is extensible

  • reader is stable (within reason)

  • reader is simple to use; API matters

  • reader features work well together

  • reader is tested

  • reader is documented

  • reader has minimal dependencies

Why make your own feed reader?

So you can:

  • have full control over your data

  • control what features it has or doesn’t have

  • decide how much you pay for it

  • make sure it doesn’t get closed while you’re still using it

  • really, it’s easier than you think

Obviously, this may not be your cup of tea, but if it is, reader can help.

Why make a feed reader library?

I wanted a feed reader that is:

  • accessible from multiple devices

  • fast

  • with a simple UI

  • self-hosted (for privacy reasons)

  • modular / easy to extend (so I can change stuff I don’t like)

  • written in Python (see above)

The fact that I couldn’t find one extensible enough bugged me so much that I decided to make my own; a few years later, I ended up with what I would’ve liked to use when I first started.