How Will You Replace Google Reader?
(Disclaimer: I'm going to use the term 'bandwidth' universally instead of the more correct 'latency' or 'throughput' so normal people can hopefully understand this post) The biggest problem I have with every alternative I have tried is that they are built with the most annoying design flaws. They are so painful to me that I am certain these flaws will be look back upon as the geocities of our modern day web development.
When I fire up an alternative, the responsiveness that was in Google Reader just isn't there. And it always seems like the alternatives require you to hit "refresh" on their interface and then what happens? It apparently makes a call out to every single RSS feed to get updates. On the surface this may seem like standard HTTP way of thinking about things. But it makes for a shit user experience. I have thousands of RSS feeds. Thousands. And if I hit refresh in this paradigm, my browser makes 1,000+ HTTP GET requests. It's not a lot of data but if even one of those requests is slow, it's usually blocking on ceding control back to me.
So let's iterate improvements on here that will get us back to Google Reader style responsiveness, shall we? Well, one of the simplest improvements I can see is to do these requests asynchronously with nonblocking web workers. You can attach each of them to the div or construct that each feed is displayed in and only have them work when that feed is visible (for instance if I am collapsing/expanding folders of feeds). You can grey out the feed until the request comes back but if another request returns first, it is parsed and inserted and activated to my vision. That way if cnn.com comes back faster than NASA's Photograph of the Day, I can read while waiting for my images.
But the core problem is that I'm on my home computer on a residential cable modem and, let's face it, Cox sucks. So what I think Google was doing was sacrificing their bandwidth to actually "reverse" the request from client to server. And, in doing so, they could package up all your updates and ship them out in one request (probably compressed). So, this is how I would approach that. Instead of doing a heart beat HTTP GET to check for RSS updates, I'd build a WebSocket and instead of requesting information, the client (browser) would be listening for information. The event/listener paradigm here would save both the user and the RSS host a lot of bandwidth but it would cost the host of the feed reader service some of that bandwidth (although much less). So basically the client JavaScript would load the page just like normal but instead of continually sending HTTP GET requests, a WebSocket would merely inform the server which feeds are active and listen for updates coming in from the server.
On the downside, this greatly complicates the server side. You need to have one be-all end-all "cache" or storage of all incoming feeds that any user is subscribed to. And for each of these feeds, you need to have a list of the users subscribed to it. And now your server will need to maintain the HTTP GET requests to cnn.com and NASA in order to get updates. When it gets an update, there's two ways you could handle it (user queues are complicated so I won't suggest that) but the most basic way is to send it right out to everyone on that subscription list who has an active WebSocket session established with their account. If a new WebSocket session is established, they simply get the last N stories from their subscriptions (Google included pagination backwards binned by time). To alleviate even more bandwidth from you, you could store it on the client side with HTML5 Web Storage and then the first thing the Web Socket does is find the last date on the last stored element and send that across to the server to establish the session. The server responds with any updates past that time. And from there your WebSocket is merely listening and inserting elements into the page when they arrive.
Of course, after you valiantly save your RSS providers from death by a thousand cuts, you yourself face that same fate. And now you know why Google scheduled a turn off of Reader ...