Slashdot Mirror
Slashdot Asks: How Will You Replace Google Reader?
Despite a hue and cry from disappointed users, Google has not made any moves to reverse its decision to close down Google Reader on the first of July, just a few weeks away. Despite the name — and the functions it started out with in 2001 — Reader has become more than a simple interface to RSS feeds; Wikipedia gives a concise explanation of how it evolved from just a few features to a full-blown platform of its own, incorporating social-sharing features of the kind that have become expected in many online apps. Those features have morphed over the years along with Google's larger social strategies, along the way upsetting some readers who'd grown used to certain features. If you're a Google Reader user, will you be replacing it with another aggregator?
www.commafeed.com
Feedly is OK, but not as good as reader. In particular I miss being able to use it to combine multiple feeds into a bundle - which then has its own RSS feed that can be displayed on web pages. Also an embeddable view for igHome would be good
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 t
My work here is dung.
In the very worst case, you can stand up your own server, as we have access to the source: https://github.com/samuelclay/NewsBlur
I have been very happy with NewsBlur as my Reader replacement. I am now 100% switched over. I use it to read nearly 1500 feeds and performance is great. They have clients for iOS and Android and FeedMe is a decent third party Windows Phone client. For the amount of time I spend each week in feeds, I am happy to pay $20 per year for a premium NewsBlur account.
I've been trying inoreader and have found it to be easy to use and fairly feature-rich.
Some highlights
- Easy import of all your Google reader feeds
- Lacking an android app, but one is planned and there is a mobile version of the site
- Fast
- Free
I think The Old Reader is the best replacement for Google Reader because it seems to be the only RSS reader I've found that is actually trying to do what Google Reader did. The others I've tried (specifically Feedly and Netvibes) seem to have different goals but can be adapted to behave similarly (but not the same) to Google Reader. I actually went with Netvibes for about the first month after the GR announcement because TOR was pretty lacking in the feature department and extremely slow due to the crush of new users. However, TOR had been rapidly updating the feature set, and I switched back over after they fixed up the mobile site and expanded their keyboard shortcuts among other tinngs (they've been great at adding features requested on the user feedback site).
When picking out a replacement to GR, I thought the most important thing was having the same goals as GR did in order provide the same functionality, and TOR has that in spades. I've never figured out why Feedly gets so much love in the GR replacement posts on tech sites. Need to install a browser extension? Yuck. The app wants to look like a magazine? Yuck. If you want to a pretty app to read articles like a magazine on your tablet, Feedly is nice, but it's not a replacement for Google Reader. The Old Reader is, especially now that the mobile site works as well as the Google Reader app ever did.
I switched to TinytinyRSS, and since its hosted on my friends server (will probably set up my own once my ESXi host gets more RAM) i dont have to worry about it suddenly dying on my. Migration was easy too since i could just export my list and import it in TTRSS.
When I received the first warning about Reader going away I started looking for alternatives. For me, having it be web-based was most important since I wanted to used it at home and work. The "at work" thing is a problem since I can't just install anything I want on my work PC.
It seems like the RSS reader market is flooded with apps so it was difficult to find web-based services. I had grown used to the Reader look and feel so I settled on NetVibes as being the closest fit.
My main criticism is NetVibes is not as fast as Reader but otherwise the format and whatnot is perfectly usable.
After getting some feedback on this usage of mine, and algo after seeing some other comments here, here are some hightlights:
+ IMAP takes care of the sincronization across devices.
+ There's a client for every device out there: the email client.
+ Achieving, deleting, marking as read/unread, flagging, all supported through IMAP as well.
Maybe rather than a web-based interface, this needs an email based interface (sort of like mailing lists).
I use tt-rss. It runs on my web server so i't always on, has mobile interfaces, runs in any browser. Try it.
http://tt-rss.org/
-- "Never underestimate the power of human stupidity." - R.A.H.
Exactly. iGoogle is a really useful homepage. Google have nothing to replace it (Google+ is not a replacement). So I'll just jump over to Yahoo. I'll probably do a large chunk of my searches through Yahoo too.
Hey all, this is Jamie Gilgen, the developer of Yoleo. The importer is very busy right now because of this post, it might take a little bit to import :)
Booz employee here. I use NSA reader to read your emails. Of course, most of your emails are boring so I have to run a filter to only include the good stuff -- drugs, gay sex, nude pics of your girlfriend (and/or mother in one case), etc. Our image analysis algorithms are pretty good, so I can exclude goatses and fat chicks.