91–100 of 153 posts
I find it curious that serialization formats like JSON get hit on for not having a native date/time format. Just use a UNIX timestamp and be done with it.
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.
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."
That same saying would also work replacing XML for soap (but not SOAP).
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.
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.
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.
I totally hear you on serialization/deserialization speed, though it is amazing how inefficient some of the "machine readible" implementations can be, and how efficient people have been able to get JSON parsing, its horrible design disadvantage in this area is lethal.
The simplicity argument is an amusing one to me. I think a lot of people build simple client/server code for JSON, but these "simple" implementations have all kinds of rough edges that prove problematic long term. Once you start doing things right, JSON proves to be far more complex.
Earlier quoted context omitted.
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 a…
Items can be order-dependent in XML. So the "id=1" thing is still superfluous. See xs:sequence. (In contrast: xs:all declares something to be order independent).
If you were doing XML for your own apps, I think xs:sequence items simplify parsing grossly.
Ex: if you have Address, maybe you always want "Street", then "Zip Code", then "State".
1234 Blah Street
Springfield
Whatever
55555
--------
If there are multiple People at this address, you could (and probably should) just list them out in order.
1234 Blah Street
Springfield
Whatever
55555
Marge
Homer
Lisa
Bart
Maggie
I would have expected some mention to https://jsonnet.org/ too, which after a bit of practice can be brilliant.
Earlier quoted context omitted.
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 a…
Earlier quoted context omitted.
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.
How would you represent CSV in JSON?