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

51–60 of 107 posts

Re: The rise and rise of JSON (2017)

#51

Post by ainar-g »

WorkLifeBalance wrote: post #32
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…

XML without schema are a mess. XML with schema and validtion can be a joy to use compared to the untyped JSON world, but it's the lack of having to specify type which helps JSON remain popular. Given a choice between strong or weak typing and weakly typed or un-typed systems will prevail in popularity. Looking at javascript itself and the type coercion rules it is easy to dismiss it as unworkable mess which leads to…

There is a draft of JSON schema: http://json-schema.org/. And there are working implementations.

Re: The rise and rise of JSON (2017)

#52

Post by niftich »

JSON maps well and intuitively to common datatypes: with a list and a hashmap, you can model a lot. Conversely, structs needing to be passed around in application code will probably be made up of stuff that maps well to JSON. XML's greater-than-blindingly-obvious impedance mismatch is a barrier to entry when an alternative, dead simple format exists.

The XML ecosystem nonetheless has parts that are desirable for certain use-cases, as the reinvention of schema validation for JSON, awkward namespacing, and efforts to dabble in hypermedia linking show. The XML ecosystem didn't require these enhancements and extensions to be used, but implementations in the wild often did, which was further off-putting to newcomers. This helped JSON gain ground back when it (and the ecosystem around it) was truly minimal and simple.

It also embodied the hacker, kludgey ethos and mythos, because without elaborate schemas and code generators, you'd pluck out only the fields you cared about and disregard the rest.

These factors led to JSON's rise at an opportune time, giving it credence and exposure, and within a few years every hip cool API was emitting JSON and using cool methods like PUT and DELETE and throwing around terms like REST despite serving linkless structs as 'application/json'.

The prevalence and staying power of CRUD HTTP APIs exchanging loosely typed JSON payloads shows that there's real benefits to semi-human-readable, self-documenting payloads that can be parsed into either rigid native datatypes, or loose collection types with ease. JSON fits into a world where stuff can be deliberately or inadvertently half-assed and still work.

Re: The rise and rise of JSON (2017)

#53

Post by asavinov »

dragonwriter wrote: post #50
asavinov wrote: post #42

Earlier quoted context omitted.

Typing (enforcing constraints) is an important aspect. But even without typing XML has one fundamental flaw. You are not able to (correctly) represent tuples with attributes which are sets. In XML, tuple attributes are properties, for example: -- object or object Now let us assume that I want to have a list of authors as a property: -- NOT SUPPORTED Therefore, we use a workaround (a crime actually): Me My friend Now…

Pretty much any time I've seen something like this, relevant inner element of the book is: ... ...

It is again a workaround because is a member of a collection - it is not a tuple attribute. Which suggests that we cannot enforce this separation and an application has to understand itself which element is an object property and which element is a member of a collection.

Re: The rise and rise of JSON (2017)

#54

Post by zmmmmm »

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!

Pretty much wrong on all counts - doesn't sound like you know very much about groovy at all?

Re: The rise and rise of JSON (2017)

#55

Post by ainar-g »

dragonwriter wrote: post #50
asavinov wrote: post #42

Earlier quoted context omitted.

Typing (enforcing constraints) is an important aspect. But even without typing XML has one fundamental flaw. You are not able to (correctly) represent tuples with attributes which are sets. In XML, tuple attributes are properties, for example: -- object or object Now let us assume that I want to have a list of authors as a property: -- NOT SUPPORTED Therefore, we use a workaround (a crime actually): Me My friend Now…

Pretty much any time I've seen something like this, relevant inner element of the book is: ... ...

Which reminds me of the picture[1] on the cat-v.org section about XML.

[1] http://harmful.cat-v.org/software/xml/xml_ascent.png

Re: The rise and rise of JSON (2017)

#56

Post by gaius »

zmmmmm wrote: post #54
gaius wrote: post #44

Earlier quoted context omitted.

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!

Pretty much wrong on all counts - doesn't sound like you know very much about groovy at all?

Have unfortunately had to use it as it was the scripting language embedded in an application we used. Now I avoid it whenever possible. Even BeanShell was better!

Re: The rise and rise of JSON (2017)

#57

Post by tannhaeuser »

ubernostrum wrote: post #30
blauditore wrote: post #13

It's funny how people often compare JSON and XML, but don't mention one huge difference: XML is "more powerful" because it supports attributes on nodes, while JSON doesn't. So if you want to encode data structure with metadata on nodes (like objects with a type), you'll have to introduce a non-standard workaround. Of course that's often not an issue, but I've run into it in the past. :)

http://www.flightlab.com/~joe/sgml/faq-not.txt Q. I'm designing my first DTD. Should I use elements or attributes to store data? A. Of course. What else would you use? Q. What is the usual way to choose between using attributes and children? [Update from David Carlisle:] In England, the normal method is to flip a coin in the air and call heads it's attributes, tails it's children. Unfortunately I'm not sure what to s…

Hilarious, but the deeper rule is: when there isn't a concept of rendering a document to the user (where attributes hold rendering properties not directly presented to a user) the concept of a markup language doesn't make sense in the first place. So if you find yourself in a situation where you need to decide on encoding data as elements vs attributes, you probably shouldn't use SGML/XML at all.

But then there is the wealth of XML standard data representations for financial/fiscal/e-commerce, medical, etc. data. You're deciding to use them to have your interfaces being implemented once and for all, and be able to switch eg. payment providers by merely specifying new endpoints and credentials. JSON doesn't really compare to XML/XSD in this space.

Re: The rise and rise of JSON (2017)

#58

Post by tlocke »

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.

Have you seen Zish? https://github.com/tlocke/zish It's designed to be an improvement on JSON, so it supports comments and has native timestamp, bytes and decimal types.

Re: The rise and rise of JSON (2017)

#59

Post by tannhaeuser »

zaarn wrote: post #40
WorkLifeBalance wrote: post #32

Earlier quoted context omitted.

XML without schema are a mess. XML with schema and validtion can be a joy to use compared to the untyped JSON world, but it's the lack of having to specify type which helps JSON remain popular. Given a choice between strong or weak typing and weakly typed or un-typed systems will prevail in popularity. Looking at javascript itself and the type coercion rules it is easy to dismiss it as unworkable mess which leads to…

JSON does have Schemas and Validation (JSON-LD and RDF I believe are the relevant standards here), which are backwards compatible with parsers that don't support it (though the number of parsers that do is sadly rather low). In principle you still get schema and validation.

No. JSON-LD aims at aiding interpretation of JSON as RDF data (semantic web, description logic). It's terrible IMHO.

Re: The rise and rise of JSON (2017)

#60

Post by zaarn »

tannhaeuser wrote: post #59
zaarn wrote: post #40

Earlier quoted context omitted.

JSON does have Schemas and Validation (JSON-LD and RDF I believe are the relevant standards here), which are backwards compatible with parsers that don't support it (though the number of parsers that do is sadly rather low). In principle you still get schema and validation.

No. JSON-LD aims at aiding interpretation of JSON as RDF data (semantic web, description logic). It's terrible IMHO.

There is also JSON-schema.org if you don't like RDF/LD.
Post reply on HN