7 ms·

It seems that RSS feed generators are a bit like static site generators: it's often thought to be easier to make your own than to learn to use someone else's.

It seems that RSS feed generators are a bit like static site generators: it's often thought to be easier to make your own than to learn to use someone else's. Anyway, here's another self-hosted open source RSS feed generator for arbitrary websites: https://github.com/hueyy/HungryHippo https://github.com/hueyy/HungryHippo

Vinnl 5y ago
I mean, it's exactly like a static site generator — I'd call it JAMstack, except the "API" is a plain HTML page and the markup is RSS :) So yeah, definitely straightforward enough for a case of NIH syndrome. I think putting together the website took more time than writing the tool itself...
lucideer 5y ago
Because the design of RSS/Atom put all of the complexity on the client (polling, state management, etc.) it's literally the same as static site generation. And by "the same", I don't mean "an equivalent but separate problem". I actually think having two separate generators—one outputting HTML, the other RSS—seems a bit wasteful. They're both parsing (presumably) the same content hierarchy and outputting it as SGML/XML-ish documents served over HTTP. One app should probably just do both (and it's easy to make your own that does)
- askhan 5y ago
  This entire post has galvanized me to write up an idea I've been noodling over as I work on a reader myself: a standard that would eliminate precisely the waste you mention by specifying within the HTML all that's needed for a feed. See https://sfeed.org https://sfeed.org. In the spirit of the multi-meaninged RSS acronym itself, the S might stand for scrape, selector, speed, or of course Scotty. Vinni, might you be interested in enabling the standard in Feed Me Up?
  - Vinnl 5y ago
    There already is such a standard! https://microformats.org/wiki/hatom https://microformats.org/wiki/hatom Happy to take a merge request that adds the option to set `extends = "sfeed"` or `extends = "hatom"` and then automatically sets the correct selectors though. (That said, if a publisher goes through the trouble of adhering to those selectors, they might as well publish a feed while they're at it :)
    - detaro 5y ago
      https://microformats.org/wiki/h-feed https://microformats.org/wiki/h-feed is the up-to-date version
      - askhan 5y ago
        I like this name better — the h prefix is cool in that it shows things are coming all the way from basic HTML. Microformats, I see this is the proper way.
      - Vinnl 5y ago
        Ah thanks - been out of that world for a long time now.
    - askhan 5y ago
      Ah thanks, didn't know about hAtom, will investigate that. I do think it's (much) easier to add some HTML classes than output an entire separate file. I've been using Nuxt + Strapi as my new CMS stack, and while it's a big step forward in so many other ways, outputting an RSS feed is far from automatic.
- pedro1976 5y ago
  I disagree. I find the it wasteful, that every source will implement their way of rendering data. If we ignore the ad-problem for a moment, I would love if RSS would be the output of every website and the client then renders HTML to achieve the best UX possible. No broken layouts, no distractions, no dark pattern, just content.
  - niutech 5y ago
    This is more less how Google Web Light worked.
pedro1976 5y ago
I created a automated HTML->Feed mapper [0], that simply analyzes the structure and offers you potential feeds. [0] https://github.com/damoeb/rss-proxy/ https://github.com/damoeb/rss-proxy/

Vinnl 5y ago

I mean, it's exactly like a static site generator — I'd call it JAMstack, except the "API" is a plain HTML page and the markup is RSS :) So yeah, definitely straightforward enough for a case of NIH syndrome. I think putting together the website took more time than writing the tool itself...

lucideer 5y ago

Because the design of RSS/Atom put all of the complexity on the client (polling, state management, etc.) it's literally the same as static site generation. And by "the same", I don't mean "an equivalent but separate problem". I actually think having two separate generators—one outputting HTML, the other RSS—seems a bit wasteful. They're both parsing (presumably) the same content hierarchy and outputting it as SGML/XML-ish documents served over HTTP. One app should probably just do both (and it's easy to make your own that does)

askhan 5y ago
This entire post has galvanized me to write up an idea I've been noodling over as I work on a reader myself: a standard that would eliminate precisely the waste you mention by specifying within the HTML all that's needed for a feed. See https://sfeed.org https://sfeed.org. In the spirit of the multi-meaninged RSS acronym itself, the S might stand for scrape, selector, speed, or of course Scotty. Vinni, might you be interested in enabling the standard in Feed Me Up?
- Vinnl 5y ago
  There already is such a standard! https://microformats.org/wiki/hatom https://microformats.org/wiki/hatom Happy to take a merge request that adds the option to set `extends = "sfeed"` or `extends = "hatom"` and then automatically sets the correct selectors though. (That said, if a publisher goes through the trouble of adhering to those selectors, they might as well publish a feed while they're at it :)
  - detaro 5y ago
    https://microformats.org/wiki/h-feed https://microformats.org/wiki/h-feed is the up-to-date version
    - askhan 5y ago
      I like this name better — the h prefix is cool in that it shows things are coming all the way from basic HTML. Microformats, I see this is the proper way.
    - Vinnl 5y ago
      Ah thanks - been out of that world for a long time now.
  - askhan 5y ago
    Ah thanks, didn't know about hAtom, will investigate that. I do think it's (much) easier to add some HTML classes than output an entire separate file. I've been using Nuxt + Strapi as my new CMS stack, and while it's a big step forward in so many other ways, outputting an RSS feed is far from automatic.
pedro1976 5y ago
I disagree. I find the it wasteful, that every source will implement their way of rendering data. If we ignore the ad-problem for a moment, I would love if RSS would be the output of every website and the client then renders HTML to achieve the best UX possible. No broken layouts, no distractions, no dark pattern, just content.
- niutech 5y ago
  This is more less how Google Web Light worked.

pedro1976 5y ago

I created a automated HTML->Feed mapper [0], that simply analyzes the structure and offers you potential feeds. [0] https://github.com/damoeb/rss-proxy/ https://github.com/damoeb/rss-proxy/