1. 20
  1.  

  2. 4

    What problem does this solve?

    “JSON is simpler to read and write, and it’s less prone to bugs”

    “For most developers, JSON is far easier to read and write than XML”

    Nobody is generating or reading feeds manually, we do it with libraries. These libraries have been around for 10+ years. Users never get to read the content so aiming for readability is useless.

    My code consists of object calls like feed.item[0].content and feed.author. Why would I need a JSON formated feed? The object calls would be exactly the same, only to another library.

    Again, I honestly don’t get it. Why try to push a format which spec is exactly the same as the previous one, only implemented in another language? These guys have been around for many years so they clearly know what they’re doing.

    I love json and use it everywhere but this seems like a clear case of NIH.

    1. 4

      Parsing a classic RSS feed is a pain though, with so many different edge cases and different implementations that it’s almost impossible to do a good one from scratch. Atom is a little better, but not as wide spread. A simple format with good documentation that’s easy to implement correctly for both new publishers and new readers can be nice.

      It’s not the only one of it’s kind though, with some alternatives being eg. https://indieweb.org/h-feed which comes from the point of view that if one already has a list of posts in ones HTML, why do one need to publish another list of posts? Can’t one just decorate that list so that readers can understand them and that way get a more DRY and possibly more accurate list of posts? (Another problem with RSS-feeds has been that they often get neglected and forgotten so that meta-data such as images become a bit unrepresentative and eg. far worse than the image quality that publishers are giving to Facebook and such, so building feed technology from the perspective of the new social web and the way that Facebook, Twitter etc consumes stuff can have its advantages in data quality)

      1. 3

        Parsing a classic RSS feed is a pain though, with so many different edge cases

        Yes, but the reason is not XML. Whoever did not migrate from RSS to Atom, will not migrate to JSONFeed either.

        1. 2

          I agree, the reason is mainly not XML, although XML contributes in some places as it allows more complex data structures than JSON

          And yeah, adoption will be hard.

        2. 2

          Aside from h-feed, there’s the schema.org markup, which might be more widely supported (i.e. Google). HTML5 itself (possibly with ARIA) contains plenty of ways to mark up a blog.

          I’d still stick to serving Atom to clients that request it though, there’s nothing wrong with the format, and it has precise semantics.

        3. 3

          The only point I disagree with you on is that this is exactly the same as RSS/Atom; it looks simpler and better defined to me. But other than that, I can only offer an anecdote on why an updated feed format might be a good idea:

          When Mastodon was still getting hype, I thought it would be fun to publish my twitter feed on my own server and see who would subscribe to it. But I looked at the specs (RSS/Atom, PubSubHubBub) and thought, “Nah, I don’t want to mess with XML today.” Maybe I’m a bad person. Probably I am. :) But I bet I’m not the only one out there, so having a cleaner, nicer way to construct feeds might lower the barrier and get more people to publish.

          1. 1

            You’re definitely not a bad person, I’d dare say that the real bad guy is the one who invented XML ;)

            However, why didn’t you use a library? It’s been a long time since I interacted with XML manually. Even DOM manipulating is XML manipulating (well, simplified XML) but we do it via selectors (CSS, xpath) and never manually parsing the XML tree.

          2. 3

            These libraries have been around for 10+ years.

            And they still suck. We still see builds fail because a third-party web site stopped hosting a schema. We still see xpaths failing to work until you preload the list of namespaces you’re using or some other such horrible shennanigans.

          3. 2

            JSON is simpler to read and write, and it’s less prone to bugs

            Fun thing; there is this small Python library called xmltodict. It translates the example RSS feed into native data types that look like this:

            rss:
              '@version': '2.0'
            
              channel:
                description: Free web building tutorials
                link: https://www.w3schools.com
                title: W3Schools Home Page
            
                item:
                  - title: RSS Tutorial
                    description: New RSS tutorial on W3Schools
                    link: 'https://www.w3schools.com/xml/xml_rss.asp'
            
                  - title: XML Tutorial
                    description: New XML tutorial on W3Schools
                    link: 'https://www.w3schools.com/xml'
            

            It can also re-create the original XML. Rather comfortable for smaller documents.

            1. 2

              I don’t have a problem with this. I’ve been listening to people carp about how difficult RSS’s quirks can be to deal with.

              Maybe it’ll gain wide adoption, maybe it won’t - but I can’t blame them for trying. This is how we make progress, right?

              1. 3

                Stability is also nice. Especially for protocols intended for wide consumption.

              2. 0

                JSON all the things!

                1. 1

                  I did generated RSS and Atom feeds manually (without library) and I must say, that I would choose JSON any time.