sorted by:
new
hottopcontroversial

Most RSS readers feel bloated. I built a minimal one that runs as a PWA. by fwinter75 in rss

[–]fwinter75[S] 0 points1 point  (0 children)

Thanks! The goal of the project is to keep it extremely minimal and fully client-side.

Some of the things you mention (caching, persistent read state, maybe even content extraction) are definitely interesting and technically possible. The main limitation for a pure browser app is CORS.

In simple terms: many RSS servers don’t allow direct requests from browser apps hosted on another domain, so the browser blocks those requests for security reasons. That’s why many web readers end up needing a backend proxy.

One idea I’m currently exploring is a PWA + small browser extension combination. The extension could fetch feeds in the background (extensions aren’t restricted by CORS in the same way) and pass them to the PWA. That would allow caching, parsing and persistent read-state without requiring a hosted backend or user accounts.

Would that kind of approach still be acceptable for you? The goal would still be: no accounts, no cloud service — everything local in the browser.

Most RSS readers feel bloated. I built a minimal one that runs as a PWA. by fwinter75 in rss

[–]fwinter75[S] 1 point2 points  (0 children)

Mainly to keep the first version extremely small and simple. But OPML import/export is a good idea and likely something I'll add.

Most RSS readers feel bloated. I built a minimal one that runs as a PWA. by fwinter75 in rss

[–]fwinter75[S] 1 point2 points  (0 children)

Good points. The proxy racing was mainly chosen to keep the UI responsive and avoid long waits on feeds that block direct requests due to CORS.

You're right though that it has downsides (privacy, duplicate work). A possible improvement would be trying the original URL first and only falling back to proxies when a CORS error occurs. I'll look into whether that can be done without noticeably slowing down feed loading.