Live data from Hacker News

Better Than JSON?

wiki.alopex.li

81–90 of 153 posts

Re: Better Than JSON?

#81

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,…

I hate xml so much. But I had a exam at my university a year ago where they would let me type a validation schema for a xml file in notepad++ and a checker on a computer with no internet. The fail rate for that exam was high and the course was outdated, api am glad they updated the curriculum now. I just hope to never work with xml data again.

Re: Better Than JSON?

#82
post #38

Arrow is rapidly become a data interchange format for Pandas and GPU compute, didn't see that on there

Good point, though I think Arrow is optimized for larger amounts of data. Not sure how it would hold up for small messages. Still, lots of people use JSON, etc. to store large amounts of data, so Arrow (or maybe more accurately, Parquet) is a fair comparison here.

Re: Better Than JSON?

#84
post #27

After half a decade of "better than JSON" mentality, fiddling with thrift, protobufs, custom serialization methods, I came to realize JSON/HTTP is usually the right tool for 90% of jobs.

Maybe, if you're not paying for data transmission costs.

Binary formats win for the following cases:

- payload size

- serialisation/deserialisation speed

- simplicity of client / server code (e.g. replacing a full blown HTTP server with a simple ZeroMQ one)

Sure, having payloads that are human readable is great for initial debugging/verification, but once things are put live it's just an unnecessary expense.

Re: Better Than JSON?

#85
This post seems to be conflating various things such as configuration files, client side message configuration, and wire format.

I am not sure what the takeaway is from it aside from the author's personal opinions on various technologies

Re: Better Than JSON?

#86

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!

Is that what VSCode does for the settings.json and similar settings files?

I haven't tried multiline strings but it allows comments and trailing commas

Re: Better Than JSON?

#88
post #27

After half a decade of "better than JSON" mentality, fiddling with thrift, protobufs, custom serialization methods, I came to realize JSON/HTTP is usually the right tool for 90% of jobs.

Maybe, if you're not paying for data transmission costs. Binary formats win for the following cases: - payload size - serialisation/deserialisation speed - simplicity of client / server code (e.g. replacing a full blown HTTP server with a simple ZeroMQ one) Sure, having payloads that are human readable is great for initial debugging/verification, but once things are put live it's just an unnecessary expense.

Definitely not for simplicity of server/client code. Using a Json serialization library basically means implementing a POJO at this point.

Re: Better Than JSON?

#89
post #34
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.

Hmm no, XML is 10x harder to read than JSON, period. It's just a ugly format with so much metadata information which are not human friendly. I think that's the main problem of XML it's not meant to be read by humans but people thought it was.

There's a huge difference between an XML document type designed by committee and something utilitarian used by an app developer. For example:

  
    
    
    
    
    
  
It's not something that an IBM committee would have come up with but it fits the needs of an application. If XML has an "intrinsic fault" it's related to DTDs and namespaces which allow for the creation of horrible, complex monstrosities. XML can be every bit as stripped down and to-the-point as JSON, trading the curley braces for angle brackets. JSON's best point is that it doesn't support any of this needless complexity but it's still easy enough, with enough nested objects and arrays, to make something that's effectively not readable by a human.

Re: Better Than JSON?

#90
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…

https://www.w3.org/TR/xmlschema-2/#built-in-primitive-dataty...

For comparison, time formats in JSON are all over the place.

Post reply on HN