JSON Feed Announced As Alternative To RSS (jsonfeed.org)

Reader Anubis IV writes: With Slashdot recently asking whether we still use RSS, it may come as a surprise that something interesting has happened in the world of news feeds this week. JSON Feed was launched as an alternative to RSS and Atom, eschewing the XML they rely on -- which is frequently malformed and difficult to parse -- in favor of a human readable JSON format that reflects the decades of combined experience its authors have in the field. The JSON Feed spec is a simple read that lays out a number of pragmatic benefits the format has over RSS and Atom, such as eliminating duplicate entries, adding the ability to paginate feeds so that old entries remain available, and reducing the need for clients to scrape sites to find images and other resources. Given that it's authored by the developers behind one of the earliest, popular RSS clients and a recently Kickstarted blogging platform, the format is intended to address the common pain points currently faced by developers when producing and parsing feeds.

While it remains to be seen whether JSON Feed will escape the chicken-and-egg stage of adoption, several clients have already added support for the fledging format in the week since its announcement, including Feedbin, Inoreader, and NewsBlur.

Comments

Obligatory XKCD

[ttyler]

https://xkcd.com/927/

Re:Obligatory XKCD

[Scarred Intellect]

I share your irrational happiness, but it is together with sadness, as I wanted to post it.

Re:Obligatory XKCD

[chispito]

Except JSON is hardly a new standard, and RSS feeds are so inconsistent with their XML it wasn't much of a standard, either.

Bad reason

[mi]

eschewing the XML they rely on -- which is frequently malformed and difficult to parse

People making mistakes implementing a spec is not in itself a good reason to drop it. There will be malformed JSON, that's to be sure. Do you escape slashes? Are true and false quoted? How long can a number be? Do the numbers use decimal dot or decimal comma — or does it depend on the locale? And, in the latter case, the server's locale or the client's?

I agree, that JSON is easier to read than XML, but not easier enough to change the standard now.

Re:Bad reason

[bill_mcgonigle]

I agree, that JSON is easier to read than XML, but not easier enough to change the standard now.

Yeah, what is the _actual_ problem that RSS/Atom are causing now?

I've written several RSS/Atom readers and writers and never once did I worry about "how hard" XML is to parse. Heck, since like 2003 I've only ever use a popular language library to read/write those formats. Who needs to even parse the XML except the first person to write the library for a new language? I iterate over an object's member objects; I don't parse XML.

It seems like the real problem being solved here is that XML isn't "new hotness" like JSON is, not that anybody is having a problem parsing RSS/Atom feeds. Were we starting over today, sure, use JSON, but we're not.

Re:Bad reason

[KiloByte]

good libraries for reading and writing XML

Let's take a look at the most used one, and see how many pages of serious security vulnerabilities it has. Many of them allow arbitrary code execution...

There is no reason to have malformed XML in 2017.

FTFY: There is no reason to have XML in 2017.

Re:Bad reason

[HornWumpus]

JSON is just XML from the Java ecosystem. Feature for feature...

Whoever made the decision to 'do it yet again' needs to be taken out and kicked square in the balls by every coder that has to waste time on this bullshit.

Re:Bad reason

[AuMatar]

Its less verbose, more easily human readable, and doesn't have the "is this a property of the tag, or data inside the tag" problem. Its a better solution all around. I wouldn't create anything new in xml, but I wouldn't race to remove it in existing apps/protocols unless I'm doing a total v2.

Re:Bad reason

[HornWumpus]

Bullshit. XML with properties is just as tight. Not every property needs to be a subentity. There are decent Wiki articles that lay them out, side by side.

JSON more readable...no comments allowed. No, just no. WRONG.

They are feature for feature compatible, but one is Jave ghetto only, the other is 'everything else'. They should have never have _started_ on JSON, in hindsight it was clearly a mistake.

"is this a property of the tag, or data inside the tag"...I see your mistake. Use a library to parse XML, don't roll your own.

Re:Bad reason

[SQLGuru]

Actually, JSON is slightly lesser in functionality compared to XML. I can validate XML with an XSD spec (and I can transform it with XSLT). But in this context, it's easy enough to compare them based on how they are typically used.

Re:Bad reason

[Darinbob]

