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

JSON Feed

jsonfeed.org

Post reply on HN
Print view View original

161–170 of 225 posts

Re: JSON Feed

#161

Post by moolcool »

pfranz wrote: post #144
mindcrime wrote: post #78

Earlier quoted context omitted.

But even in established languages I've had trouble finding an appropriate xml parser and had to tweak them way more than I thought necessary. I haven't (yet) had that problem with JSON. Maybe it's just that I work mostly with JVM languages (Java, Groovy, etc.) but I haven't had any problems with handling XML - including Atom - in years. But I admit that other platforms might not have the same degree of support.

Most of my experience is from Python. Each time I use it I have to look at the docs for etree (a library that ships with Python). We would hit performance and feature support issues with etree and tried lxml but had binary compatibility issues between our environments. The Hitchhiker's Guide to Python[1] (a popular reference for Python) recommends untangle[2] and xmltodict[3], neither of which I've used. I feel like…

Beautiful Soup is alright in most cases. JSON is handled much better than any XML library I've seen so far though.

Re: JSON Feed

#162

Post by moolcool »

sacheendra wrote: post #126
mstade wrote: post #66

Earlier quoted context omitted.

Right, but you inevitably end up with boilerplate "massage" code around your data anyway. Case in point: dates, any number that isn't just a number e.g. currencies or big numbers, URLs, file paths, hex, hashes. Basically any type that carries any kind of semantics beyond array, object, string, number, or null will require this boilerplate, only that your data format has no way of describing them except for out-of-ban…

IMHO the boilerplate code is much easier to read than understanding the nuances of XML if I have to read a document. {"type":"currency", "unit":"euro", "amount": 10} feels easier to understand than 10

The biggest problem with XML is how easy it is to make a very bad schema, and how hard those can be to parse

Re: JSON Feed

#163

Post by jameshart »

d0mine wrote: post #151
jameshart wrote: post #128

Earlier quoted context omitted.

Actually actually... the JSON spec doesn't define the concept of a JSON document. Neither http://www.json.org/ nor http://www.ecma-international.org/publications/files/ECMA-ST... actually specifies that a JSON 'document' is synonymous with a JSON 'value'. Now it's also true that JSON doesn't specify an entity that can be either an object or an array but not be a string or a bool or a number or null. So it's kind of t…

Why are you referencing the obsolete rfc? There is no restriction to object/array for the JSON text in the current rfc https://tools.ietf.org/html/rfc7159

Because I just discovered that there was, at least once, a specification that actually defined JSON that way, where previously I had thought it had only been ambiguously described, and I thought that was interesting.

Re: JSON Feed

#164

Post by smilbandit »

Communitivity wrote: post #148

It is worth pointing out that there is a relevant W3C Recommendation "JSON Activity Streams", https://www.w3.org/TR/activitystreams-core/ . I'm not saying JSON Feed is worse, or better. I am saying that I think JSON Feeds adoption requires a detailed comparison between JSONFeed and JSON Activity Streams 2.0.

Thanks +1, didn't know that.

Re: JSON Feed

#166

Post by __david__ »

ozten wrote: post #48

XML is aweful, but it does have CDATA, which lets you embed blog posts directly and it's easy to debug. String encoded blog posts are going to be painful once people start using the `content_html` part of the spec.

Naw, JSON has reasonable quoting in the strings. It's maybe painful to read the raw json, but it encodes just fine.

Re: JSON Feed

#167

Post by robgibbons »

mindcrime wrote: post #2

Do we really need this? Atom is fine for feeds. Avoiding XML just for the sake of avoiding XML, because it isn't "cool" anymore is just dump groupthink. If this industry has a problem, it's FDD - Fad Driven Development and IIICIS (If It Isn't Cool, It Sucks) thinking.

JSON, given the same schema, will always be more efficient byte-for-byte than XML. In addition, JSON as a format is native to JavaScript, which itself is ubiquitous. That's not even mentioning raw readability/writability.

Basically, XML is to JSON as SOAP is to REST. It had it's day, though it's obviously still useful, but we have better tools now. Frankly, I'm surprised we haven't seen a proposal like this sooner.

Re: JSON Feed

#168

Post by hajile »

zeveb wrote: post #76

If we're going to talk about replacing XML with better data formats, why not switch to S-expressions? (feed (version https://jsonfeed.org/version/1) (title "My Example Feed") (home-page-url https://example.org) (feed-url https://example.org/feed.json) (items (item (id 2) (content-text "This is a second item.") (url https://example.org/second-item)) (item (id 1) (content-html " Hello, world! ") (url https://example.or…

Those two aren't comparable because you cannot distinguish between key:val pairs and lists. You need dotted lists.

Re: JSON Feed

#169

Post by liuyanghejerry »

mindcrime wrote: post #2

Do we really need this? Atom is fine for feeds. Avoiding XML just for the sake of avoiding XML, because it isn't "cool" anymore is just dump groupthink. If this industry has a problem, it's FDD - Fad Driven Development and IIICIS (If It Isn't Cool, It Sucks) thinking.

Part of me is also with you - JSON is indeed smaller than XML , but we do have gzip almost everywhere around the web, and with gzip, they don't have that much difference on space. Also, if people really care about this, why don't they use binary format, such as something like protobuf?

And the other part of me is not with you - manipulating XML is not as easy as JSON in most of my development time, and sometimes I even need to write something by my bare hands, which JSON is much more handy. Tons of other formats are more human-friendly than JSON, for example TOML, but they don't have the status JSON has. So I guess JSON is kinda choice under the current state of "web development times".

Re: JSON Feed

#170

Post by Aeolun »

bastawhiz wrote: post #158
josteink wrote: post #83

Earlier quoted context omitted.

> XML also has a lot of room for syntax errors, No it doesn't. XML is either well formed or not, and any parser encountering non well-formed XML will reject it outright. Therefor all XML in use on the internet is spec-compliant. Now try to say the same about JSON.

> any parser encountering non well-formed XML will reject it outright. Ah, I see you're new to parsing XML.

Oh, it will be rejected alright. And then you're forced to override the parser, or to manipulate the XML before parsing it because it makes business sense to not have the source fix their XML for some reason.

People and machines are just utterly incapable of outputting valid XML.

Post reply on HN