HN Debrief

Atom is better than RSS, in ways that matter

  • Open Standards
  • Developer Tools
  • Media
  • Infrastructure

The post is a technical case for Atom over RSS. It argues that Atom cleaned up RSS’s biggest messes by making the format more precise, especially around text handling, dates, IDs, summaries versus full content, and embedded markup. The article’s headline point is not that users will notice a dramatic product difference, but that developers and feed consumers inherit fewer ambiguities and less broken behavior when a feed is Atom instead of RSS.

If you publish or parse feeds, prefer Atom when you control both ends or want fewer edge cases. If distribution depends on legacy clients, podcast tooling, or broad compatibility, test the actual consumers first and consider shipping RSS or multiple formats.

Discussion mood

Mostly pro-Atom on technical grounds, with impatience toward RSS’s ambiguity and legacy breakage. The pushback centered on whether Atom’s richer title markup is actually a feature, and on the fact that ecosystem constraints like podcasts and old clients often matter more than spec elegance.

Key insights

  1. 01

    RSS pain comes from generators, not readers

    The stronger case against RSS is not that modern readers cannot parse it. It is that publishers still emit sloppy feeds through old CMS code, ad hoc templates, and mixed encodings that leave readers guessing. That makes Atom valuable as a publishing discipline. It removes whole classes of bugs like broken title encoding that otherwise get blamed on the site or the reader.

    If you run a publishing platform, spend more effort on feed generation than feed parsing. Tightening your output format will remove support issues that your users cannot diagnose.

      Attribution:
    • jillesvangurp #1
    • chrismorgan #1
  2. 02

    Podcast distribution still pins you to RSS

    Podcasting remains the clearest place where the technically better format loses. Apple’s ecosystem was described as never meaningfully supporting Atom where it counted, and podcast metadata still rides on RSS 2.0 plus iTunes-style extensions. That makes feed format a market access decision, not just a developer preference.

    If your feed must reach podcast apps, treat RSS compatibility as a product requirement. Do not assume generic feed-reader support tells you anything about podcast ingestion.

      Attribution:
    • rhdunn #1
    • throw0101a #1
    • chrismorgan #1
  3. 03

    Atom strictness is annoying but mostly intentional

    Complaints that Atom is fussy about XML syntax and absolute self links got a useful correction. You only need XHTML rules in specific cases, and absolute links exist for the consumer’s benefit, not the publisher’s convenience. The burden is real, but it buys determinism. That is exactly the trade Atom makes.

    Expect a little more implementation work if you emit Atom from static tools or simple scripts. In return, you get fewer ambiguous interpretations downstream.

      Attribution:
    • qznc #1
    • talideon #1
  4. 04

    Store raw feeds and parsed fields separately

    The best operational advice in the comments was about feed ingestion systems. Keep the original feed payload so you can reprocess later, but also extract the fields your app actually needs into normal columns or related tables. Use item IDs or GUIDs for deduping, do not treat disappeared entries as deletions, and keep the parsing work out of clients.

    If you are building a feed reader or aggregator, design for replay. Persist raw source data alongside normalized records so parser changes do not force you to choose between data loss and a full recrawl.

      Attribution:
    • Kwpolska #1
    • munch117 #1
    • SahAssar #1
    • zaptheimpaler #1
  5. 05

    XML parser quality still decides your pain level

    A lot of Atom complexity collapses if you use a real XML stack and honor namespaces properly. The article’s author was blunt that the title encoding modes are straightforward once you stop treating XML as string munging. That does not make every environment pleasant, but it shifts the blame from the format to weak tooling and shortcut implementations.

    Do not hand-roll feed parsing or generation. Pick libraries that correctly handle XML namespaces, escaped HTML, and content types, then test them with ugly real-world samples.

      Attribution:
    • qznc #1
    • inigyou #1
    • chrismorgan #1 #2
  6. 06

    JSON Feed is the cleaner modern alternative

    Several people treated the Atom versus RSS argument as yesterday’s war and pointed to JSON Feed instead. The appeal was practical rather than ideological. It is easier to produce, easier to manipulate in common languages, and includes metadata readers actually use like icons. The catch is support remains uneven across feed clients.

    If you control the reader or your audience uses modern clients, JSON Feed can cut implementation friction. If compatibility is the priority, you probably still need Atom or RSS alongside it.

      Attribution:
    • tjansen #1
    • BoingBoomTschak #1

Against the grain

  1. 01

    Markup in titles makes readers worse

    The cleanest pushback was that Atom’s support for HTML or XHTML titles is not a practical win. Titles are rendered in lists, notifications, sidebars, and accessibility contexts where the consumer controls typography and spacing. Adding inline semantics sounds nice for code or emphasis, but it creates sanitation work and presentation mismatches for marginal value. Plain text titles keep the UI coherent.

    If you publish feeds, do not assume every feature the spec permits improves the product. Favor titles that survive plain-text rendering without losing meaning.

      Attribution:
    • tjansen #1 #2
    • mcv #1
    • paulddraper #1
  2. 02

    Consumers barely notice the format choice

    From the user side, RSS versus Atom is mostly invisible. Readers usually support both, and when something breaks, users blame the feed or the app rather than the underlying standard. That means format purity has limited end-user payoff unless you are the one absorbing the parser and generator edge cases.

    Choose feed formats based on engineering cost and target distribution, not on the expectation that users will value the distinction. Most of the benefit is operational, not customer-facing.

      Attribution:
    • ladax72707 #1
    • kelnos #1
  3. 03

    The real problem is polling, not syntax

    A few comments cut past the file format debate and argued that both RSS and Atom are stuck with an inefficient pull model. Re-downloading mostly unchanged feeds is wasteful, and neither format cleanly signals full versus partial content. Tools like WebSub help, but the frustration points toward transport and update semantics rather than markup design.

    If you run feed infrastructure at scale, optimize your fetch strategy before obsessing over RSS versus Atom. Conditional requests, push mechanisms, and clear content semantics will save more pain than a format switch alone.

      Attribution:
    • noAnswer #1
    • adrianwaj #1
    • inigyou #1

In plain english

ActivityPub ↩
A protocol for decentralized social networking and content exchange used by services in the Fediverse.
Atom ↩
A web feed format based on XML that was designed as a cleaner, more precisely specified alternative to RSS.
CMS ↩
Content Management System, software used to create and publish website content.
HTML ↩
HyperText Markup Language, the standard markup language used to structure web pages.
JSON Feed ↩
A web feed format that uses JavaScript Object Notation instead of XML to represent feed data.
RSS ↩
Really Simple Syndication, a family of XML-based web feed formats used to publish updates from sites like blogs, news outlets, and podcasts.
WebSub ↩
A protocol that lets publishers push feed updates to subscribers instead of forcing them to poll repeatedly.
XHTML ↩
A version of HTML expressed with XML rules, which makes the syntax stricter than ordinary HTML.
XML ↩
Extensible Markup Language, a text format for structured data that uses tags and strict syntax rules.

Reference links

Feed formats and standards

Article and example pages

Historical context and commentary

Implementation and tooling

Related protocols and alternatives