Not for XML, but for JSON, I wrote my own library. Had to, one did not exist for the device that met the requirements. Not everything is a PC. And if you do want proper libraries, they will still disagree with each other! One problem I have seen more than once is the assumption that a library is correct merely because it's a library from a third party (as in my fellow coworkers are morons but anyone outside the building clearly has a comprehensive understanding of all the standards and was given enough time to complete the feature without ever feeling rushed).

JSON as a standard is very weak. It's hard to find a well defined specification suitable for implementing. There are a lot of assumptions made. Ie, how do you store binary data? Normally base64 but nothing requires this or specifies what base64 is and how it must be represented and what to do with the leftover odd bytes at the end. But everyone sort of knows as vague tribal knowledge what to do (do what Javascript does, do it the same way Python library does it, etc). It's a simple format, it has much going for it, but it's not formally specified.

Re:Bad reason

[yurikhan]

Bullshit. XML *is* part of the Java ecosystem. JSON is from Javascript which is an entirely different thing.

Kickstarted blogging platform?

[Vyse of Arcadia]

Why are people crowdfunding blogging platforms?

Re:Kickstarted blogging platform?

[hmckee]

Good question. It made me curious so I checked it out. It's not a blogging platform but a micro-blogging platform. First thing I thought was, "So what?" Turns out they're using it as an alternative to bloated social websites that hoard your data. This micro-blog makes it easier to retain your own data, share it with others and easily move it to another service provider. Something like this might have the chance to do what Diaspora couldn't, namely, put ownership of the data with whom it belongs and make social media sites irrelevant.

Obvious solution

[mwvdlee]

Problem: XML is harder to write than JSON.
Proposed solution A: Invent an entirely new format based on JSON and have the entire world adopt it.
Proposed solution B: Write a small library that translates JSON to XML and just use any of the dozens of libraries that already exists to parse RSS feeds.
Let's go for solution A.

Re:Obvious solution

[Anubis IV]

You've listed one problem, and were that the only one, you'd be right. But it wasn't. The summary itself obliquely mentions three other problems...

Problem: Duplicate entries frequently appear in feed clients.
Problem: It's expensive to serve up a feed that contains all of a site's content stretching back for years.
Problem: Clients have to implement their own searching and scraping to find favicons, images, or other resources.

Given all of those, a new format is not just the obvious solution, it's the only solution, which is why they had to create the new format to address those issues, among many other ones. Once you realize that fact, basing it on JSON or something else simply makes sense, what with it having far simpler and more ubiquitous library support in the software stacks involved, which is in addition to it being simpler to read and write.

Oh FFS

[ilsaloving]

I remember when XML was the big thing and everyone was all, "Oooh oooh! Our solution will be so much better if we USE XML!!!11!eleventy"

I also remember then, how stupid this idea was, because there was nothing intrinsic about XML that would improve anything. Sure, XML is a human-readable file format that could be validated against a schema file if you so chose, and that was pretty good, but claiming a file/data format will improve how something functions, is like saying a car will perform better if you put the gas tank on the right side instead of the left.

And here we go, full circle again, except now everyone is ejaculating all over JSON, whose only benefit to XML is that it's slightly less verbose. It has none of the rigour that XML has, but everyone thinks it's great cause it's new and cool, and XML sucks because it's "old".

At least with XML, you can say enforceably say whether the piece of data is malformed or not. With JSON, the best you can do is basic syntax checking. There is no way to enforce the data itself is what it should be.... you have to trust that the other party didn't screw up the contents. The only way to add enforceability is reinvent the wheel in the worst way, by writing your own reference function to validate the data and hope other people use it.

Re:Oh FFS

[tepples]

JSON Schema is a vocabulary that allows you to annotate and validate JSON documents.

Re:Oh FFS

[ilsaloving]

XSLT is a presentation layer component, for translating XML into something else. If you're using it for validation, you're REALLY doing it wrong.

I won't go into details about what you can and cannot do with schemas because there are countless resources that can give far more detailed information than what I can do in a single slashdot post. Suffice it to say, Schemas may not be 100%, but for comparison, JSON has no equivalent to schemas at all.

