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

81–90 of 124 posts

Re: Transit: JSON Data Interchange Format

#81

Post by jimktrains2 »

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…

> maps (with arbitrary scalar keys, not just strings)

Floating point keys just seem like a terrible idea.

Re: Transit: JSON Data Interchange Format

#82

Post by prodigal_erik »

dec0dedab0de wrote: post #69
wtbob wrote: post #56

Earlier quoted context omitted.

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

I'm going to risk sounding thick here, but why would you need a strongly-typed data exchange format? I always thought the beauty of JSON was that it forced the sender to organize the data in a generic way, which allowed the receiver to interpret it however needed.

Without a strongly-typed data exchange format, you constantly have to write code that makes assumptions you hope the sender followed. Timestamps are ISO formatted. No, timestamps are seconds since 1970. No, they're floats including milliseconds. Blobs are base64. No, hex. Money is a string. No, it's a float. No, it's an int in micros. An empty array is different than an omitted field. No, they're the same. No, multiple values are comma-delimited strings.

Re: Transit: JSON Data Interchange Format

#83

Post by Skinney »

nly wrote: post #76
Skinney wrote: post #71

Earlier quoted context omitted.

Transit also allows you to use msgpack, but JSON is more performant on the web. Another feature Transit has is that it caches identical keys (can also cache values with some additional code), giving you a smaller footprint.

Sure, but all that comes at the huge disadvantage of throwing away the ability for someone to just grab a JSON library and access your data adhoc. Now you have to fiddle with stripping away tildes and cache references and such. At the same time, I don't see how you can do anything sensible with Transit except throw it in to a hashmap/dict alongside runtime type information. This is natural for dynamic languages, but,…

The great thing about Transit is that I can extend the data layer with new types (like JodaTime). Even without that, I really like Transit's builtin support for sets, keywords, symbols, lists and vectors (which really helps in a clojure environment).

Another great thing (again, for someone using functional languages) is that Transit can ensure identity for equal values.

When it comes to structural validation, that is something I use prismatic.schema for. Of course, it helps that I can share the validation code between backend and server (using Clojure and ClojureScript).

When using plain JSON, I had to convert types myself after decoding/encoding, which was error-prone and gave a surprising amount of bugs (especially regarding dates).

Transit solves a big problem for me, while still retaining the easy to read syntax which JSON has, and also has great tooling in browsers.

Also, caching isn't only about smaller size. It allows for faster parsing of the initial data, allowing Transit to be just as fast as plain JSON for certain payloads, even considering that it has to expand from cache and decode values.

Re: Transit: JSON Data Interchange Format

#84

Post by vocaro »

gioele wrote: post #75
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…

> 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. XML has become the go-to schemaless format between languages, despite being verbose and having problems with typing. JSON aims to be a general-purpose successor to XML here.

XML is not schemaless. It was designed to be extensible through schemas. It's in the name, after all: eXtensible Markup Language.

XML also doesn't suffer the problems of a limited set of pre-defined types that JSON has. Its type system is extensible through schemas.

Re: Transit: JSON Data Interchange Format

#85

Post by Skinney »

Skinney wrote: post #74
creshal wrote: post #11

Reinventing XML, one data type at a time.

Not really. Transit doesn't care about the underlying data-layer. It could be JSON, could be msgpack, could be XML. Currently, only JSON and msgpack backends exist. XML is probably ruled out due to performance.

Why the downvote? XML could also benefit from automated tag-shortening (in my last place of employement, we encoded XML-tags and attribute-keys manually).

Re: Transit: JSON Data Interchange Format

#86

Post by dragonwriter »

vocaro wrote: post #84
gioele wrote: post #75

Earlier quoted context omitted.

> 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. XML has become the go-to schemaless format between languages, despite being verbose and having problems with typing. JSON aims to be a general-purpose successor to XML here.

XML is not schemaless. It was designed to be extensible through schemas. It's in the name, after all: eXtensible Markup Language. XML also doesn't suffer the problems of a limited set of pre-defined types that JSON has. Its type system is extensible through schemas.

> XML is not schemaless.

Yes, it is, though there are a variety of schema schemes that can be used with XML.

> It was designed to be extensible through schemas.

It was designed to be extensible through custom tags (in fact, all tags are custom tags); it can be optionally be restricted through the use of schemas, not extended.

> XML also doesn't suffer the problems of a limited set of pre-defined types that JSON has.

Yes, it does, with an even smaller number of types. (Strings, with a couple different representations.)

> Its type system is extensible through schemas.

No, it isn't. Its structure can be constrained through schemas (XML Schema, Relax NG, etc.), which can provide a means of modeling a different type system on top of the data structure supported by XML, but that isn't really "extending" XMLs type system any more than using a Haskell compiler to generate x86 machine code is "extending" the type system of x86 machine code; its just providing a completely separate type system on a different layer.

Also, no matter how you view this, its not a distinction between XML and JSON, since you can do the same thing with JSON, and just as there are a variety of different schema standards that do this for XML, there are a variety that do the same thing for JSON.

Re: Transit: JSON Data Interchange Format

#87

Post by nmeofthestate »

brianberns wrote: post #79
gioele wrote: post #75

Earlier quoted context omitted.

> 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. XML has become the go-to schemaless format between languages, despite being verbose and having problems with typing. JSON aims to be a general-purpose successor to XML here.

Yes, except that XML has a schema (XSD).

Ahem. http://json-schema.org/

Re: Transit: JSON Data Interchange Format

#88

Post by dragonwriter »

jimktrains2 wrote: post #81
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…

> maps (with arbitrary scalar keys, not just strings) Floating point keys just seem like a terrible idea.

> Floating point keys just seem like a terrible idea.

I don't see why floating point (with a defined precision) keys are any worse fundamentally than any finite-domain scalar keys. The applications for which they are useful may be limited, and they may be the wrong choice for some uses, but that's true of anything.

Re: Transit: JSON Data Interchange Format

#89

Post by dragonwriter »

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.

> Nodes for data, attributes for metadata.

Its a nice soundbite, but it ends up being less than useful in practice, because all metadata is data, and almost any data can be viewed as metadata, a distinction which is both subjective and strongly influenced by the use to which a consumer is putting the data rather than being determined on the basis solely of the inherent nature of the data.

Re: Transit: JSON Data Interchange Format

#90

Post by jimktrains2 »

dragonwriter wrote: post #88
jimktrains2 wrote: post #81

Earlier quoted context omitted.

> maps (with arbitrary scalar keys, not just strings) Floating point keys just seem like a terrible idea.

> Floating point keys just seem like a terrible idea. I don't see why floating point (with a defined precision) keys are any worse fundamentally than any finite-domain scalar keys. The applications for which they are useful may be limited, and they may be the wrong choice for some uses, but that's true of anything.

> floating point (with a defined precision)

If it's fixed-precision it's not floating point, it's basically an integer we interpret with a decimal point somewhere when we display it. If you didn't mean fixed-precision, then I'm not sure how actual floating points could sanely act as a hash key.

Post reply on HN