There’s a new RSS feed reader for the text console out there, called NRSS. I took some time and had a look at it.
What is displeasing in the beginning is the lack of support for OPML file import. OK, then let’s fill ~/.nrss/config with a few URLs:
add “http://blog.fefe.de/rss.xml?html” “Fefe’s Blog”
add “http://www.sixapart.jp/business/index.xml” “Unicode-Test”
add “http://diveintomark.org/feed/” “Dive Into Mark (Atom)”
add “http://venzi.wordpress.com/feed/” “Venzis Blog”
So I start NRSS, and what happens? NRSS immediately begins to reload all feeds, and crashes at the URL http://diveintomark.org/feed/. Oh, well. That Atom feed doesn’t seem to work, although the FAQ claims that Atom is supported. So I remove it from the configuration. (N.B. the guy diveintomark.org is an absolute Atom nerd, and his feed is considered a kind of “benchmark” for Atom compatibility by many people)
The interface looks rather unusual, namely it starts with a feed’s name, below it its articles, then another feed, with its articles below, and so on. IMHO not very concise, especially for a lot of feeds (I read about 100 feeds right now, and I know newsbeuter users with 300 and more subscriptions). The articles can be collapsed, with the “C” key. BTW, help can’t be found via the ‘h’ or ‘?’ key, but via the rather un-intuitive ‘u’ key (as in “toggle-usage”).
Navigation is done via the cursor keys respectively page-up/down. Latter keys jump to the previous resp. next feed. With the space key, the selected article can be displayed. And here the next problem: HTML doesn’t get rendered. The documentation explains that a filter must be configured (it comes with an example to use w3m as such a filter). From the article view, it’s also possible to navigate to the next and previous article.
With Unicode characters, NRSS also seems to have problems (although I only tested with Japanese characters). The characters are displayed properly (well, not exactly in the Debian build, the colors are messed up there), but when switching from the article view to the article list, NRSS has redrawing issues. Ctrl-L, the “classic” keystroke to do a complete redraw in text-based applications, doesn’t work. Instead, the user has to press ‘D’.
After some more experiments, I had enough of NRSS, so I had a look through the documentation. The only special feature that caught my eye is the possibility to customize NRSS’ style with custom format strings. That’s a feature that’s not yet available in newsbeuter. Otherwise, NRSS has no interesting features, even Snownews and raggle provide a more complete set of features.
What especially amused me is the first entry in the FAQ, titled “What makes NRSS better than snownews/Raggle/newsbeuter/[other reader]?” that directly attacks these mentioned RSS readers.
There it says “With NRSS, the feeds are laid out in a predefined order, each with a summary of headlines, and I can read any story I like or go to its link without any clicking or tabbing. One of the philosophies of NRSS is that it should pack the most information into a single screen without seeming crowded.” Oh, well, this is possible in newsbeuter, too. In multiple ways. You can for example define a query feed that then displays articles of different feeds in a single list. From there, it’s a single keypress to view the article, and another one to return to the list. Exactly the same number of keystrokes that you need with NRSS. And you can navigate to the next article directly from the article view, too, in newsbeuter. And you can directly jump to a certain line in any article list or feed list, something that’s currently not possible with NRSS. In fact, there are so many more cool things in newsbeuter that simply can’t be done with NRSS.
And that brings me to my next point: scalability. Scalability in terms of extensibility. NRSS supports pipe-based plugins in many systems. This is pretty cool, in newsbeuter, support for Snownews extensions (and bookmarking support in the upcoming version 0.7) is implemented this way. But in some places, this isn’t really cool, like when it comes to display filters. Everyone who has used mutt probably knows display filters, and NRSS follows a similar concept. And everyone who knows display filters from mutt most likely has made the experience that this doesn’t perform really good, since a new process has to be spawned for every displayed article. An internal HTML renderer would fit well into NRSS. And it isn’t even too difficult to implement, as my own simple HTML renderer in newsbeuter shows.
But back to scalability: NRSS is written in pure C. The code quality is quite OK, what I could see from a quick look at it. But due to the IMHO poor choice of language, my prediction is that NRSS won’t scale in the mid- to long term. Adding new features will be harder and slower than in newsbeuter (unless the author spends more development time per day), and doing fundamental refactoring (and that is going to be necessary, I predict, if the author doesn’t want NRSS to end like mutt or slrn, which are both basically in maintaince modes these days) will be more painful. Snownews is a good example for an RSS feed reader, written in pure C, which lacks a lot of important features even after quite a long development time, and whose development practically came to a halt.
That said, I wish the author of NRSS all the best with further development, but I see no point in developing yet another RSS feed reader when there’s already a pretty good one out there.
(This article has been published in a shorter version [and in German] in my personal blog before)