We — Manton Reece and Brent Simmons — have noticed that JSON has become the developers’ choice for APIs, and that developers will often go out of their way to avoid XML. JSON is simpler to read and write, and it’s less prone to bugs.

Two very smart guys that I respect a lot. I’m going to take a look at this.

  • Look at the list of reviewers at the bottom of the spec. That alone tells me this is solid stuff.

  • rick gregory

    I’m confused. Huge respect to those guys but… why? RSS readers are a relative niche and I can’t see enough sites switching to make it worthwhile for reader devs to switch. WordPress can already emit JSON via its REST API although not in that format… but if you want to interact with it that way it has a native API.

    I don’t get the point.,

    • I can see an immediate use to this in any app that has a news feed. I’d much rather hook to a JSON feed than use a library to interpret RSS, and there’s enough legacy stuff in RSS that it certainly wouldn’t be a couple lines of code instead of that library.

      • rick gregory

        Sure, for a defined need (an internal site etc) I can see that. But if I’m writing something to consume information from arbitrary sites out there and they already emit RSS I don’t see the advantage. I’m not going to be able to rely on all of them moving to this flavor of JSON so I have to continue to support the RSS/Atom stuff AND do this?

        • You’re right in both cases. But that’s not my use case.

          Not too long ago, we used Twitter to run a status update on one of our applications. Twitter change the rules and dropped the per-user RSS feed (at least for a while?) so it became not an option.

          I could see using a WordPress site with the JSON Feed plugin to feed the app’s sense of status.

          As a channel between components, this is top notch. That it’s a proposed standard really doesn’t matter. Other people will use it or won’t; it’s already found a place.