RSS Part 12: yarr
The yarr RSS client, short for “yet another RSS reader,” was only started last summer. I am hesitant to try it out after my experience with GORSS, but it has already reached version 2.1, which I hope is a sign that it is usable. It is another web-based client, but this one is implemented in Go, using SQLite for the database.
Impressions
I prepared a container for testing yarr using the binary that is
distributed on GitHub. The zip
file extracts to a single
executable file. There is almost no documentation. The client managed
feeds for a single user but has support for authentication, so I
prepared a file in username:password
format. I executed the
program as follows, with port 7070
in the container exposed
to my host:
docker@yarr:/tmp$ ./yarr -addr 0.0.0.0:7070 -auth-file yarr.auth
Browsing to the exposed endpoint (localhost:7070
in my
test), you are presented with a login screen, which works fine. After
logging in, you are presented with a mostly empty user interface, with
no default feeds. No problem.
The settings menu is accessible via an ellipsis icon (three dots) at the top left of the leftmost pane, and there are very few settings! Simplicity is nice, but I worry that this program may not be able to do everything that I want to do.
I imported my OPML file, and there was absolutely zero feedback during the lengthy time that it took to import. I figured it might just be taking a while, and sure enough the screen eventually updated to display my feeds. The category folders imported successfully, with the feeds directly inside of them. Interestingly, the feed folders that I have to create in Thunderbird are not imported. I think that yarr only supports one level of hierarchy, like FreshRSS, and it only keeps the topmost folder. This happens to be the easiest for me to work with. The folders are automatically sorted. Nice!
After importing, the feeds are automatically updated. The initial update was extremely slow. From the logs, I calculated that it took 43 minutes and 12 seconds! Thankfully subsequent updates are much faster. My second update took 1 minute and 28 seconds, which is not bad.
What could cause the initial update to be so slow? The network traffic and latency should be the same for subsequent updates, which are fast, so the issue is probably client-side. My guess is that it is a database issue, since the initial update has many more database writes than a subsequent update that is done soon afterwards. FreshRSS has great performance when using SQLite for the same feeds, so the problem is on the yarr side. It really looks like feeds are updated serially (one at a time). At first I wondered why this is done, since it is so easy to implement task pools in Go using channels and goroutines, but I now realize that parallel updates would probably exacerbate the database issue.
When you select a feed or folder in the left pane, a list of items in the feed/folder is displayed in the middle pane. A search bar and feed settings icon (another ellipsis) is displayed at the top of the middle pane. The feed settings are minimal: you can open the website, open the feed link, rename the feed, move the feed to a different folder, or delete the feed.
Feed titles default to the those specified in the feeds, but users can set a better name when desired. Great!
This client does not show which feeds have unread items! Most feeds show the number of unread items per feed, but you have to select the feed and visually look for unread items in yarr. This is terrible for productivity.
When you select a feed item, the item content is displayed in the right pane. The item link is made available using a link icon at the top of the pane, and the URL can be copied via a right click. Podcast enclosures are displayed using a media player. Since the URL is not made available, this does not work for me at all.
There is support for manually checking all feeds as well as periodically checking them automatically. Items are marked as read, not deleted, and there is no trash support, which is not my preferred way of processing feeds. The search works well. It searches item content, not just item titles. Keyboard shortcuts use Vim-style key bindings. Great!
Item descriptions look fine. Japanese is displayed without issue and fonts look fine, as it is in my browser after all. Tables look great. Images are displayed, and there is no configuration for disabling them. This is not a big issue since item content is displayed in a separate pane.
The simple user interface is quite nice. The panes can be easily resized using the mouse. I turned on responsive design mode to see how it would look on a smartphone, and it looks great! When the screen is less than 768 pixels wide, only one pane is displayed at a time. When the screen is between 768 and 992 pixels wide, two panes are displayed: the feed list and a pane that displays the items or item content. All of the display modes are intuitive, and I would particularly appreciate the simplicity on a tiny screen.
With the port bound to my Wi-Fi LAN, I was able to test out the interface on my smartphone and tablet. As expected, the interface is nice. A few issues became immediately obvious, however. First, navigation within the client does not work with the browser back button. When I am done reading an item, I naturally use the back button to go back, because it is at the bottom of the screen near my thumb, but the back button unfortunately takes me back to the login screen. The other issue is that you have to open an item to mark it as read. I wish that there was a way to mark an item as read without opening it.
There is no support for authenticated feeds. As with other web-based RSS clients, you get the benefits of browser features (including add-ons) since yarr is used in the browser.
I added the feed that Thunderbird refuses to load due to validation issues, and yarr handles it without any problems.
There are no settings for purging old items. I wonder if it is implemented but is not configurable or if the program keeps all items and grows in size over time.
The configuration and state is stored in
~/.config/yarr/storage.db
. This does not cleanly separate
configuration from state, but at least it does not pollute the home
directory with an application directory. This file is about 62 MB after
my initial import. If yarr does not purge old items, I expect that this
file would grow very large at quite a rapid rate!
I checked out the resource usage in order to estimate server requirements. The low values were measured during an idle state, and the high values were measured while processing feeds.
Container | CPU (%) | Memory (MiB) |
---|---|---|
yarr |
0~9 | 75~79 |
The CPU usage is generally very low, with some small spikes (~9%) when I process feeds very quickly. Assuming that the memory usage is roughly constant, not a function of the size of the perhaps ever growing database, I could run this software on an existing server, not adding any additional expenses.
I would also like to measure the network/browser usage for comparison with other web-based RSS clients. The HTML depends on feed items that are displayed, but I am most interested in the JavaScript anyway. It loaded four scripts, transferring a total of 41.41 KB. This is really great! If I need to do frontend JavaScript in the future, perhaps I will consider using Vue.js.
The repository has open issues and I noticed an interesting one titled yarr is feature complete. The author created the program to serve his own needs and does not plan on adding any new features now this his needs are met. He recommends that people fork the project if they want to implement new features.
My Client Requirements
How does yarr measure up to my client requirements?
It is difficult to say that yarr meets my essential requirements because the initial import was so incredibly slow. My second import was fast, but I worry that more (database?) problems may come up over long-term usage. Other than that, I was really happy with the small JavaScript size, the keyboard shortcuts are good, and it works with all of my feeds. I did not spot any UI bugs.
I prefer a native application, but using a web application would be convenient for checking RSS feeds while away from my computer. While I prefer my current workflow of deleting items as I process them because of the high efficiency, I quite like the yarr UI on small screens. For checking RSS on my phone, I like it even better than the FreshRSS and Tiny Tiny RSS UIs.
The client supports a single level of categories, which meets my requirements. This allows me to optimize the order that I process feeds. It supports checking feeds manually as well as automatic checking. Unfortunately, it does not indicate which feeds have unread items.
Since yarr is accessed via my web browser, the content is rendered well. The fonts look fine, it supports multiple languages, and HTML content is rendered well (including tables). Browser add-ons can be used!
Overall, there are some really nice aspects of yarr, but there are also a number of deficiencies. Given that the author is not interested in doing further development, aside from maintenance, I will definitely not switch to yarr. It could serve as good inspiration for a new RSS client, however.
- RSS Part 1
- RSS Part 2: My Client Requirements
- RSS Part 3: Validation Issues
- RSS Part 4: Thunderbird
- RSS Part 5: Newsboat
- RSS Part 6: GORSS
- RSS Part 7: QuiteRSS
- RSS Part 8: Liferea
- RSS Part 9: Akregator
- RSS Part 10: Tiny Tiny RSS
- RSS Part 11: FreshRSS
- RSS Part 13: RSS Guard
- RSS Part 14: Feature Reflections
- RSS Part 15: Client Reflections
- RSS Part 16: QuiteRSS Day 1
- RSS Part 17: QuiteRSS Update
- RSS Part 18: QuiteRSS is Dead
- RSS Part 19: Current Thoughts
- RSS Part 20: RSS Guard Revisited