Life Beyond Google Reader

Update September 2013: I’m now using Elfeed. The Old Reader was a victim of its own success, unable to keep up with its surge in popularity, and I ended up writing my own reader to serve my needs.

Google Reader will close its doors in about two more weeks. A few people had wanted to know what my plans were for accessing web feeds (Atom/RSS) once Reader is dead. Well, I finally figured it out and the process was much easier than I anticipated. The winner for me is The Old Reader.

This seems like such a strange move from Google. Judging from the public response to this news, Reader obviously still has widespread popularity. Google completely dominates this market and they’re throwing a huge opportunity out the window. The official statement is that the closure is due to Reader’s decline in popularity. However, Reader remains far more popular than Google+. My personal theory is that they want Reader users to switch to Google+, even though social media is no replacement for web feeds.

Oh well. While Reader’s closure will probably be a step backwards for web feeds in the short term, I think in the long term this will ultimately be a good thing. Feature-wise Reader has stagnated over the years. Removing this massively Google-subsidized client from the market should open up some interesting competition.

I waited awhile to look around for alternatives. Almost to the last minute, you might say. Google’s announcement in March was very sudden and unexpected, and the alternatives quickly found themselves overwhelmed. I wanted to give them time to respond to this massive shift in the market before evaluating them.


From my experience with Google Reader, knowing my personal needs, I developed a set of requirements that any replacement would need to meet.

A cloud-based web application

Surprisingly to some, readers have a significant amount of state. Not only do they need to store all of the feed URLs, they need to keep track of which articles in each feed are read and unread. If a local client, of which there are many to choose from, is used, this state is stored on the local machine, tying the use of a reader down to a single computer.

I see two ways to work around this. One would be to configure the client to keep this state in locally-mounted cloud storage. I don’t currently have a solution in place for this sort of thing, nor would such a solution be very friendly to access from the workplace.

The second is to use a local client that exposes a web interface. Basically, hosting a reader service myself. Should any cloud-based services be unreasonable, this would probably be the route I’d take. However, I’d really prefer to not have to manage another host. I’d have to worry about backing up the reader state and keeping the service running. When I eventually move onto newer computers, I’d have to migrate all of this as well.

Unfortunately, the Google Takeout export format (OPML) doesn’t including any of this state, just the subscription list. This state will need to be resolved manually on the initial import no matter what client I choose. In contrast to others, I personally have 0 unread articles most of the time, so this isn’t difficult for me.

There’s the privacy concern of using a cloud service. Someone I don’t know will have full access to a significant portion of my online reading. This isn’t really an issue for me. If you look at my navigation side-bar here you’ll see a listing of most of the feeds I follow, making this information public anyway.

Support for a large number of feeds

I have around 150 subscriptions at the moment. I keep my subscription list trimmed down to feeds active within the last year, so this cannot be reduced any further. The new client must support at least twice this number of feeds, since my trimmed subscription list grows with time.

Google Reader offered an unlimited number of subscriptions at no cost. I’d love for the alternative to also have no cost, but this isn’t a hard requirement, just a preference. I’d be willing to pay a few dollars per month to support an unlimited number of feeds.

However, I would like for there to be some kind of full-featured trial period, or the ability to pay for just one month so that I can import all of my feeds and give the service a full test drive without committing to it.

Support for reading articles in browser tabs

I don’t actually read anything inside the reader itself. Articles that are more complicated than plain text can’t really adjust to any arbitrary reader frame around them (including my own blog), so I don’t expect them to. The reader is only there to inform me that a new article has been published.

When new articles arrive I pop them out into new tabs for viewing. If there are many articles to be read, I position the mouse over the title of the first article, middle click it, then hit n to advance to the next. Alternating between middle-clicking and n I can quickly knock each article out into a tab. Then I just go through the tabs, closing them as I consume articles. Occasionally tabs remain open for a couple of days until I finish them.

This means the alternative must not use fake JavaScript “links” that can’t be middle-clicked into its own tab. It needs to play nice with the browser.

Soft Requirements

These are things that would be nice, but have little impact on my decision.

Support for mobile devices

While I recently starting using a mobile device I don’t currently access an web feed reader from it. It really comes down to the one-article-per-tab thing, where I don’t want to read articles inside the reader itself. However, maybe someday I’ll start access a reader this way, so support would be nice.

Open Source

I’m using it entirely as a cloud service with no intention on running it on my own machine, so this isn’t very important. However, it would be nice to see what’s going on, and maybe even submit a patch to fix problems I find.

This has been one of my biggest annoyance with these “app stores” popping up over the last few years. There’s no metadata for indicating where to find an app’s source code (if available), even if it’s just a link to a GitHub repository. When I find bugs in apps I have no way to fix them myself — something I have taken for granted with Debian and Emacs. These app stores are not made for technical people or power users.

No social/sharing services in the way

Google Reader has this and I never used it. I don’t really mind if it’s there, but it needs to stay out of the way.


Very convenient, but I can live without it. Because I keep my subscription list well-curated, going through them all one-at-a-time to move to another client isn’t a big deal. On the other hand, I’d really prefer not to go through this process just to evaluate a potential reader client.

The Evaluations

I did a number of searches to learn the names of the alternative readers so that I could evaluate them. These four were the most popular, being named over and over in the results.


This one seems to have the most popularity of all. It’s cloud-based, but it’s not a web application, rather it’s a browser extension. This doesn’t fit the first requirement.


Unlike the others, this one’s a straight $2 per month with no free version. Fortunately you don’t actually get billed unless you stick around for three days. Unfortunately this one wasn’t for me. The interface is completely incompatible with reading articles in their own tabs, among other issues.

However, they do have a really slick API.


This is the one that caught my eyes months ago. It’s even open source, in case I ever wanted to run my own private instance. However, I’m not satisfied with the interface. It really wants everything to be read within the client itself rather than popped out into new tabs.

Going beyond 64 feeds also costs $24 per year. That’s a reasonable price, but these circumstances make it hard to give it a full test drive for a few days.

This one’s a close second place. It also has an API.

The Old Reader

Here’s the winner. As advertised, the interface is almost exactly the same as Reader, which makes it entirely compatible with reading articles in their own tabs.

What’s really insane is that it’s entirely free to use for an unlimited number of feeds! They’re really copying Reader as far as possible here. They do accept donations to cover their significant server costs. I intend to donate the typical web feed reader subscription fee of $2/month, in yearly installments, when Reader finally shuts down next month.

The downside is that it’s much slower than Reader at getting updates from feeds. Up to a full day slower. I don’t know how they did it but Reader managed to catch articles just minutes after they were published. I believe this is partly due to PubSubHubbub, but they managed this speed even with my own blog, which definitely doesn’t use PubSubHubbub (I’m not pinging a hub when I publish).

Slow updating is the only downside I’ve had so far, and it seems to be an issue with all readers except Google Reader. If the option was provided, I’d pay a premium to have feeds update faster.


Google Reader represented a significant part of my daily schedule. It was my breakfast morning newspaper for about 6 years. Thanks to web comics, it even had a metaphorical comic section. I’m just getting settled into this new alternative and I’m crossing my fingers that it will do as good of a job. I think it will.

blog comments powered by Disqus

null program

Chris Wellons