![\"feedspool-go](\"./feedspool-screenshot.png\")
\n TL;DR: Released v0.2.0 of feedspool-go, my static-site RSS reader. Added features to keep infrequent feeds from vanishing and an over-engineered web component lazy-loading system that progressively loads content as you scroll.
\n\n\n\n\n\n\nI started this thing last fall, but I don't think I've blogged about it much yet.
\nfeedspool-go is a CLI tool I built for fetching & reading RSS feeds. It takes OPML & text lists of feeds, fetches those feeds periodically into a SQLite database, and produces static HTML as a reading interface.
\nThe \"spool\" part is inspired by Usenet and the \"-go\" part is because I've started and abandoned several iterations of this thing in other languages over the years. Maybe this one will stick and I'll more creatively rename it later. 😅
\nThis runs every 15 minutes on one of my machines at home. If the web server's running, you might be able to read my news at feedspool.lmorchard.com.
\nHere's a screenshot from mid-scroll:
\n\n The key thing is this: I don't want an inbox of unread items. I want to scroll through a personal newspaper of recent content from the web - I stop reading when I see stuff I saw before. This basically does that.
\nThis follows what Dave Winer calls the \"River of News\" pattern, which is fundamentally different from inbox-style RSS readers:
\nMany RSS readers treat feeds like email - every item is a task to process. That makes me anxious and feel like I have make number go down. The river model is liberating: you dip in, catch up on what's new, move on.
\nWhere I riff on Dave's usual river design is that I like to more strictly group items from the same feed together. And, I really like the card layout with preview images. But, it's basically inspired by his idea.
\nI'd mostly left this thing alone since an initial burst of hacking last fall. I've been using it daily, but accumulated a few wishlist items over time. Decided this past weekend I had time to tackle a some of them. Then, I figured that was worth a new v0.2.0 release.
\nThis release has a two major themes: ensuring infrequently updated feeds don't disappear, and adding navigation features to make browsing more pleasant.
\nThe main driver for this release was issue #20: when you filter feeds by timespan (e.g., \"show me feeds updated from the last 24 hours\"), feeds that update infrequently just vanish. My favorite once-a-week blog gets completely hidden when more active feeds dominate the view.
\nMy solution was adding --min-items-per-feed to the render command. Now the query logic ensures I see MAX(items in timespan, minimum items). So if a feed has zero items in the last 24 hours, I'll still see its 5 most recent items. The purge command got similar treatment with --min-items to protect history for quiet feeds during cleanup operations.
I sort the overall display by last-updated time of each feed, so the quiet feeds show up toward the bottom of the scroll. But, I can still see them. I'm considering adding another page devoted to just these feeds, though.
\nThe part where I really fell down a webdev rabbit hole in this release was with the lazy loading architecture. Currently, feedspool-go is primarily a static site generator - it renders everything to HTML files during the render command. But with hundreds of feeds and thousands of items, loading everything at once would be painful.
The key is scrolling, though: that's my main signal to the web UI that I want to read more. So, I wanted to build a UI that responded to that signal.
\nThe Go program generates:
\nindex.html with skeleton structurefeeds/{id}.html files for each feedfeeds/page-{n}.html files when pagination is enabledBut here's the clever bit: the index.html doesn't embed much content at all. Instead, it wraps each feed (or page of feeds) in a custom <link-loader> web component as a stub:
<feed-navigator>\n <link-loader>\n <h2>My Favorite Blog</h2>\n <a href=\"feeds/123.html#feed-123\">Read more...</a>\n </link-loader>\n <!-- More link-loaders... -->\n</feed-navigator>\nThe link-loader custom element is pretty simple, but does a lot of heavy lifting. When it appears in the viewport (detected via IntersectionObserver), it:
#feed-123 anchor)It's essentially progressive enhancement for static HTML - you get the anchor link as a fallback, but JavaScript hijacks it to load inline on demand just before it scrolls into view.
\nOne optimization worth highlighting: instead of each link-loader creating its own IntersectionObserver, they all share singleton instance created at the module level where the web component is defined.
let sharedObserver = null;\n\nfunction getSharedObserver() {\n if (!sharedObserver) {\n sharedObserver = createLazyLoadObserver(...);\n }\n return sharedObserver;\n}`\nThis is more efficient than creating hundreds of observers for each link-loader. The browser can optimize intersection calculations across all elements at once, and it reduces memory overhead. Each component just registers itself with the shared observer when it mounts, and unregisters when it unmounts.
\nAnother challenge from here: you can't fire off hundreds of fetch requests simultaneously. Well, you can, but the browser gets a bit cranky. So, I built a generic LoadQueue class that manages queued loads with tuneable concurrency:
class LoadQueue {\n constructor({\n maxConcurrent = 1, // How many loads at once?\n isVisible, // (function) Is this item currently visible?\n isLoaded, // (function) Already loaded?\n startLoad, // (function) How to load it\n }) { /* ... */ }\n}\nA subtle but important optimization: when a link-loader triggers an IntersectionObserver event, it gets enqueued immediately. But the queue doesn't start fetching right away - it waits its turn based on concurrency limits. Then, the LoadQueue re-checks visibility when it's actually time to fetch:
process() {\n while (this.currentlyLoading.size < this.maxConcurrent && this.queue.length > 0) {\n const item = this.queue.shift();\n\n // Check visibility RIGHT NOW, not when enqueued\n if (!this.isVisible(item)) {\n continue; // Skip and try next item\n }\n\n // Actually start loading\n this.startLoad(item, onComplete);\n }\n}\nWhy does this matter? Because earlier loads in the queue inject content into the DOM, which pushes subsequent elements down the page. An element that was near-visible when it entered the queue might be way off-screen by the time its turn comes up. This re-check prevents wasted fetches for content that was scrolled away while waiting in the queue.
\nBefore I implemented this, I'd get dozens of feeds loading into the page unseen, just because their narrow stubs were briefly visible before they got pushed down. I actually managed to crash the browser on my phone with this, a few times. Now, only the stuff I actually scroll to gets fetched.
\nSince I group items from the same feed together, I wanted a way to easily skip to the next feed once I started seeing familiar content. So, I built a feed-navigator component that wraps all the feed loaders and provides prev/next buttons and a dropdown to jump to specific feeds.
![\"feed-navigator](\"./feedspool-feed-navigator-screenshot.png\")
\n The <feed-navigator> also uses a CSS trick worth mentioning: display: contents, which I only really learned about when I started wrestling more with custom elements.
This is perfect for wrapper components that add behavior but shouldn't affect layout. The feed-navigator wraps all the feed loaders in the DOM tree, giving it control over them, but it doesn't create a containing block or participate in layout. It's completely transparent to CSS.
The component itself:
\nWhen pagination is enabled, there's a two-level hierarchy:
\npage-{n}.html filesfeeds/{id}.html filesWhen a page loader fires, it injects more link-loader elements (for individual feeds) into the DOM. The feed navigator's MutationObserver detects these new elements and starts observing them too.
I found this two-level system works really well for my use case, to help spread out the feed loading. The initial page load is super fast since only a few page stubs are loaded. As I scroll, more pages load, and within those pages, individual feeds load as I approach them.
\n--max-items option for capping rendered itemsThis release makes feedspool-go more comfy for my daily RSS reading. The minimum items feature helps me see quieter feeds and the lazy loading system makes it snappy even with my large feed collection.
\nNext up: I'm thinking about keyboard shortcuts and maybe further specialized feed pages. Also considering tinkering with some more advanced stuff with the database, like running items through an embedding model so I can do some topical clustering or search.
\nI might also just wander off and do nothing else with this until summer. Who knows?
\nAnyway, the full changelog for v0.2.0 is on GitHub. Check it out if it sounds handy!
\n", "body": "*TL;DR*: Released v0.2.0 of feedspool-go, my static-site RSS reader. Added features to keep infrequent feeds from vanishing and an over-engineered web component lazy-loading system that progressively loads content as you scroll.\n\n\n\n\n\n## What is feedspool-go?\n\nI started this thing last fall, but I don't think I've blogged about it much yet.\n\n[feedspool-go](https://github.com/lmorchard/feedspool-go) is a CLI tool I built for fetching & reading RSS feeds. It takes OPML & text lists of feeds, fetches those feeds periodically into a SQLite database, and produces static HTML as a reading interface. \n\nThe \"spool\" part is [inspired by Usenet](https://en.wikipedia.org/wiki/Spooling#Other_applications) and the \"-go\" part is because I've [started and abandoned](https://github.com/lmorchard?tab=repositories&q=feedspool&type=&language=&sort=) several iterations of this thing in other languages over the years. Maybe this one will stick and I'll more creatively rename it later. 😅\n\nThis runs every 15 minutes on one of my machines at home. If the web server's running, you might be able to read my news at [feedspool.lmorchard.com](https://feedspool.lmorchard.com/).\n\nHere's a screenshot from mid-scroll:\n\n\n \n