An AC in another post pointed to a project that is attempting to fill in that gap (http://json-schema.org/), but without something directly in the JSON spec, there best you can hope for are non-standard cobbled together solutions like the above.

Re:

[dgaller]

RSS worked fine, the problem is it was too open. Publishers want you logged in and monetized, with a reader that will display ads, and subscribing through a smart phone app.

Harder to malform the JSON

[SuperKendall]

People making mistakes implementing a spec is not in itself a good reason to drop it.

It is when the mistakes are frequent enough, obviously implementing RSS feeds is rather hard and most sites are really poor at it.

Adding to that is the simple fact that very few server languages have really easy or good XML generation at this point, compared to JSON library support. There are lots more good JSON libraries around and people are more comfortable with them and used to how they work.

There will be malformed JSON, that's to be sure.

Why, when most JSON will be produced by a library that simply maps something out to JSON? Also it's super easy to check JSON validity. If you ask 100 developers today to produce a defined output in JSON and XML, which do you think will have a much higher percentage chance of being correct?

Do you escape slashes? Are true and false quoted? How long can a number be? Do the numbers use decimal dot or decimal comma â" or does it depend on the locale?

Why do you think any of that matters? If the JSON is valid it is valid. Everyone on earth and most libraries are used to accommodating JSON that may have true or false either as boolean values or as strings for example. It simply doesn't matter.

I agree, that JSON is easier to read than XML, but not easier enough

It's WAY easier to generate in a world of developers that uses mostly JSON now and hardly touches XML. That alone is a HUGE reason to switch. Why saddle every website on earth with legacy crap? It's probably a big part of the reason RSS is not as common anymore, and the real crime would be if most sites had nothing like RSS at all...

Re:Harder to malform the JSON

[gnunick]

The only coders using JSON now are java coders. They made a mistake selecting their flat file, hierarchical data format. Should have just build a good XML library in java to start.

Point of order: I've read several messages in this thread where you misassociate JSON with Java, but JSON didn't come from Java.

Its source is right there in the name: Javascript Object Notation.

Now on to subjective matters: XML is a disgusting standard which should die a fiery death. And I say this as someone who works with XML on a daily basis (but more and more JSON these days, thankfully). The fact that good libraries exist to work with it doesn't make it any more palatable to me. JSON is vastly simpler, maps easily to the most common data types, and is (get this...) usually easy (for humans) to read.

Java and XML were stuck together at an early age, and their forced marriage was unfortunately very fecund... but even many Java developers have seen fit to move on, if they're lucky enough to have the chance.

I annonce new formats...

[grumpy-cowboy]

YAML Feed
INI Feed
CSV Feed
PROTOBUF Feed
THRIFT Feed
TSV Feed
TXT Feed
{NEW TRENDY FORMAT} Feed

Podcasts would be the adoption moment I think.

[thewolfkin]

Since the death of Google Reader my most used case of RSS is podcasts. I get the occasional feed notification from IFTTT but most of the websites I used to get RSS from just have direct channels that are a little better and a little easier.

But podcasts however I listen to a fair number of podcasts and I have about 30-40 of them in my reader (Podcast Addict). I'd like a readable JSON format for syndication but if it's going to mess with my podcasts I won't bother.

Not at all true

[SuperKendall]

The only coders using JSON now are java coders.

What about every web or server developer on Earth? Are you not aware that the entire industry has moved to JSON for client to server transmission? ALL of the server people I have worked with in the last decade now have preferred JSON for REST web service calls too. That includes Ruby servers, PHP servers, not just Java stuff. In fact REST was pretty much using JSON from day one except for a few crazy attempts to use XML instead.

The entire iOS development community uses JSON rather heavily also (mostly because of REST calls but also for other purposes)...

Re:Name it J-a-SON Bateman and you'll have my vote

[Oswald McWeany]

But in reality, a watch is quite impractical because the time gets all blurry from the motion of your wrist when you masturbate.

Yes, and a watch is very important during those times because you have to keep an eye on you watch to make sure you don't go beyond 4 hrs.

date_published is optional? Noooo...

[dhasenan]

It's a lot easier to parse a feed into a series of articles if each article entry has something in it that gives a natural ordering.

It's a lot easier to display an integrated collection of feeds if articles have a natural ordering relative to each other.

It was a problem that RSS didn't make publication date mandatory. JSON Feed doesn't solve this problem.