Live data from Hacker News

Better Than JSON?

wiki.alopex.li

71–80 of 153 posts

Re: Better Than JSON?

#72
post #6

Everyone loves to hate on XML just because it can be verbose and some of the WS* protocols are complicated. But as a human-readable format it’s no harder to read or parse than JSON and legacy application support is orders of magnitude better than JSON. I’m not saying we should all use it but we shouldn’t be hating it either.

The issue with XML is that it was mostly pushed upon developers without any deeper understanding. So there's a ton of utterly crap XML applications out there with no rhyme or reason, and these crap XML enterprise apps are most developer's understanding of "real world XML". Similar to how terrible C++ code being all over the place is making people hate C++ the language. ------- XML can be used very well however: its u…

> without any deeper understanding

I can't count how often I've seen XML that looked like this:

    
       
       
       
       
       ...
     
Which was, technically, XML (it even conformed to a schema!)... almost like "malicious compliance".

Re: Better Than JSON?

#73

On XML: > Not sure anyone really knows how XML happened. It’s > basically the W3C’s fault, I think? It’s okay for some > things but in the end I’m not sure it’s something anyone > actually wants to use, it’s just going to be one more of > those mistakes of the past. Look, I was doing web dev when XMLRPC was in. For simple API stuff, JSON ended up being worlds better. No fiddly XML preamble, no schemas, no envelopes,…

XML can be a bear, but sometimes you need a bear. Phrase heard at conferences in the 90's/2000's: "XML is like violence. If it doesn't work, you're not using enough of it."

Made me laugh. :-)

Re: Better Than JSON?

#75
post #6

Everyone loves to hate on XML just because it can be verbose and some of the WS* protocols are complicated. But as a human-readable format it’s no harder to read or parse than JSON and legacy application support is orders of magnitude better than JSON. I’m not saying we should all use it but we shouldn’t be hating it either.

Yes, XML is verbose. It's also highly redundant (so it basically can't be hand written), undesrpecified (do I put this value as an atribute, value, or sub-element?), underpowered (how does it represent numbers? Byte streams?), complicated (have you ever created a DTD by hand?), and just out badly designed. Of course, JSON and YAML share some of those same problems, and add some different ones. But the complaints abou…

The under-specified thing I think is funny because it’s the source of pretty much all the bad XML you see in the wild. For being an entirely tree oriented format it’s tragic flaw is that XML can’t actually represent nested dicts (or arrays for that matter) which turned out to be the data structures people actually wanted to work with.

Oh there are lots of ways to beat XML into looking like it can do it but they’re all bad, break all the actual semantics of XML and turn a nice deserialization story of a tree where each node is a complete thing into mess.

Turns out that very few people actually needed a tree of heterogeneous string k-v pairs.

Re: Better Than JSON?

#76
post #55

In some sense JSON is unimprovable, because some properties of JSON are reached their limits. The idea of JSON is to offer two important ways to aggregate, which are different enough that they deserve separate treatment - ordered array and associative array. They are economically represented, with [] and {}, and internal structure is also made with small costs - commas (,) between elements and colons (:) for keys in…

[deleted]

Re: Better Than JSON?

#77
post #6

Everyone loves to hate on XML just because it can be verbose and some of the WS* protocols are complicated. But as a human-readable format it’s no harder to read or parse than JSON and legacy application support is orders of magnitude better than JSON. I’m not saying we should all use it but we shouldn’t be hating it either.

The attribute versus child conundrum in XML specification is largely absent in JSON. Ordered versus unordered children is still a puzzle to sort out but more of a special case.

In XML, there was always some motherfucker trying to stuff CSV into an attribute.

And the difference between ID as specified and ID as implemented lead to a lot of problems, reaching its zenith (or maybe nadir?) in the XML Signature spec.

Re: Better Than JSON?

#78

On XML: > Not sure anyone really knows how XML happened. It’s > basically the W3C’s fault, I think? It’s okay for some > things but in the end I’m not sure it’s something anyone > actually wants to use, it’s just going to be one more of > those mistakes of the past. Look, I was doing web dev when XMLRPC was in. For simple API stuff, JSON ended up being worlds better. No fiddly XML preamble, no schemas, no envelopes,…

> So when our integrations broke because they were sending XML payloads that failed schema validation, our conversations were so easy.

Fine, but with for example, Protobuf, you share a .proto file and so there's zero percentage chance of this happening.

Re: Better Than JSON?

#79
JSON5 looks pretty great to me, I'm surprised it doesn't get more attention in the write-up. Take JSON and add trailing commas, multi-line strings, and comments. Done and done!

Re: Better Than JSON?

#80

Also worth looking are EDN [0] (mentioned briefly under S-Expressions), Transit [1] and Fressian [2][3]. [0] https://github.com/edn-format/edn [1] https://github.com/cognitect/transit-format [2] https://github.com/Datomic/fressian/wiki [3] https://www.youtube.com/watch?v=JArZqMqsaB0&ab_channel=Cloju...

I would love edn if it was viable as a standalone format. In practice, programming in clojure it's plain JSON vs transit vs fressian. I tend to go with just JSON.
Post reply on HN