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

61–70 of 107 posts

Re: The rise and rise of JSON (2017)

#61

Post by jcelerier »

taeric wrote: post #4
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…

You would have loved s-expressions in a typical lisp setup, then. :) And you have also obviously never fallen victim to slightly off spec JSON parsers and folks that took advantage of them. Trailing commas? Definitely useful. Until they break a system. (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...)

> (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...)

I just checked an a comma is a grand total of three filled pixels on my coding font in my screen while a parenthese is 12 pixels. Parentheses are freakin visual bloat. Just look at this : https://i.imgur.com/UTGjbI5.png

Re: The rise and rise of JSON (2017)

#62

Post by majewsky »

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.

Also https://swagger.io/

Re: The rise and rise of JSON (2017)

#63

Post by majewsky »

donmatito wrote: post #27
ubernostrum wrote: post #22

Earlier quoted context omitted.

The counterpoint here is that a lot of the success of JSON was in presenting an alternative to the then-state-of-the-art, which was basically "here's a small mountain of spec documents explaining how you need at least fifty megabytes of metadata spread out over forty-three separate namespaces' worth of elements to safely send a single string key to someone else with XML". And at the time people insisted JSON could ne…

Or, "worse is better"

Not really. There sure are some warts and inconsistencies in implementations (and across specs), but the success is because of the limited complexity. It's more "perfection is achieved not when there is nothing to add but when there is nothing left to take away" than "worse is better".

Re: The rise and rise of JSON (2017)

#64

Post by tannhaeuser »

taeric wrote: post #24
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. :)

Oddly, attributes do little to actually help you here. What mattered was that xml gave you a language that could describe a valid document. Which, for reasons that actually exist, wasn't necessarily a valid xml document. That said, the effort to write a valid schema was rather high. And it was sold with the other technologies that were in violation of the anti-fragile spirit of the web. That left us with people wanti…

JSON was just a quick shot by Douglas Crockford. No need to spin a genesis myth around it.

Re: The rise and rise of JSON (2017)

#65

Post by Mikhail_Edoshin »

asavinov wrote: post #53
dragonwriter wrote: post #50

Earlier quoted context omitted.

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.

You're trying to impose an arbitrary model on XML.

XML grew from markup languages. It's as if we took some text, parsed it, and then store the resulting syntax tree along with the text. Here elements are non-terminals of the grammar and element attributes are additional augmenting properties of those non-terminals.

The text, of course, does not have to human-readable, it can very well be a sequence of anything, for example, of bits, bytes, words, etc. In XML we'd have to represent these with special elements, something like or , but once we do this, we can use XML to enclose them into additional non-terminals that tell us what these bytes mean and let us use automated tools to manipulate them.

XML can represent objects, but in its own way: we have to first sort of serialize our object into a sequence and once we have this sequence, we can use XML. The model you seem to be talking about an abstract model of abstract objects in memory. Although memory is technically sequential, we normally ignore this and treat objects as nodes in some graph. This is not the domain of XML; it has to be a sequence to begin with. XML has a concept of IDs and references to IDs and thus can represent graphs reasonably well, but it must be a serialized graph.

So XML is basically a language to express the underlying grammatical structure of an arbitrary sequence. That structure is a tree, but it is based on a sequence nonetheless. It's not quite what abstract objects are in programming; but if you think of files, for example, files are sequences and thus are totally the domain of XML.

Re: The rise and rise of JSON (2017)

#66

Post by majewsky »

gaius wrote: post #48
Zamicol wrote: post #10

JSON is one of the best things to ever come out of the CS disciplines. It is one of the most perfect technologies I deal with.

Well, unless you need to deal with datetimes or timestamps. And it suffers from the same repeated-metadata problem that XML does. It’s easy for JavaScript users, that’s it’s main purpose. For serialised data either at rest or on the wire there are dozens of better formats e.g. HDF5. Or even ASN.1.

> It’s easy for JavaScript users, that’s it’s main purpose.

I'm writing Go applications that talk to Python applications with (you guessed it) JSON-over-HTTP. Saying that JSON is only for JS users is like saying the iPhone is only for people that need to make calls.

> For serialised data either at rest or on the wire there are dozens of better formats e.g. HDF5. Or even ASN.1.

A huge advantage of JSON is that it is human-readable and human-writable without extra tooling (although an indenter sure makes things easier on the eye). Also, I recall ASN.1 parsers being a rich well of RCE bugs.

Re: The rise and rise of JSON (2017)

#67

Post by tannhaeuser »

lkuty wrote: post #37
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…

Yes but in XML we view things as trees, not sets, tuples, or the likes. If you consider stuff as trees, there is not anti-pattern and the example is not wrong, it is correct. It is easy. Maybe we can be a little bit dissatisfied with the choice of attributes vs elements. Of course JSON and its small spec is easier than XML and its bunch of complex recommendations.

I think it's more appropriate to say XML is about a grammar description of some information serialization. Whereas JSON starts from concepts such as maps which are higher-level data structures. Also, SGML/XML originally isn't so much about trees as about regular tree languages - where the sequence of elements appearing below a node must satisfy a content model given by a regular expression.

Re: The rise and rise of JSON (2017)

#68

Post by lmm »

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…

XML with schema (and namespaces, which schemata necessitate) is an immense pain to work with. XML with simple elements and no namespaces is actually fine to work with, as is something like thrift/protobuf. I don't think the problem is that XML has schema and validation, it's that it has bad schema and validation.

Re: The rise and rise of JSON (2017)

#70

Post by Mikhail_Edoshin »

gaius wrote: post #48
Zamicol wrote: post #10

JSON is one of the best things to ever come out of the CS disciplines. It is one of the most perfect technologies I deal with.

Well, unless you need to deal with datetimes or timestamps. And it suffers from the same repeated-metadata problem that XML does. It’s easy for JavaScript users, that’s it’s main purpose. For serialised data either at rest or on the wire there are dozens of better formats e.g. HDF5. Or even ASN.1.

Repeated metadata is just one of XML serializations, although the most common one. But there are technologies to compress XML and compression based on schema may give very compact results.
Post reply on HN