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

101–110 of 124 posts

Re: Transit: JSON Data Interchange Format

#101

Post by dragonwriter »

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?

> what if you need a strongly-typed data exchange format

I'm not convinced that "strongly-typed" is an attribute that can meaningfully be possessed by a data exchange format. "Strongly-typed" is about allowed actions in processing data, not about the inherently-static format of data exchange or serialization.

Re: Transit: JSON Data Interchange Format

#102

Post by Scarbutt »

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…

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

Immutable, js-csp, etc... were all inspired by Clojurescript, I guess that's the point the grandparent was trying to make.

Re: Transit: JSON Data Interchange Format

#103

Post by waxjar »

to3m wrote: post #55
waxjar wrote: post #50

Earlier quoted context omitted.

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…

Sure, but it's not very convenient.

I regularly MITM a connection between a mobile app and a HTTP server, when something isn't going quite right. A look at the JSON they exchange exposes the problem in under a minute more often than not. If I want to test something out quickly, I simply modify the incoming / outgoing JSON by hand. It's rare to get the syntax wrong and involves no context switches. I can then go back to the code, find the relevant section and make the changes I need to make. I find this a very convenient way of debugging and I don't think it would be as nice to do this with a binary format.

Re: Transit: JSON Data Interchange Format

#105

Post by vvanders »

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?

Every XML parser I've seen is garbage on the performance side of things.

Personally I'm a fan of YAML for both being fast and human readable.

Re: Transit: JSON Data Interchange Format

#106

Post by orless »

togusa wrote: post #63
oneeyedpigeon wrote: post #58

Earlier quoted context omitted.

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

That's not the problem I'm outlining. It is that semantics around type handling are implied rather than specified by schema.

I'm also not sure I'm getting you. In JSON, types can be unambiguously deferred by syntax/via gramar. You can't mistake JSONString for JSONNumber/JSONNullLiteral/JSONBooleanLiteral, the type is absolutely clear from the syntax. So I don't see how a schema would help here. What would the schema express? Surely not "this is a number" as it is clear without the schema. What then?

And what exactly do you mean by "semantics around type handling are implied", especially in `{ number: 1.0000000000000000000000000000001 }` case?

Re: Transit: JSON Data Interchange Format

#107

Post by orbitur »

zamalek wrote: post #43
nadam wrote: post #29

Earlier quoted context omitted.

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

As soon as you are making a schema for JSON you've eliminated XML with no good justification. More and more, people are re-inventing XML on top of JSON: schemas, namespace, the works. JSON is great because when you don't need all the things that XML solves it's extremely succint and readable. Use any single copied feature from XML and it turns out being more verbose and less readable than XML. Use the right tool for…

"As soon as you are making a schema for JSON you've eliminated XML with no good justification"

Sure, if you don't consider "human-readable" a good justification. Some of us do.

Re: Transit: JSON Data Interchange Format

#108

Post by brandonbloom »

lars512 wrote: post #10

I couldn't get the why of the project from the Github page alone. Rich Hickey's post introducing it a year ago is clearer: http://blog.cognitect.com/blog/2014/7/22/transit JSON has become the go-to schemaless format between languages, despite being verbose and having problems with typing. Transit aims to be a general-purpose successor to JSON here. Stronger typing allows the optional use of a more compact binary form…

Another important feature is stream-oriented caching of values. Essentially some range of opcodes in the stream language are reserved for referring to a cache of recently seen values. It's a "dynamic" encoding feature that's super beneficial for common payloads, like JSON API responses with lots of similar keys. This is something a protobuf/thrift-like should steal, as it can often be more efficient than vanilla field-number + value encoding.

Re: Transit: JSON Data Interchange Format

#109

Post by orless »

togusa wrote: post #26
progx wrote: post #24

Earlier quoted context omitted.

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:a…

Well, the `xs:decimal` example is quite interesting. In the XML Schema specification on xs:decimal (http://www.w3.org/TR/xmlschema-2/#decimal), you'll see the following note:

All minimally conforming processors must support decimal numbers with a minimum of 18 decimal digits (i.e., with a totalDigits of 18).

You have 32 decimal digits in 1.0000000000000000000000000000001, so "minimally conforming processors" are, according to spec, actually free to drop everying after 17th place after comma in this case.

You say "constraints of the type are undefined". I don't see how "double-precision 64-bit format IEEE 754 value" from ECMAScript spec is lesser defined than "decimal numbers with a minimum of 18 decimal digits".

Re: Transit: JSON Data Interchange Format

#110

Post by orless »

icebraining wrote: post #39
neoeldex wrote: post #34

Earlier quoted context omitted.

Try creating that number is several languages. #/usr/bin/python n = 1.0000000000000000000000000000001 print n # 1.0 //Javascript n = 1.0000000000000000000000000000001; console.log(n); // 1

from decimal import Decimal n = Decimal("1.0000000000000000000000000000001") just because float is the default, doesn't mean you have to use it. JSON doesn't have anything else, though.

JSON does not have float (nor double) either. JSON has JSONNumber.
Post reply on HN