7 ms·

Can part of the renaissance be switching to a JSON format? Please?

ocdtrekkie 9y ago
https://jsonfeed.org/ https://jsonfeed.org/ has had some preliminary traction. Of course, the reason RSS works so well is that everyone uses the same format. So you wouldn't see so much of a "switch" as a bunch of readers accepting either format, for a very, very long time. That being said, I don't see what's "wrong" with XML in this context.
- craftyguy 9y ago
  Most of the complaints I've seen with the 'wrongness' of xml are centered around its human unreadability, which doesn't matter in this context. I'm curious if there's another reason.
  - digi_owl 9y ago
    Bunch of webheads that thinks JS is the end all be all of languages...
  - ken 9y ago
    Legibility isn't just for fun. The entire JSON spec is only about 3 pages long. (I don't know exactly how long because ECMA's webpage is down today!) I'm pretty confident that any popular JSON parser I use will abort correctly on bad JSON. There's no expansion or entities or escaping, so the parser is a pretty boring 1-to-1 translation. Give it a 1KB JSON file, and I'm going to get back a data structure that takes roughly 1KB. XML is incredibly complicated. My operating system's XML parser has had XXE-related security bugs in the recent past -- that's OWASP bug#4, and there's a Wikipedia article about it. There's other possible attacks, like the "billion laughs attack". I'm very nervous about running an XML parser on untrusted content.
    - eropple 9y ago
      Not to be flip, but if you're using a parser written by competent individuals post-2010 (really, post-2008), billion laughs is a nothing. And that follows for most XML stuff. If you are getting most bloggable with your tech stack, yes, there are certainly risks to XML (also to YAML, also to JSON--and there are definitely JSON parsers that have had some capital-I Issues out there, and a good number of the popular ones also parse not-JSON too). That said, if you're using anything remotely mainstream you can feel reasonably secure against the sorts of attacks you are likely to see because, TBH, your RSS reader is just not that valuable a target. (Or, in my case--the podcast service I'm writing.)
  - chipotle_coyote 9y ago
    While I shouldn't speak for JSON Feed's developers (Manton Reece of Micro.blog and Brent Simmons, original developer of RSS/Atom reader NetNewsWire), their argument basically boils down to "developers seem to be better at constructing valid JSON than they are at constructing valid XML." I know a lot of HN folks will say but you can just construct perfectly valid XML with library such-and-such or API this-and-that and, yes, I'm sure they're all absolutely, positively 100% correct. But in my real-world experience, Reece and Simmons seem to be correct in practice. Given that Simmons wrote NNW, worked at the now-defunct server-side RSS company NewsGator, and is now writing a new RSS (and JSON Feed) reader, I'm inclined to believe that when he says JSON Feed "reflects the lessons learned from our years of work reading and publishing feeds," he means it.
    - mcormier 9y ago
      You don’t have to worry about recursive entity definitions in JSON.
    - UncleEntity 9y ago
      It's funny, the only RSS feed I use I turn into json so I can store it tinydb in "native" format. Well, technically, I turn it into a python dict and then tinydb does the conversion to json automagically. Took 50 lines of code which I banged together from google searches. Back before I started using the db backend I was parsing the feed with an auto-generated (from the schema) "rss reader" in python then merging the items into a master rss feed sorted by channels. That worked for a while until I got motivated and made it searchable/modifiable but couldn't find a simple database that I could just dump xml into. Anyhoo, my point is it's easy to work with rss in either native xml or json with some simple tools that do most of the work for you. Would be super easy to bang together a converter that goes both ways if someone was motivated enough. Actually... now that I think about it, changing generateDS to use a dict to store xml attributes could easily go back and forth with all the error checking one would desire -- might have to hack that together.
- parvenu74 9y ago
  There's nothing "wrong" with XML but with JSON there's no need to add another 5 pounds (2.2 KG) of JavaScript to convert XML to JavaScript objects. For any other language it doesn't matter since you're re-mapping to objects, most likely, but with JavaScript eating the web (even on the server side) I think the question should be "why shouldn't this be JSON" as a default. In the end either way works. I would love to see Google Reader resurrected... stopped reading blogs and switched to Twitter and Hacker News once Reader died.
  - deleted 9y ago
    [deleted]
  - goalieca 9y ago
    > There's nothing "wrong" with XML but with JSON there's no need to add another 5 pounds (2.2 KG) of JavaScript to convert XML to JavaScript objects Non web-dev guy here, but browsers have excellent XML parses out there that can turn XML into a document object with a fully fledged query language. Why does it need to be a JS object?
    - jklinger410 9y ago
      I have an old wordpress blog that I would love to introduce to whatever XML reader you would suggest.
  - seangrogg 9y ago
    Alternatively, if all you're doing is supporting RSS, you could opt to just use the DOMParser API (native to most browsers) and navigate a DOMTree which is a type of JavaScript Object already...
heinrichhartman 9y ago
Yes, and while we are at it. Can we make HTML JSON based, as well? { "head" : [...], "body" : [ { "name" : "H1", "text" : "Hello JSON" }, ... ] } So much easier on the eye. ; )
- parvenu74 9y ago
  Ditching HTML for CommonMark (like MarkDown but without any daring fireballs) would be better IMO. Then again, the designers of HTML had no idea what it would become when they carved out a subset of SGML for their document markup. If we were starting over perhaps a mix of XAML for app-stuff and CommonMark for text would be a good mix... unless that totally screws up i18n. "It is what we have and it seems to work" explains HTML somewhat adequately.
