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

Transit: JSON Data Interchange Format

github.com

Post reply on HN
Print view View original

21–30 of 124 posts

Re: Transit: JSON Data Interchange Format

#21

Post by rjbwork »

andyjohnson0 wrote: post #19
creshal wrote: post #11

Reinventing XML, one data type at a time.

My thoughts exactly. JSON is great for Javascript clients, but if you're dealing with clients written in multiple languages then there is already a good language-neutral serialisation format: XML. Just because it's not fashionable (with some) doesn't mean it doesn't work. Edit: So why the downvotes? How about a conversation instead?

I used to agree, but I've lately come over to the JSON side, I think. It's easier to read by a human, and it doesn't have this weird "should it be a node or an attribute" thing. Single things are properties, many things are arrays.

And now with Schemas and editor support for them, I think it is an acceptable replacement personally.

Re: Transit: JSON Data Interchange Format

#22

Post by Mikera »

khgvljhkb wrote: post #6

Am I the only one amazed by what the Clojure community and core team are conjuring up? Doing client-side programming with things like CLJS, Figwheel, Reagent and core.async feels miles ahead of what we have in moden-js-land (es6/7, babel, webpack, React, promises). If you were to start a startup today, would you be comfortable going with something like Clojure/script?

Absolutely happy with my choice of Clojure as a startup (doing data science, analytics, some front-end work).

Biggest wins for us are:

- ClojureScript / figwheel as an awesome front end development combination.

- The combination of functional programming with immutable data structures

- Lisp "magical powers" (macros, interactive REPL etc.)

- Ability to exploit the Java library ecosystem whenever you need it

Biggest downside = Lack of types.

Re: Transit: JSON Data Interchange Format

#24

Post by progx »

togusa wrote: post #20
aerique wrote: post #18

Earlier quoted context omitted.

Hopefully something better than XML comes of it before the enterprise gets its grubby hands on it!

Enterprise here. We like XML because it's explicit. { number: 1.0000000000000000000000000000001 } Try parsing the above JSON consistently in several languages without a consistent schema definition.

Feel free to write a schema definition for json data (or use the existing). Why should this not be possible?

Re: Transit: JSON Data Interchange Format

#26

Post by togusa »

progx wrote: post #24
togusa wrote: post #20

Earlier quoted context omitted.

Enterprise here. We like XML because it's explicit. { number: 1.0000000000000000000000000000001 } Try parsing the above JSON consistently in several languages without a consistent schema definition.

Feel free to write a schema definition for json data (or use the existing). Why should this not be possible?

Well in this case, JSON schema doesn't specify any more fundamental types other than "number". On the receiving end of a wire or network contract, how do we pick a storage type for "number"? We can't because the constraints of the type are undefined. Ergo JSON schema isn't a strong schema language. Be explicit is really important when defining contracts.

Type this in your address bar for an illustration:

    javascript:alert(1.0000000000000000000000000000001);
So where can we go here. Yep:

   { number: "1.0000000000000000000000000000001" }
which means we then break the encapsulation boundary of the metadata. Then we have a wire contract that says "this is a string" and a separate semantic contract that says "this is a decimal".

XML:

   1.0000000000000000000000000000001
Schema:
This is just one example. We can also serialize and deserialize complex self-relational composite types transparently at both ends of the channel.

This is a real world problem we encounter in the financial sector every day.

Re: Transit: JSON Data Interchange Format

#27

Post by jzwinck »

mukundmr wrote: post #16

Why choose this over Google's Protocol buffers? https://github.com/google/protobuf

One issue with Protobufs is they do not always enable optimal performance (latency, power). Better than JSON but worse than some others. Compared to MessagePack, Protobufs require a schema, which is not always convenient. Compared to Cap'n Proto, Protobufs are less CPU efficient. Trade offs all around.

Re: Transit: JSON Data Interchange Format

#28

Post by icebraining »

mateuszf wrote: post #25
mukundmr wrote: post #16

Why choose this over Google's Protocol buffers? https://github.com/google/protobuf

One reason is compatibility - it can be encoded to json and thus is handled by http proxies, etc. It is also human readable in encoded form.

Protobuf is just a serialization format; you can send it over HTTP.

Re: Transit: JSON Data Interchange Format

#29

Post by nadam »

togusa wrote: post #20
aerique wrote: post #18

Earlier quoted context omitted.

Hopefully something better than XML comes of it before the enterprise gets its grubby hands on it!

Enterprise here. We like XML because it's explicit. { number: 1.0000000000000000000000000000001 } Try parsing the above JSON consistently in several languages without a consistent schema definition.

Then use this instead:

{ number: "1.0000000000000000000000000000001" }

How is it worse than XML?

Re: Transit: JSON Data Interchange Format

#30

Post by togusa »

nadam wrote: post #29
togusa wrote: post #20

Earlier quoted context omitted.

Enterprise here. We like XML because it's explicit. { number: 1.0000000000000000000000000000001 } Try parsing the above JSON consistently in several languages without a consistent schema definition.

Then use this instead: { number: "1.0000000000000000000000000000001" } How is it worse than XML?

See: https://news.ycombinator.com/item?id=10385610
Post reply on HN