Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atom is better than RSS, in ways that matter

chrismorgan.info

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Atom is better than RSS, in ways that matter

#31

Post by tjansen »

I agree that Atom is easier to use and better defined in some ways. But why on earth would you want to put unrestricted HTML in the title in the first place? How is a reader supposed to handle that? It's just a weird thing to allow.

In practice, the differences between the syndication formats don't really matter. Today even less than when they were created, as a solution for most of the differences is just a prompt away.

In my humble opinion, JSON feed (https://www.jsonfeed.org/version/1.1/) is the most practical format. By a small margin, but still...

- it's really simple and doesn't use XML

- it doesn't allow stupid things like HTML in titles (which I guarantee >50% of all implementations can't handle correctly)

- JSON Feed allows feeds to have a and a (square!) , which is a very practical thing for readers. You can use the in lists of feeds, and the to present a single feed. Atom has a small square icon and a which is supposed to use a 2:1 aspect ratio. 2:1 is completely useless. No site has a logo in 2:1. It's also useless for most full-name logos, like 'New York Times'. (RSS is, of course, even worse; it doesn't even recommend an aspect ratio, practically guaranteeing that RSS readers can look bad)

You can see that JSON feed has been designed from a feed consumer's point of view: what does an RSS reader need to make a feed look good? While Atom and RSS have been written from an abstract publisher's point of view, making everything possible and allowing maximum flexibility. Especially RSS, which has shown its flexibility in becoming the de facto format for podcasts. And both Atom and RSS are really old, written at a time when it probably wasn't clear how RSS would eventually be used.

In the end, no matter which format a feed uses, users won't notice any difference (as long as publishers are smart enough to use square images!). So any feed is a win, no matter whether RSS, Atom, or JSON feed.

Re: Atom is better than RSS, in ways that matter

#32

Post by benj111 »

thaumasiotes wrote: post #4
superkuh wrote: post #2

Atom is better than RSS in the way Betamax was better than VHS. With the same outcome and consequences for practical use.

What? Not at all. RSS is a product category. Many RSS feeds are, if you look into them, Atom. Your RSS reader just doesn't bother to tell you, because why would you care? Try putting a Betamax tape into a VHS VCR and see if you can watch it.

To extend the metaphor though. An RSS reader that works with atom is the same as a VHS player that also has a beta max player. Or your blueray player that plays dvds and CDs....

Re: Atom is better than RSS, in ways that matter

#33

Post by LAC-Tech »

thaumasiotes wrote: post #4
superkuh wrote: post #2

Atom is better than RSS in the way Betamax was better than VHS. With the same outcome and consequences for practical use.

What? Not at all. RSS is a product category. Many RSS feeds are, if you look into them, Atom. Your RSS reader just doesn't bother to tell you, because why would you care? Try putting a Betamax tape into a VHS VCR and see if you can watch it.

huh, I call the atom feed on my site an atom feed. I wonder if that confuses people...

Re: Atom is better than RSS, in ways that matter

#34

Post by notpushkin »

leoc wrote: post #30
4ndrewl wrote: post #17

Earlier quoted context omitted.

Isn't this just VHS v Betamax again?

While a worse format surely could have won something like the video wars, it doesn't seem that VHS was in fact the worse format overall: https://www.youtube.com/watch?v=FyKRubB5N60 (Part 2: https://www.youtube.com/watch?v=v019trxfcmg . Quality comparison: https://www.youtube.com/watch?v=_oJs8-I9WtA ) Beta was basically optimised for one thing, reasonable cassette size, and the tradeoffs turned out probably not to be…

Moreover, the VHS cassete itself is arguably a better design! https://www.youtube.com/watch?v=hWl9Wux7iVY

Re: Atom is better than RSS, in ways that matter

#36

Post by latexr »

Personally, I don’t care at all since we’ve gotten JSON feeds.

https://en.wikipedia.org/wiki/JSON_Feed

Not every programming language I use can output RSS/Atom/XML by default, but pretty much all of them can output JSON natively, no library needed, just fine. The spec is short and easy to understand, to the point it’s little effort to manipulate the feeds, adding to them or consuming them even without a dedicated reader if need be.

To consume other people’s feeds, I mostly don’t care what format they are as long as my reader can understand them. To generate my feeds, I always use JSON. Most of them are for personal use, but even for those which aren’t, I never had any complaints (most feed readers seem to be able to read those just fine).

Re: Atom is better than RSS, in ways that matter

#37

Post by setr »

vivzkestrel wrote: post #28
Kwpolska wrote: post #24

Earlier quoted context omitted.

If you're building a RSS reader, you'd probably want to process the data and store all relevant fields as columns for storage. Not much point to storing the XML. Entries in feeds should have a guid you can use to detect updates/entries you have already seen. RSS readers typically don't delete entries that disappeared from the feed - entries disappear from feeds to limit their size. You can get live updates to some RS…

- the idea behind storing the raw feed items instead of processed ones is - what happens if your processing logic changes 6 months down the line? - for example today you decide you want to remove all extra spaces and lowercase all titles before storing them - 6 months down the line you want to revert, what now?

For that purpose, you’re perfectly well off just leaving it as an opaque blob; compress, base64 encode and stuff it into a string/varbinary column and call it a day.

You don’t even need to store it in pg itself; stuff it into a cheaper datastore like s3 and just have the locations stored in pg.

The only thing to optimize for is cost & storage. Access/retrieval doesn’t matter for a once in 6 months process.

Also what is this revolting formatting strategy you’ve found?

Re: Atom is better than RSS, in ways that matter

#38

Post by qznc »

Atom is correct to a degree that is annoying.

It is XML, so not all HTML5 is allowed. You would have to convert your HTML5 to XHTML5. Possible but harder than string-concatenation.

It requires full self links, so you must put your domain name in there as relative links would be an error. When using a static generator, why should I care where the files are published?

My website has valid Atom feeds. Still, it's an annoying format to me.

Re: Atom is better than RSS, in ways that matter

#39

Post by mbirth »

latexr wrote: post #36

Personally, I don’t care at all since we’ve gotten JSON feeds. https://en.wikipedia.org/wiki/JSON_Feed Not every programming language I use can output RSS/Atom/XML by default, but pretty much all of them can output JSON natively, no library needed, just fine. The spec is short and easy to understand, to the point it’s little effort to manipulate the feeds, adding to them or consuming them even without a dedicated rea…

But JSON doesn’t allow you to run it through an XSLT and get a normal webpage out of it, does it?

Re: Atom is better than RSS, in ways that matter

#40

Post by robalni »

There are so many formats and standards and people using different sets of them that I feel like we need an organisation that selects some of them and decides that those are the ones that people should use. Everyone could become a member of that organisation and vote for which standards should be part of the next version of the selected set. Maybe there could be a new version every other year or something.

This would give us some kind of leader that shows the way. It would make it easier for developers if people were more focused on fewer standards and there would be a well defined point in time when we would upgrade to the new set of standards.

For those of you who are familiar with RISC-V, it would be like the RVA23 spec: one big collection of things to use that can be targeted and talked about as one thing with one name, rather than everyone having their own collection of extensions that they use.

Post reply on HN