3 ms·

While I use RSS, I think we need to recognize that it's slowly going away. Even a single publisher that's missing a feed will be a deal-breaker for any new adop

While I use RSS, I think we need to recognize that it's slowly going away. Even a single publisher that's missing a feed will be a deal-breaker for any new adopters. And RSS is an over-complex solution anyway, designed for a time before web standards when sites all had spaghetti table layouts. Today there's no need to create a whole shadow site in fussily-formatted XML for what can usually be found in the page source of the article list page as a bunch of `<li>`s. The more sustainable solution, I believe, is client-based: RSS readers that also parse HTML. There is even an HTML attribute schema, `hfeed`, that makes this easy-peasy and is much easier to implement for publishers. I still don't understand why this solution has not taken off yet. It's clearly optimal.

_heimdall 2y ago
At least for me, there is still benefit in being able to load only the list of articles. Attempting to fetch the full HTML and scrape it can be error prone and may not even work depending on how the site is using client-side rendering. Microformsts, which give us things like h-feed, are useful but the author is already thinking about the feed reader use case. Why wouldn't they also hook up an RSS feed?
- bluebarbet 2y ago
  The scraping issue is resolved by just putting the `h-feed` attributes on the relevant HTML elements. Far easier to implement and maintain than RSS. Maintaining a parallel XML endpoint is itself very error-prone, I know this from unpleasant experience. The only drawback to `h-feed` I can see is that the feed reader must fetch a larger initial payload. Seems like a small price to pay for much easier implementation and maintainability.
  - _heimdall 2y ago
    Do RSS readers and libraries do a good job of parsing out the feed without all the related microformats tags like h-entry, p-title, etc? I've found microformats to be just as much work to maintain (assuming more than just h-feed is needed these days). Its still easy to break silently, and if I care enough to make it I'll automate a test. Testing an RSS feed shouldn't be any harder than testing the rendered HTML to catch silent regressions.
account42 2y ago
> While I use RSS, I think we need to recognize that it's slowly going away. Do we? > Even a single publisher that's missing a feed will be a deal-breaker for any new adopters. Is a single publisher not being on your favorite social media app also a deal breaker? Where does this absurd requirement come from - most people already end up visiting multiple sources for their daily updates. If RSS can reduce that it's useful even if you still need more than one. > And RSS is an over-complex solution anyway It's extremely simple compared the "modern" alternatives (social media APIs). > I still don't understand why this solution has not taken off yet. It's clearly optimal. Because it doesn't actually improve anything over the status quo. You still need to do the work to implement it whether it's inline or a separate file for the feed and the inline version is more prone to breakage with website changes.

_heimdall 2y ago

At least for me, there is still benefit in being able to load only the list of articles. Attempting to fetch the full HTML and scrape it can be error prone and may not even work depending on how the site is using client-side rendering. Microformsts, which give us things like h-feed, are useful but the author is already thinking about the feed reader use case. Why wouldn't they also hook up an RSS feed?

bluebarbet 2y ago
The scraping issue is resolved by just putting the `h-feed` attributes on the relevant HTML elements. Far easier to implement and maintain than RSS. Maintaining a parallel XML endpoint is itself very error-prone, I know this from unpleasant experience. The only drawback to `h-feed` I can see is that the feed reader must fetch a larger initial payload. Seems like a small price to pay for much easier implementation and maintainability.
- _heimdall 2y ago
  Do RSS readers and libraries do a good job of parsing out the feed without all the related microformats tags like h-entry, p-title, etc? I've found microformats to be just as much work to maintain (assuming more than just h-feed is needed these days). Its still easy to break silently, and if I care enough to make it I'll automate a test. Testing an RSS feed shouldn't be any harder than testing the rendered HTML to catch silent regressions.

account42 2y ago

> While I use RSS, I think we need to recognize that it's slowly going away. Do we? > Even a single publisher that's missing a feed will be a deal-breaker for any new adopters. Is a single publisher not being on your favorite social media app also a deal breaker? Where does this absurd requirement come from - most people already end up visiting multiple sources for their daily updates. If RSS can reduce that it's useful even if you still need more than one. > And RSS is an over-complex solution anyway It's extremely simple compared the "modern" alternatives (social media APIs). > I still don't understand why this solution has not taken off yet. It's clearly optimal. Because it doesn't actually improve anything over the status quo. You still need to do the work to implement it whether it's inline or a separate file for the feed and the inline version is more prone to breakage with website changes.