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

The rise and rise of JSON (2017)

twobithistory.org

Post reply on HN
Print view View original

71–80 of 107 posts

Re: The rise and rise of JSON (2017)

#71

Post by lmm »

joesb wrote: post #11
denormalfloat wrote: post #6

The success of JSON is due to one thing: Browser support. As soon as it's use on a server, or a mobile device, or practically anywhere else almost all the benefits of JSON go away. Can you inspect the payload easily? Well, yeah, if you unwrap the bytes into a string or open up Wireshark. But on any moderately optimized system, the JSON is going to be gzip encoded and whitespace compressed, making in quite unpleasant…

Changing fieldName is not easy in any data format. Schema has nothing to do with it. If your schema change, you are still going to to break existing client somewhere. It's not like schema can magically tell which field is renamed. Schema also doesn't help different permutation of how a field is spelled. Because, in web world, nobody is going to use your schema. So you just end up with 5 schemas, each with different w…

> Changing fieldName is not easy in any data format. > Schema has nothing to do with it. If your schema change, you are still going to to break existing client somewhere. It's not like schema can magically tell which field is renamed.

If you use something like thrift or protocol buffers then the field on the wire is numbered, and so you can change the human-friendly name that's used in code without breaking wire-level compatibility.

Re: The rise and rise of JSON (2017)

#72

Post by lmm »

humbleMouse wrote: post #12
foota wrote: post #9

Earlier quoted context omitted.

I would argue that the fact that json doesn't have schema support built in makes it more difficult to handle those issues though.

Avro json schemas and jackson json annotation for POJOS makes json object schemas easy to implement. Versioned object repos make great shared schemas and are easier to manage than xsds. (imo)

