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

51–60 of 124 posts

Re: Transit: JSON Data Interchange Format

#51

Post by retrogradeorbit »

grayrest wrote: post #49
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?

The Clojurescript community are ahead but not by that much. To list specifics, cljs->babel+and immutable lib, figwheel->react-hot-loader, reagent->react 0.14 pure components, core.async->js-csp (or async/await). In terms of non-component organization, I believe re-frame is a significant improvement over redux. Reactions are good when you don't control the endpoints, splitting out the reducers into pure functions is g…

> If you're using core.async, the main loop has a try/catch/rethrow. This causes Chrome Dev Tools to break in the outer loop instead of actually at the problem.

OMG! Is that what is causing that behaviour?! It's frustrating (though not a show stopper) and I was unsure of the cause. Thanks for pointing that out. I will have a deeper look.

Re: Transit: JSON Data Interchange Format

#52

Post by pjc50 »

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?

http://programmers.stackexchange.com/questions/61198/if-xml-...

http://blog.codinghorror.com/xml-the-angle-bracket-tax/

http://nothing-more.blogspot.co.uk/2004/10/where-xml-goes-as...

SOAP's serialisation of RPC predated the popularity of JSON, and has largely been replaced by JSON for web-RPC through REST APIs. Why? Because it's needlessly verbose and complicated.

(I do worry that new serialisation formats are being developed in a vacuum, and we'll reinvent ASN1 or something)

Re: Transit: JSON Data Interchange Format

#53

Post by djKianoosh »

waxjar wrote: post #50
easytiger wrote: post #4

Earlier quoted context omitted.

It's the whole FAST/FIX clusterfuck all over again. Use a binary format and stop cocking around. You can't serialise/deserialise it faster and JSON is a string based mess. No low latency path can absorb it. Even influxdb have removed JSON support because it was their slowest part of their critical path that could not be optimised. Complete lack of mechanical sympathy + laziness is why JSON is popular outside of the w…

I don't think I would enjoy debugging a service that talks in a binary format.

debugging the data, no. debugging the code, depending on how the representation looks like, probably wouldn't be too bad...

Re: Transit: JSON Data Interchange Format

#54

Post by oskarth »

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?

The downvotes are because it comes across as a shallow, middlebrow dismissal.

An interesting and useful criticism would first engage with the strongest arguments of Rich Hickey (creator of Transit and edn). If you find something in his Language of the System talk (https://www.youtube.com/watch?v=ROor6_NGIWU) that you either (a) disagree with (b) think XML solves already, I and many others would certainly be interested in having that conversation.

Note that this doesn't mean the exposition of "Why Transit" can't be better, but that calls for constructive criticism on how explain the ideas better, or a question made in qood faith. What it doesn't call for is a hostile reply saying in effect "pff, already been done already, stop reinventing the wheel".

Re: Transit: JSON Data Interchange Format

#55

Post by to3m »

waxjar wrote: post #50
easytiger wrote: post #4

Earlier quoted context omitted.

It's the whole FAST/FIX clusterfuck all over again. Use a binary format and stop cocking around. You can't serialise/deserialise it faster and JSON is a string based mess. No low latency path can absorb it. Even influxdb have removed JSON support because it was their slowest part of their critical path that could not be optimised. Complete lack of mechanical sympathy + laziness is why JSON is popular outside of the w…

I don't think I would enjoy debugging a service that talks in a binary format.

I've never done it with JS. It's not really a problem in C, though. If there's a lot of data, you're no better off with text; if there's not much, reading binary data isn't too bad. You've usually got other problems on top of decoding the actual data - like, why is this data coming in the first place? Why isn't the code accepting it properly? Why isn't the other end listening? The data encoding is just the tip of the iceberg.

Either way, the advantages of binary often outweigh the difficulty of having a human read the data. As the saying goes, code is executed far more often than it's read.

(Most binary formats have some fairly obvious possible text representations, at least for key fields (they're just encoding ints, floats, strings, bitfields, etc.). When you're having difficulty, or you're simply curious, you can print them out. If the format is any good, malformed messages are easy to check for in code - this code is not harder to debug than any other. If anything it's actually easier than with some kind of text format.)

Re: Transit: JSON Data Interchange Format

#56

Post by wtbob »

creshal wrote: post #32
andyjohnson0 wrote: post #19

Earlier quoted context omitted.

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?

JSON is pretty great to parse in a variety of (web-relevant) languages. And it's a good data exchange format if you're okay with its loose typing. But if I need a strongly-typed, extensible markup language, I'd think really hard about inventing my own…

Sure, XML may be decent as an extensible markup language, but what if you need a strongly-typed data exchange format?

Re: Transit: JSON Data Interchange Format

#58

Post by oneeyedpigeon »

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.

True, any problem domain that requires accuracy to 31 decimal places might not be best suited to JSON. I wonder how many decimal places would be required to represent the percentage of projects that would actually be affected by that...

Re: Transit: JSON Data Interchange Format

#59

Post by icebraining »

wtbob wrote: post #56
creshal wrote: post #32

Earlier quoted context omitted.

JSON is pretty great to parse in a variety of (web-relevant) languages. And it's a good data exchange format if you're okay with its loose typing. But if I need a strongly-typed, extensible markup language, I'd think really hard about inventing my own…

Sure, XML may be decent as an extensible markup language, but what if you need a strongly-typed data exchange format?

Turtle!

Well, I can dream..

Re: Transit: JSON Data Interchange Format

#60

Post by HolyHaddock »

andyjohnson0 wrote: post #31
rjbwork wrote: post #21

Earlier quoted context omitted.

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.

Nodes for data, attributes for metadata. I think you made a good argument, although I personally prefer the more mature XML tooling and metadata support for versioning.

That's fine in theory, but it's not a universal heuristic, and even then, different smart well-intentioned people independently applying it won't necessarily come to the same result.
Post reply on HN