- franzpeterstein 9y ago
  Please. :)
unicornporn 9y ago
Sorry, no. RSS and Atom already does the job. https://imgs.xkcd.com/comics/standards.png https://imgs.xkcd.com/comics/standards.png
- tomcatfish 9y ago
  Why didn't you link to the comic to allow Munroe to gain views/advertisement revenue/etc.?
  - Spivak 9y ago
    Because XKCD doesn't have any of that and he explicitly supports hotlinking?
ropeadopepope 9y ago
Why stop there? Let's go to cap'n proto or protobuf.
joejoebob 9y ago
I came here looking for this comment.
maxxxxx 9y ago
That's probably the least important issue that could be addressed.
gkya 9y ago
Yeah certainly, then later we can port public signeage to JSON too. {"prohibition": {"act": "pissing", "message": "Please do not urinate on the wall", "code": 1232}}.

https://jsonfeed.org/ https://jsonfeed.org/ has had some preliminary traction. Of course, the reason RSS works so well is that everyone uses the same format. So you wouldn't see so much of a "switch" as a bunch of readers accepting either format, for a very, very long time. That being said, I don't see what's "wrong" with XML in this context.

craftyguy 9y ago
Most of the complaints I've seen with the 'wrongness' of xml are centered around its human unreadability, which doesn't matter in this context. I'm curious if there's another reason.
- digi_owl 9y ago
  Bunch of webheads that thinks JS is the end all be all of languages...
