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

Better Than JSON?

wiki.alopex.li

Post reply on HN
Print view View original

101–110 of 153 posts

Re: Better Than JSON?

#101

Post by cbsmith »

lxe wrote: post #95
secondcoming wrote: post #84

Earlier quoted context omitted.

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.

This is true. There usually are a few cases an org would have where latency costs, de-serialization and deserialization costs outweigh the simplicity of http/json, and it usually happens in a business critical part of the company. This leads to a standardization policy where ALL projects now use grpc/thrift/etc... as an RPC standard, even if when it doesn't make sense.

"simplicity of http/json" always elicits snickering from me.

HTTP, by itself, is one of the more complex layer-7 protocols known to man. UTF-8 is not simple. Converting a decimal string representation of a floating point value into IEEE 754 is not simple (particularly compared to... memcpy). In a bizarre example of the tail wagging the dog, the ARM ISA has added an instruction specifically for parsing JSON...

There's really not a lot of value in having different serialization formats, so the "even if it doesn't make sense" requires a specific context for determining what makes sense.

Re: Better Than JSON?

#102

Post by generalk »

secondcoming wrote: post #78
generalk wrote: post #28

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.

No, with Protobuf, I send my counterparts a .proto file, and they 1) Don't know what the hell to do with it, not just because they don't know Protobuf but because 2) it wasn't included in the docs/dictionaries from the standards organization that set this all up in the first place.

Re: Better Than JSON?

#104

Post by secondcoming »

t-writescode wrote: post #88
secondcoming wrote: post #84

Earlier quoted context omitted.

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.

I was more referring to the overkill nature of needing a HTTP server rather than the ease of integration of JSON parsing code.

Re: Better Than JSON?

#105

Post by secondcoming »

cbsmith wrote: post #96
secondcoming wrote: post #84

Earlier quoted context omitted.

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.

With compression, payload size differences aren't that significant, and don't necessarily favour other formats (e.g. almost none of the formats have particularly compact representations of strings, and single decimal digit integer values are common enough that integer fields are not that wasteful in JSON). I totally hear you on serialization/deserialization speed, though it is amazing how inefficient some of the "mac…

Are you including the size of the typically useless HTTP headers when you talk about 'payload size', or just the actual payload in the HTTP request itself?

I really mean 'typically useless' in the scenario where the communication is being done internally, not when you're actually communicating over the public internet. There can be quite a bit of wastage in this scenario. I really don't care about the 'Date' header or the 'Server' header, but the HTTP spec does, so they're there.

Re: Better Than JSON?

#106

Post by cbsmith »

avmich wrote: 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…

Again, I think this is based on some starting assumptions about what is an ideal state, and a lot of people would argue they are flawed assumptions. It's easy to get trapped into a context when considering what the ideal solution would look like.

People forget this, but ASCII (and therefore UTF-8) already has characters in it for field/record/etc. separation. One increases complexity significantly (and introduces inefficiency) by overloading other characters with their semantics.

There are much more simple & efficient ways to demarcate ordered arrays in particular (e.g. simple length prefixed structures).

Nulls are highly problematic for any number of reasons that are widely documented, and JSON unfortunately compounds this by having two ways of representing them (explicitly and by omission).

One might quibble with the notion that a format that didn't even exist in 2000 doesn't really have two decades worth of applications working on it, but setting that aside, the design constraints of JavaScript and the challenges that have emerged from it are far from ideal. The work arounds that have emerged (the whole Number fiasco, the "standardizing" on UTF-8 while using UTF-16 when escaping, line terminators, the backslash escapign of control characters, the inconsistencies between JSON & JSONP, the binary64 "good interoperability" rule, and comments being disallowed, and of course the various JSON Schema efforts).

While I agree that an ideal serialization standard would not have versioning, and Crockford's decision to avoid JSON versioning might consequently seem to make good sense... in practice this has lead to significant inconsistencies between implementations, many of which lead to interoperability problems that could at least be somewhat mitigated by versioning. (http://seriot.ch/parsing_json.php)

"Fixing" a bad abstraction by layering on a bad abstraction is a common house of cards meme. It is highly problematic to say the least. It's how "simple" JSON rapidly evolves to be at least as complex (and at least as error prone) as ASN.1.

Re: Better Than JSON?

#107

Post by rwmj »

generalk wrote: post #28

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

It's a shame the original article didn't mention XPath which is a great feature when you're in the XML ecosystem. (Obviously JSON has jq, but that's not a standard - so there's no library version - and has some weirdness compared to XPath).

Re: Better Than JSON?

#108

Post by rwmj »

lxe wrote: 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.

Provided you never need to use integers > 53 bits, dates, binary data, comments or validate what you're sending or receiving it's totally fine.

Re: Better Than JSON?

#109

Post by GoblinSlayer »

tannhaeuser wrote: post #11

> Not sure anyone really knows how XML happened. It’s basically the W3C’s fault, I think? Doesn't instill confidence in that content. fyi: XML was subset by W3C (the SGML "extended review board" specifically) from SGML to become the generic syntax for web vocabularies (replace HTML syntax by XTHML, and define new SVG, MathML vocabularies). Didn't work out on the web, though.

SVG did. XHTML is incompatible with traditionally lazy nature of webdev: broken markup happens regularly, XML would make it non-displayable, so HTML keeps accessibility of broken pages.

Re: Better Than JSON?

#110

Post by fanf2 »

cbsmith wrote: post #101
lxe wrote: post #95

Earlier quoted context omitted.

This is true. There usually are a few cases an org would have where latency costs, de-serialization and deserialization costs outweigh the simplicity of http/json, and it usually happens in a business critical part of the company. This leads to a standardization policy where ALL projects now use grpc/thrift/etc... as an RPC standard, even if when it doesn't make sense.

"simplicity of http/json" always elicits snickering from me. HTTP, by itself, is one of the more complex layer-7 protocols known to man. UTF-8 is not simple. Converting a decimal string representation of a floating point value into IEEE 754 is not simple (particularly compared to... memcpy). In a bizarre example of the tail wagging the dog, the ARM ISA has added an instruction specifically for parsing JSON... There's…

I guess the ARM instruction you are thinking of is FJCVTZS, which implements the special ToInt32 operation required by JavaScript. https://stackoverflow.com/questions/50966676/why-do-arm-chip...

It is nothing to do with JSON.

Post reply on HN