Anything would be better than XSD (though I don't think JVM-only is a good idea), but with an object you still don't necessarily know what kind of changes are going to be forward compatible or not. The only thing I've had any success with is something like Thrift or Protocol Buffers, where the canonical definition of your objects is a terse, Algol-like syntax but one that's been designed explicitly with version compatibility in mind, and you know exactly what changes do or don't break compatibility.

Re: The rise and rise of JSON (2017)

#73

Post by vertere »

> By being at the intersection, [JSON] turns out to be the thing that everybody can agree on, and so it's really easy to pass data back and forth. Prior data interchange formats tended to try to be the union of all the languages, and that turns out to be horrendously complex and really difficult to deal with. JSON by being so simple actually became really easy to use.

- Douglas Crockford ('discoverer' of JSON)

https://youtu.be/-C-JoyNuQJs?t=730

Re: The rise and rise of JSON (2017)

#74

Post by tlocke »

wetpaws wrote: post #39
hguhghuff wrote: post #16

It’s a great thing that JSON adequate. It’s a great pity that JSON isn't much better. It would be great if JSON had comments, more thorough typing and determinism so that data structures could be compared. Apart from that it’s streets ahead of XML.

It's exactly as good as it needs to be. Trying to 'improve' JSON will turn it into xml again.

Surely it's a problem that in JSON, duplicate keys are allowed?

https://stackoverflow.com/questions/21832701/does-json-synta...

Re: The rise and rise of JSON (2017)

#75

Post by sametmax »

bouke wrote: post #17
sidstling wrote: post #2

I write a lot of smaller service agents, connecting legacy systems or feeding them with data in the public sector of Denmark. Most of those are done with XML and it’s often quite terrible. We write a lot of C# but one of our tools is an old adobe lifecycle server, and .Net XML isn’t the same as Adobe XML. I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break…

You’re comparing SOAP, a message protocol, with JSON, a data format. SOAP is so much more, it specifies how objects are defined, how they should be serialized and delivered to a server (WSDL). Note that JSON doesn’t have anything like this that has seriously taken off. There’s a few attempts, but they aren’t in great use or have tooling support. So as a result everyone working with JSON implements their own de-/seria…

Yeah but most projects I worked on used soap as a data format. I had to interface with a french administration that parsed the xml manually (poeple printed and read it) and an american administration that used regex to read the xml.

Just having devs reading the dom correctly, including namespaces, is a rare occurence. It's sad, but we are living in a time were too many software is written, and not enough competent devs are available.

So simplicity, again, wins.

Re: The rise and rise of JSON (2017)

#76

Post by sametmax »

vertere wrote: post #73

> By being at the intersection, [JSON] turns out to be the thing that everybody can agree on, and so it's really easy to pass data back and forth. Prior data interchange formats tended to try to be the union of all the languages, and that turns out to be horrendously complex and really difficult to deal with. JSON by being so simple actually became really easy to use. - Douglas Crockford ('discoverer' of JSON) https:…

What amazes me is that I regularly train people in IT that have never used JSON themself and are not sure what's it good for.

So something that is quite everywhere now, is simple, easy, and has existed for a long time, is still far from being a given.

It definitely puts in perspective people that are telling me that my webpack configuration from last year is obsolete, that I should ditch everything and learn Elm, that nix is the future of package management or that webassembly is going to change everything next week.

Re: The rise and rise of JSON (2017)

#77

Post by atakiel »

asavinov wrote: post #26

If we ignore syntactic aspects then the success of JSON is due to one fundamental reason. JSON relies on two structural elements [] and {}, which have very clear semantics of sets (collections) and tuples (combinations), respectively. It is simple, general, natural and consistent. In comparison, XML also provides two structural elements but they do not have such a nice duality and clarity of interpretation. Here is a…

Rich Hickey has a good point in his Rails Conf 2012 "Simplicity Matters" talk[0] - json is just more simple than xml, as it clearly states which parts are maps and which are sequences. Xml has an inherent, implicit order in everything, due to its history as a document markup language.

If you think xml through the lens of jsx pragma style transformation, xml element and it's attributes are more or less a (typed) map. Similarly element's children is an (ordered) sequence. Where as in json you can have maps inside maps, in xml you always have to wrap maps inside an ordered sequence, as maps can only be passed to element as its children.

You can totally use xml without paying attention to the order, but the order is still there, complicating things.

[0] Rails Conf 2012 Keynote: Simplicity Matters by Rich Hickey - https://youtu.be/rI8tNMsozo0?t=28m5s

Re: The rise and rise of JSON (2017)

#78

Post by bouke »

senozhatsky wrote: post #21
pingec wrote: post #14

I use XSD a lot for XML validation in .net world and better intellisense when writing XML by hand. I was exploring the json world but I could not find a json schema technology that would be as expressive and the tooling around it is much inferior IME. I feel like the technology around schemas (json, xml or anything else) is underrated and not developed enough. And if I wanted to support both json and xml it would be…

> would be nice to have a tool that could translate xml schema to json schema and back. Hmm, after a quick search I found a bunch of json-to-xml and xml-to-json converters, including libraries. E.g. JSON-Java library [0]. May be same things exist for .Net. Is this what you meant? [0] https://github.com/stleary/JSON-java -ss

I think parent was talking about the document definition (schema) instead. So not to rely on the document instance for the translation definition.

Re: The rise and rise of JSON (2017)

#79

Post by bouke »

pingec wrote: post #14

I use XSD a lot for XML validation in .net world and better intellisense when writing XML by hand. I was exploring the json world but I could not find a json schema technology that would be as expressive and the tooling around it is much inferior IME. I feel like the technology around schemas (json, xml or anything else) is underrated and not developed enough. And if I wanted to support both json and xml it would be…

> would be nice to have a tool that could translate xml schema to json schema and back.

I once worked with a customer that bolted a JSON frontend onto an existing XML backend. However the translation definition was not predefined but determined at runtime. Some XML node could have 1+ children but because of this translation the result would either be an object (1), or an array of objects (2+). Needless to say the implementation in the consumer became rather messy, having to deal with this dynamic structure.

Re: The rise and rise of JSON (2017)

#80

Post by rhencke »

gaius wrote: post #44
humbleMouse wrote: post #3

Earlier quoted context omitted.

> Working with JSON never takes longer than it should. This is the key point right here. JSON is a big reason I love groovy so much. No matter what json you have in groovy, you are a couple lines of code and a couple closures away from doing anything. I always use json string payloads on HTTP aswell. It vastly simplifies rest service development. Another thing I love about json is using it with cassandra. So easy to…

Ah, Groovy. All the brevity of Java and all the type safety of JavaScript. I had no idea anyone still used it, let alone loved it!

That's an unfortunate stance on Groovy. Groovy code is often far more brief than Java's, and it has some beautifully expressive capability for making DSLs, both through its world-view on closures and its ability for the developer to walk and modify the AST at compile time (see, for example, the @Canonical attribute for how this can be useful)

While I, too, wish it built on a statically typed base, Groovy offers amenities such as @CompileStatic that go a long way towards alleviating this.

I personally find Kotlin strikes a wonderful spot with the brevity and expressiveness of Groovy, while managing to be more type-safe than Java (reified generics, null safety in the type system). But there is no denying Groovy's heavy influence on Kotlin, either.

Groovy may not be perfect but I don't think the picture you paint is accurate, either.

Post reply on HN