- ken 9y ago
  Legibility isn't just for fun. The entire JSON spec is only about 3 pages long. (I don't know exactly how long because ECMA's webpage is down today!) I'm pretty confident that any popular JSON parser I use will abort correctly on bad JSON. There's no expansion or entities or escaping, so the parser is a pretty boring 1-to-1 translation. Give it a 1KB JSON file, and I'm going to get back a data structure that takes roughly 1KB. XML is incredibly complicated. My operating system's XML parser has had XXE-related security bugs in the recent past -- that's OWASP bug#4, and there's a Wikipedia article about it. There's other possible attacks, like the "billion laughs attack". I'm very nervous about running an XML parser on untrusted content.
  - eropple 9y ago
    Not to be flip, but if you're using a parser written by competent individuals post-2010 (really, post-2008), billion laughs is a nothing. And that follows for most XML stuff. If you are getting most bloggable with your tech stack, yes, there are certainly risks to XML (also to YAML, also to JSON--and there are definitely JSON parsers that have had some capital-I Issues out there, and a good number of the popular ones also parse not-JSON too). That said, if you're using anything remotely mainstream you can feel reasonably secure against the sorts of attacks you are likely to see because, TBH, your RSS reader is just not that valuable a target. (Or, in my case--the podcast service I'm writing.)
- chipotle_coyote 9y ago
  While I shouldn't speak for JSON Feed's developers (Manton Reece of Micro.blog and Brent Simmons, original developer of RSS/Atom reader NetNewsWire), their argument basically boils down to "developers seem to be better at constructing valid JSON than they are at constructing valid XML." I know a lot of HN folks will say but you can just construct perfectly valid XML with library such-and-such or API this-and-that and, yes, I'm sure they're all absolutely, positively 100% correct. But in my real-world experience, Reece and Simmons seem to be correct in practice. Given that Simmons wrote NNW, worked at the now-defunct server-side RSS company NewsGator, and is now writing a new RSS (and JSON Feed) reader, I'm inclined to believe that when he says JSON Feed "reflects the lessons learned from our years of work reading and publishing feeds," he means it.
  - mcormier 9y ago
    You don’t have to worry about recursive entity definitions in JSON.
  - UncleEntity 9y ago
    It's funny, the only RSS feed I use I turn into json so I can store it tinydb in "native" format. Well, technically, I turn it into a python dict and then tinydb does the conversion to json automagically. Took 50 lines of code which I banged together from google searches. Back before I started using the db backend I was parsing the feed with an auto-generated (from the schema) "rss reader" in python then merging the items into a master rss feed sorted by channels. That worked for a while until I got motivated and made it searchable/modifiable but couldn't find a simple database that I could just dump xml into. Anyhoo, my point is it's easy to work with rss in either native xml or json with some simple tools that do most of the work for you. Would be super easy to bang together a converter that goes both ways if someone was motivated enough. Actually... now that I think about it, changing generateDS to use a dict to store xml attributes could easily go back and forth with all the error checking one would desire -- might have to hack that together.
parvenu74 9y ago
There's nothing "wrong" with XML but with JSON there's no need to add another 5 pounds (2.2 KG) of JavaScript to convert XML to JavaScript objects. For any other language it doesn't matter since you're re-mapping to objects, most likely, but with JavaScript eating the web (even on the server side) I think the question should be "why shouldn't this be JSON" as a default. In the end either way works. I would love to see Google Reader resurrected... stopped reading blogs and switched to Twitter and Hacker News once Reader died.
- deleted 9y ago
  [deleted]
- goalieca 9y ago
  > There's nothing "wrong" with XML but with JSON there's no need to add another 5 pounds (2.2 KG) of JavaScript to convert XML to JavaScript objects Non web-dev guy here, but browsers have excellent XML parses out there that can turn XML into a document object with a fully fledged query language. Why does it need to be a JS object?
  - jklinger410 9y ago
    I have an old wordpress blog that I would love to introduce to whatever XML reader you would suggest.
- seangrogg 9y ago
  Alternatively, if all you're doing is supporting RSS, you could opt to just use the DOMParser API (native to most browsers) and navigate a DOMTree which is a type of JavaScript Object already...

heinrichhartman 9y ago

Yes, and while we are at it. Can we make HTML JSON based, as well? { "head" : [...], "body" : [ { "name" : "H1", "text" : "Hello JSON" }, ... ] } So much easier on the eye. ; )

parvenu74 9y ago
Ditching HTML for CommonMark (like MarkDown but without any daring fireballs) would be better IMO. Then again, the designers of HTML had no idea what it would become when they carved out a subset of SGML for their document markup. If we were starting over perhaps a mix of XAML for app-stuff and CommonMark for text would be a good mix... unless that totally screws up i18n. "It is what we have and it seems to work" explains HTML somewhat adequately.
franzpeterstein 9y ago
Please. :)

unicornporn 9y ago

Sorry, no. RSS and Atom already does the job. https://imgs.xkcd.com/comics/standards.png https://imgs.xkcd.com/comics/standards.png

tomcatfish 9y ago
Why didn't you link to the comic to allow Munroe to gain views/advertisement revenue/etc.?
- Spivak 9y ago
  Because XKCD doesn't have any of that and he explicitly supports hotlinking?

ropeadopepope 9y ago

Why stop there? Let's go to cap'n proto or protobuf.

joejoebob 9y ago

I came here looking for this comment.

maxxxxx 9y ago

That's probably the least important issue that could be addressed.

gkya 9y ago

Yeah certainly, then later we can port public signeage to JSON too. {"prohibition": {"act": "pissing", "message": "Please do not urinate on the wall", "code": 1232}}.