Atom é melhor do que RSS, em aspectos que importam

Artigo original ↗ Discussão no Hacker News ↗

Atom é amplamente visto como uma alternativa tecnicamente mais limpa e consistente ao RSS para feeds da web, especialmente ao lidar com HTML, codificação de caracteres e metadados sem ambiguidade, embora o RSS continue dominante por inércia e suporte legado (notavelmente em podcasts). Comentadores observam que a maioria dos leitores de feeds modernos suporta ambos de forma transparente, que poucos usuários finais se importam com a distinção e que opções mais novas como JSON Feed podem ser mais práticas para desenvolvedores. A conversa também aborda detalhes de implementação, como armazenar dados de feeds em bancos de dados, estratégias de polling e atualização, e os problemas de permitir HTML rico (como código ou ênfase) em títulos.

Atom vs RSS: Méritos Técnicos

  • Muitos argumentam que Atom é estritamente melhor especificado e menos ambíguo do que RSS, especialmente para codificação, timestamps e conteúdo misto.
  • Atom lida com < / & em títulos de forma limpa e suporta resumos além de conteúdo completo; isso evita bugs de codificação vistos em feeds RSS do mundo real.
  • Críticos observam que a correção XML do Atom pode ser “irritante” (por exemplo, XHTML vs HTML5, links auto-referenciais absolutos obrigatórios), mas defensores dizem que o parsing XML adequado torna isso direto.
  • Alguns apontam que o RSS tem várias versões incompatíveis, minando alegações sobre sua vantagem de “compatibilidade retroativa”.

Adoção, Nomeação e “Pior é Melhor”

  • Padrão comum: tudo é coloquialmente chamado de “RSS”, mesmo quando o feed subjacente é Atom.
  • Vários comentaristas comparam RSS vs Atom a VHS vs Betamax ou “pior é melhor”: o tecnicamente inferior, mas anterior e mais simples, vence. Outros contestam que o VHS tenha sido realmente pior.
  • Uma visão: pouquíssimas pessoas usam quaisquer feeds agora (em relação a todos os usuários da internet). Outra: os números absolutos de usuários de RSS/Atom podem ser maiores do que nunca, ainda que sejam uma pequena fração da população web de hoje.

Preocupações de Desenvolvedores: Parsing e Armazenamento

  • Conselho prático:
    • Para um leitor, faça parsing dos feeds e armazene campos normalizados (título, autor, datas, conteúdo) em colunas.
    • Armazene também o XML bruto (por exemplo, uma coluna text/XML, ou em armazenamento blob mais barato) para permitir reprocessamento caso a lógica mude.
    • Use GUIDs para detectar itens novos/atualizados; não apague os ausentes só porque desaparecem do feed.
    • Ao fazer polling, use HTTP HEAD para verificar se o conteúdo mudou antes do GET; WebSub pode fornecer push para alguns feeds.
  • Alguns observam que muitos feeds são gerados por scripts frágeis e legados, causando XML/HTML malformado e bugs de codificação.

Títulos, HTML e Consistência da UI

  • Um lado: permitir HTML (especialmente <code>, <em>) em títulos é semanticamente útil e já é suportado pelo Atom.
  • Outro lado: títulos aparecem em listas; variações de formatação e sanitização de HTML tornam as UIs confusas e complexas. Eles argumentam que títulos deveriam se comportar como <title> em HTML (texto simples).
  • Há preocupação com subconjuntos inconsistentes de HTML permitido e com problemas de segurança/sanitização.

Formatos Alternativos: JSON Feed, ActivityPub, Fediverse

  • Vários expressam preferência por JSON Feed: mais simples, sem XML, campos pragmáticos (favicon/icon), projetado do ponto de vista do leitor.
  • Outros gostam de Atom, mas reconhecem que a ferramenta JSON é hoje mais ubíqua.
  • ActivityPub/Fediverse é mencionado brevemente como “a nova coisa”, mas os detalhes não são discutidos em profundidade.

Miscelânea

  • Podcasts são destacados como um domínio ainda fortemente ligado ao RSS 2.0 mais extensões personalizadas; algumas grandes plataformas de podcast explicitamente abandonaram ou nunca suportaram totalmente Atom.
  • Alguns usuários querem modelos mais “ativos” ou orientados a push (por exemplo, semelhantes a POP3, WebSub, conceitos local-first/fediverse) em vez de polling constante.
  • Há o desejo de indicadores padronizados de “completo vs parcial” em feeds e de feeds de comentários de usuários no HN.