Atom is better than RSS, in ways that matter

Original Article ↗ Hacker News Discussion ↗

Atom is widely seen as a technically cleaner, more consistent alternative to RSS for web feeds, especially when handling HTML, character encoding, and unambiguous metadata, yet RSS remains dominant by inertia and legacy support (notably in podcasting). Commenters note that most modern feed readers transparently support both, that few end users care about the distinction, and that newer options like JSON Feed can be more practical for developers. The conversation also touches on implementation details such as how to store feed data in databases, polling and update strategies, and the pitfalls of allowing rich HTML (like code or emphasis) in titles.

Atom vs RSS: Technical Merits

  • Many argue Atom is strictly better specified and less ambiguous than RSS, especially for encoding, timestamps, and mixed content.
  • Atom handles < / & in titles cleanly and supports summaries plus full content; this avoids encoding bugs seen in real-world RSS feeds.
  • Critics note Atom’s XML correctness can be “annoying” (e.g., XHTML vs HTML5, required absolute self-links), but defenders say proper XML parsing makes this straightforward.
  • Some point out RSS has multiple incompatible versions, undermining claims about its “backwards compatibility” advantage.

Adoption, Naming, and “Worse is Better”

  • Common pattern: everything is colloquially called “RSS” even when the underlying feed is Atom.
  • Several commenters compare RSS vs Atom to VHS vs Betamax or “worse is better”: technically inferior but earlier and simpler wins. Others dispute that VHS was actually worse.
  • One view: very few people use any feeds now (relative to all internet users). Another: absolute RSS/Atom user numbers might be higher than ever, just a small fraction of today’s web population.

Developer Concerns: Parsing and Storage

  • Practical advice:
    • For a reader, parse feeds and store normalized fields (title, author, dates, content) in columns.
    • Also store raw XML (e.g., text/XML column, or in cheaper blob storage) to allow reprocessing if logic changes.
    • Use GUIDs to detect new/updated items; don’t delete missing ones just because they disappear from the feed.
    • When polling, use HTTP HEAD to check if content changed before GET; WebSub can provide push for some feeds.
  • Some note that many feeds are generated by fragile, legacy scripts, causing malformed XML/HTML and encoding bugs.

Titles, HTML, and UI Consistency

  • One side: allowing HTML (especially <code>, <em>) in titles is semantically useful and already supported by Atom.
  • Other side: titles appear in lists; formatting variations and HTML sanitization make UIs messy and complex. They argue titles should behave like HTML <title> (plain text).
  • There’s concern about inconsistent subsets of allowed HTML and security/sanitization issues.

Alternative Formats: JSON Feed, ActivityPub, Fediverse

  • Several express preference for JSON Feed: simpler, no XML, pragmatic fields (favicon/icon), designed from the reader’s perspective.
  • Others like Atom but acknowledge JSON tooling is more ubiquitous today.
  • ActivityPub/Fediverse is briefly mentioned as “the new thing,” but details are not deeply discussed.

Miscellaneous

  • Podcasts are highlighted as a domain still heavily tied to RSS 2.0 plus custom extensions; some major podcast platforms explicitly dropped or never fully supported Atom.
  • A few users want more “active” or push-like models (e.g., POP3-like, WebSub, local-first/fediverse concepts) instead of constant polling.
  • There’s a wish for standardized “full vs partial” indicators in feeds and for user-comment feeds on HN.