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

121–130 of 153 posts

Re: Better Than JSON?

#121

Post by cbsmith »

fanf2 wrote: post #110
cbsmith wrote: post #101

Earlier quoted context omitted.

"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.

You think an instruction with Javascript in the name, that converts JavaScript floating-point to signed fixed-point, rounding towards zero, isn't used when parsing JSON?

Re: Better Than JSON?

#122

Post by nly »

Avro never gets any love, which is a real shame given its extremely powerful schema resolution rules[0]

You don't have to worry about maintaining numeric field tags, can remove fields, can make previously required fields optional (by promoting them to unions with null), or even change their type (by promoting them to unions of and )

You need to pass your schema around with your data somehow, but there's a file format specified for that, and you can still just dump to JSON if you can't be bothered.

The schemas are specified in JSON too... which in my view makes it more robust than the JSON + JSON-Schema combo

[0] https://avro.apache.org/docs/current/spec.html#Schema+Resolu...

Re: Better Than JSON?

#124

Post by bjconlan »

jandrese wrote: post #56
peatmoss wrote: post #20

Earlier quoted context omitted.

Yeah, the author didn’t specify why he thought EDN wasn’t more than “a good start.” I’m curious what it’s missing!

What's missing is major projects using it I think. Note how for every example he lists the big players keeping it alive.

From recollection it’s the native data transmission format for Datomic (which is driven by Cognitect/Nubank). I think there is a little bit more to the bias’ of EDN (mostly driven by language preferences in this case).

Re: Better Than JSON?

#125

Post by t-writescode »

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

Earlier quoted context omitted.

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.

I remain confused. Many libraries support generic data contracts that enable both xml and json objects from the same objects.

Re: Better Than JSON?

#126

Post by l0b0 »

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

Basically, use the best tool for the job. If you're working with complex data structures from many sources, having data, validation and transformation languages (XML, XSD and XSLT) which have been co-developed and refined to basically be able to validate any third-party tool is invaluable. Sometimes extra safety is worth both the extra space and time.

Re: Better Than JSON?

#127

Post by xellisx »

fanf2 wrote: post #118
rwmj wrote: post #108

Earlier quoted context omitted.

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.

I-JSON specifies how to represent dates and binary data in strings. https://tools.ietf.org/html/rfc7493 JSON Schema http://json-schema.org/ is widely used for things like Swagger / OpenAPI.

I like JSON Schema and I wish Typescript did something more like it with it type definitions.

Re: Better Than JSON?

#128

Post by andreareina »

jrochkind1 wrote: post #40

There are a bunch more possible entries in the human-readable category, one of the more popular contenders is TOML. https://github.com/toml-lang/toml . There are more. I don't know if java dot-properties file is worth including.

The speaks to the context of serialization formats, which TOML isn't.

Re: Better Than JSON?

#129

Post by Seb-C »

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

JSON schema achieves the same result and is fairly standard actually.

Re: Better Than JSON?

#130

Post by setr »

lemmsjid wrote: post #48
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,…

Much agreement here, and from the exact same usecase. Probably the easiest B2B API integration scenario I worked with in the past was XML + XML Schema validation. And I still think XML is more readable in many cases than JSON, because while verbose the hierarchical structure is very easy to grasp, sometimes I misread an entire JSON document at first because I missed a quick "[" or "[{" (yes I have also misread XML do…

The problem I think is the extreme cargo-culting that exists with any popular technology -- half the arguments against the current flavor of the month really just begin with "no, this is not sent from god, and there do exist tradeoffs". Which is a fairly unreasonable starting point for a conversation between educated parties.

And then the ratchet turns, and the pendelum swings in reverse, and suddenly that thing sent from god was instead discovered to be sent from satan... and you're still trying to explain that tradeoffs exist

Post reply on HN