7 ms·

The rise and rise of JSON (2017)

83 points by henridf 8y ago

sidstling 8y ago
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 when they aren’t. So in order to make the two techs talk with each other through SOAP, we had to write a custom library to translate the .Net xml before we send it. And that’s just one in a long line of similar stories. Hell, SOAP calls en general take longer time to get running than any JSON rest service call I’ve ever set up. Even when the XML interprets the same on both ends, though I’m not sure why that is exactly. So it’s fair to say that I love JSON. The article outlines it as being easier to read, and there is certainly that, but for me it’s the efficiency. Working with JSON never takes longer than it should.
- humbleMouse 8y ago
  > 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 store big maps that hold the state of different things. Dont even get me started on avro/kafka/etc....
  - taeric 8y ago
    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...)
    - TuringTest 8y ago
      That may be because you don't need to keep track of how many commas are there, you can just throw them in wherever you need one. Yet parentheses must always come in pairs, you need a pair for every term in the program (brackets are only needed for full statements), and they tend to pile down at the end of complex functions and data structures.
      - taeric 8y ago
        I have seen more than my fair share of build failures from missing or extra commas. Worse, they have odd behavior in some languages. That said, I cede that they are different. I just don't get the hate of parens.
        sli 8y ago
        My frontend builds fail because of trailing commas in the code (by design, so technically a non-issue). At the same time, my editors can balance parens but they can't really do anything but complain about trailing commas. It can't assume it's an issue and "fix" it because I just might not be done writing, yet. My editor can make more and safer assumptions about paren balancing, however, and so it does. I really have no horse in this race, neither of these things bother me. I just can't help but notice that the paren problem in particular can be easily rectified.
        TuringTest 8y ago
        Yeah, I concur. I mean, instances have a "global stream" where all posts from all users are sent? What's the use for that? It would be like Facebook or Twitter having a "front page" showing all posts from all their users. I don't want to read what something posted merely because they're subscribed to the same physical server. There should be some classification of affinity by common interests.
    - jcelerier 8y ago
      > (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 https://i.imgur.com/UTGjbI5.png
  - gaius 8y ago
    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!
    - zmmmmm 8y ago
      Pretty much wrong on all counts - doesn't sound like you know very much about groovy at all?
      - gaius 8y ago
        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!
    - rhencke 8y ago
      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.
      - vorg 8y ago
        If you need to use the JVM ... > walk and modify the AST at compile time Clojure is best for this. A macro only a few lines long in Clojure will do the same as what a few hundred lines in Apache Groovy are required for. It's possible to walk the AST in Groovy but it's verbose and messy. > CompileStatic that go a long way Both Kotlin and Scala are both statically typed from the ground up, instead of having a @CompileStatic annotation tacked on later. > the brevity and expressiveness of Groovy Groovy started off in 2003 as a functionally similar clone of Beanshell, which had already existed since 1999, but with closures added. Someone then translated all the standard functional methods from Ruby into Groovy's codebase. Of course, Jython, a JVM version of Python, has been around since 1997. So Groovy is a relative late comer to the JVM in this regard. Groovy tried to be a bit of everything for everyone on the JVM, but has ended up being used only for 20-line build scripts in Gradle.
- bouke 8y ago
  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-/serializer, resulting in all sorts of errors. SOAP on the other hand takes care of this and even has a formalized date type and various number types. Your complaint is about two vendors creating incompatible inplementations/extensions. I’ve run into this as well and causes a lot of issues with compliant implementations that cannot work together. I think this has been a big reason why eventually SOAP will die.
  - donmatito 8y ago
    I think parent's point was that with JSON you are, in most langages, a JSON.parse(payload) away from a message protocol. I am interfacing our startup's services with legacy (insurers) systems. We don't use the same programming langage. The docs are missing. Yet, we somehow manage to set up a functional API with minimal pain using JSON. When I compare that, to the amount of documentation a SOAP service requires (for another partner), I find JSON much more usable
  - sametmax 8y ago
    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.
  - sidstling 8y ago
    I did specifically say it wasn’t technically the languages fault, but you certainly have a point. I don’t think it’s completely unreasonable to bring in SOAP even though you’re talking about the language, because I’ve almost never worked with XML without also working with SOAP. But in not completely comparing it to JSON either, I mean, I love JSON for the efficiency of transferring it between systems, so I’m not completely comparing XML/SOAP to JSON the language either. As far as lifecycle goes, it’s not actually the SOAP call but the way the two tech stacks parse the XML that’s the problem. You can also do rest calls with livecycle, and you’ll run into the same problems trying to pass XML created by any of the standard .net libraries to it. I agree SOAP is terrible, but part of my point is that SOAP taints XML, because it’s a really common way to transfer XML. I do use XML in other ways of course. We get quite a few datadumps in XML, that I turn to SQL through Microsoft SSIS, and even here it’s annoying. Not so much the language, but the way it breaks your SSIS service if it’s not delivered exactly as specified in its schema. Obviously that shouldn’t happen, but it does. Sometimes a supplier delivers half a file, and everything because SSIS didn’t get the XML specified in the schematic. (The fact that this breaks this is another wonderful story, where multiple datasets gets delivered within the same XML file.) JSON and XML are languages, as you say, but their main usage (at least for me) is transferring data between systems and techs, and that is almost always easier, simpler and safer with JSON. Maybe it’s unfair to call JSON the better language because of that, but it’s certainly more useful to me.
- collyw 8y ago
  It does. Its not that much different from Python dictionaries, but those are so much more pleasant to work with. Trailing commas, comments (in large multiline dictionaries) and proper integers are some features I can think of. Small things like those can make a big difference in ease of use for many practical cases.
- Zardoz84 8y ago
  > I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break when they aren’t. So in order to make the two techs talk with each other through SOAP, we had to write a custom library to translate the .Net xml before we send it. And that’s just one in a long line of similar stories. Something similar happens me with Java. Our product have some legacy ancient code that serialize/deserialize XML to beans using a library (JOX) that works with pure reflection (pre Java annotations). I try to replace it for something more modern like Jackson or JAXB, but I hit a wall when I found that the XML that reads/writes these library are very different from what Jackson or JAXB expect to find. So, or we translate all XMLs to the new format or I write some translator to transform the old XMLs to something more standard.
saagarjha 8y ago
Of course, JSON has its own share of issues too, largely as a result of it trying to be as simple as possible. Many JSON parsers support nonstandard features such as comments and trailing commas, and in the process, create mutually incompatible "dialects". XML might be verbose and complicated, but I think JSON unfortunately is a bit too far in the other direction.
- function_seven 8y ago
  If a JSON parser ignores the JSON spec, is it the spec that went too far in the other direction? Or is that parser just badly-written? (Or misguidedly lenient?) You could say the same for an XML parser that allows a naked '&' between tags, or continues parsing a document that omits a closing tag somewhere. Your complaint is probably still valid, but I'd say it's better directed at the culture than the specs.
denormalfloat 8y ago
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 to look through. By that point a pretty printer is needed, and you might as well have picked any format that has a pretty printer. Can you add new fields easily? Yeah, but try changing a field name, or its type, or remove a field. This is guaranteed to break some client or server somewhere eventually. I've seen code that uses at least 5 permutations of "Zipcode", "zipcode", "zip_code", etc. I also wouldn't dare try to change it for fear of accidentally breaking our payments processing system. JSON trades ease of starting up, for suffering when the code base gets big. It's an incredibly alluring trap, as TFA's graph shows.
- humbleMouse 8y ago
  Why are you using wireshark to inspect json payloads? Your other complaints stem from poor system design and lack of shared data contracts. They could be complaints about any data format.
  - foota 8y ago
    I would argue that the fact that json doesn't have schema support built in makes it more difficult to handle those issues though.
    - humbleMouse 8y ago
      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)
      - lmm 8y ago
        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.
Schwolop 8y ago
This article had a footnote linking to a snide Douglas Crockford retort to a blog post that was dismissive of JSON. The other discussion comments on that page are a fascinating history of the arguments for and against, through the lens of 2006. https://scripting.wordpress.com/2006/12/20/scripting-news-for-12202006/#comment-26383 https://scripting.wordpress.com/2006/12/20/scripting-news-fo...
- joatmon-snoo 8y ago
  Whoa, thanks for linking that. It's really interesting seeing all this talk about sandbox escapes. This is a particularly interesting quote: > One huge practical advantage to JSON over XML in the web browser is that you can load JavaScript from any site, while you’re restricted in which sites you can load XML from. I have no idea why browsers insist on limiting where you can load non-executable XML from, when they don’t bother to limit where you can load executable JavaScript from, but there you go: that’s how it is, and there’s nothing anybody can do about it. JSON nicely works around that limitation, instead of holding its breath and waiting until the world comes around to being fair. Surely you can appreciate that practical advantage.
Zamicol 8y ago
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.
- stinos 8y ago
  I too admit liking JSON for it's simple yet extremely useful in a whole lot of usecases, but calling it near perfect is a maybe bridge too far. Officially it doesn't have a representation for nan or infinity, otherwise perfectly valid floating point numbers.
- gaius 8y ago
  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.
  - majewsky 8y ago
    > 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.
  - Mikhail_Edoshin 8y ago
    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.
blauditore 8y ago
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. :)
- taeric 8y ago
  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 wanting something different. JSON was born as much for basically being javascript literals minus functions as it was anything else. Most any other explanation is just someone selling you something. (Now, attributes did offer a technical way to ignore subsets of the attributes that would be hard to do any other way. But they didn't exactly make it easy, and namespaces did not compose nearly as well as people hoped they would.)
  - tannhaeuser 8y ago
    JSON was just a quick shot by Douglas Crockford. No need to spin a genesis myth around it.
    - taeric 8y ago
      I don't know what genesis myth you mean. I do know that I was regularly serializing JavaScript literals for years before I heard of json. Basically just said I could no longer serialize functions. Or references. Which, to be fair, was not that common and I could easily live without. I do miss being able to have comments.
- tannhaeuser 8y ago
  It's funny how people often compare JSON and XML, but fail to see that XML/SGML is for document data (like whole web pages) whereas JSON is a clever reuse of JavaScript object literal syntax.
pingec 8y ago
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 such a pain to maintain, would be nice to have a tool that could translate xml schema to json schema and back.
- lwansbrough 8y ago
  I’ll pass on any serialization format that is itself vulnerable to RCE.
  - eridius 8y ago
    You can easily create a parser with RCE using just JSON. Just define a simple schema that looks like { "type": "ObjectName", … } The only difference between this and e.g. YAML is YAML has specific syntax for declaring the object type whereas with JSON you need to declare it yourself.
- senozhatsky 8y ago
  > 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 https://github.com/stleary/JSON-java -ss
  - bouke 8y ago
    I think parent was talking about the document definition (schema) instead. So not to rely on the document instance for the translation definition.
    - senozhatsky 8y ago
ToFab123 8y ago
So, when do we get a typescript for JSON? You mean a schema like XML has? It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.
- ubernostrum 8y ago
  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 never replace that, because JSON was so underspecified and unsafe. You could maybe get away with it for a couple requests to your puny baby child's "Fisher-Price My First Webservice" toy program, but JSON would instantly and completely fall over the instant any real-world problem presented itself. Yet here we are all those years later, in a world which largely runs on JSON as a data interchange format. Or, more concisely, as I wrote in 2006 in response to the Dave Winer piece someone else linked in another comment: And now here are these kids with their startup companies and their weblogs who are getting data exchange and even things that kind of look like APIs out of… JavaScript arrays? The XML guys are sitting up on the mountaintop like the Grinch, with his pile of stolen presents, wondering how Christmas still managed to happen: it came without specs! It came without hype! It came without angle brackets, envelopes or types!
  - hguhghuff 8y ago
    There’s passion for you.
  - donmatito 8y ago
    Or, "worse is better"
    - majewsky 8y ago
      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".
hguhghuff 8y ago
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.
- wetpaws 8y ago
  It's exactly as good as it needs to be. Trying to 'improve' JSON will turn it into xml again.
  - tlocke 8y ago
    Surely it's a problem that in JSON, duplicate keys are allowed? https://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object https://stackoverflow.com/questions/21832701/does-json-synta...
- tlocke 8y ago
  Have you seen Zish? https://github.com/tlocke/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.
asavinov 8y ago
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 very typical example which is more than an anti-pattern: <books> <book id="1"><title>XML is evil</title></book> <book id="2"><title>XML considered harmful</title></book> </books> Here we see that semantically <books> is a collection while <book> is a tuple (where <title> is an attribute). Yet, they use one and the same structural construct. XML does not enforce the dual semantics of sets and tuples, and therefore XML files are frequently a conceptual mess. The above example is essentially wrong but XML does not care.
- WorkLifeBalance 8y ago
  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 expensive bugs in production, but in the real world the ability to mostly ignore types lets people get things done in a more hackish / amatuer way which eases the learning curve and helps popularity.
  - zaarn 8y ago
    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.
    - tannhaeuser 8y ago
      No. JSON-LD aims at aiding interpretation of JSON as RDF data (semantic web, description logic). It's terrible IMHO.
lkuty 8y ago
XHTML is still alive as the section 13 "The XML syntax" in the "HTML Living Standard" shows us. Moreover XML comes with a host of useful technologies : schemas, XSLT, XQuery and namespaces. It is quite complex compared to JSON but more powerful when you consider the whole ecosystem. In the end, it depends on the need we have. Quick, small, simple XML is possible and easy.
cool-RR 8y ago
"JSON’s dominance is surprising when you consider that as recently as 2005 the web world was salivating over the potential of “Asynchronous JavaScript and XML” and not “Asynchronous JavaScript and JSON.”" "As recently as 2005," heh. In the frontend world, you might as well say "as recently as the Paleolithic age."
nebulous1 8y ago
I think the the only people who could be confused as to the reason for the rise of JSON are people who have never used XML
niftich 8y ago
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.
zde 8y ago
A message format that requires parser to understand both UTF8 and UTF16, cool!
- pitaj 8y ago
  Unsurprisingly, one of the most common data types is text strings, so most serializations need that anyways.
vertere 8y ago
> 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 https://youtu.be/-C-JoyNuQJs?t=730
- sametmax 8y ago
  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.
another-cuppa 8y ago
> only one API exposes data in XML rather than JSON They are not mutually exclusive. It should be trivial to offer the data as either JSON or XML at the user's request.
amaccuish 8y ago
I feel like the best takeaway here is that XML is a document format, and JSON is for programmatic interchange, e.g. APIs. That's at least how I operate, and I use both XML and JSON for various things. My APIs are all JSON, but if I'm serialising some data to disk, or for export etc, it's usually XML.
ktpsns 8y ago
One aspect about JSON is the lack of comments. This makes it mostly unsuitable as a configuration language and in fact simple "JSON for humans" such as https://hjson.org/ https://hjson.org/ and https://json5.org/ https://json5.org/ exist. In my opinion, this is a design flaw and if JSON would be a bit more human-oriented, it could be much more widespread in non-web contexts.
- fenwick67 8y ago
  I actually like that JSON has no comments. With comments in a data transmission format you will end up with things like "conditional comments" in IE. I agree there are certainly many better configuration languages.
  - ktpsns 8y ago
    I agree, but you can do context switchs also without having comments. For instance, the JSON Schema defines (Source: https://json-schema.org/latest/json-schema-core.html#rfc.section.9 https://json-schema.org/latest/json-schema-core.html#rfc.sec...) { '$comment': "string that can hold whatever you want" } and it is obvious that you can embed any other language in a string.
- rurban 8y ago
  It is not design flaw, it was a conscious decision to enhance security. JSON is still the only secure (and fast) generic transport protocol, all others but msgpack are insecure by design. The various attempts to "enhance" json with types, datetime, comments, ... just make it worse, don't fall into that trap. The latest JSON changes also made it more insecure, while they didn't clarify the missing spec points, so even they fell into that trap. msgpack is more also a bit insecure than JSON, but not as dramatic as XML, YAML, BSON, ...
DonHopkins 8y ago
>Though one might think that a contest between data interchange formats would be unlikely to engender death threats, Winer wrote: >"No doubt I can write a routine to parse [JSON], but look at how deep they went to re-invent, XML itself wasn’t good enough for them, for some reason (I’d love to hear the reason). Who did this travesty? Let’s find a tree and string them up. Now." In retrospect, he should have said: "Let's find a tree and stringify it."
cpr 8y ago
Not: as groundbreaking as Scribe (Brian Reid at CMU) was, I don’t think SGML was inspired by it. They had parallel dev paths...

83 points by henridf 8y ago

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 when they aren’t. So in order to make the two techs talk with each other through SOAP, we had to write a custom library to translate the .Net xml before we send it. And that’s just one in a long line of similar stories. Hell, SOAP calls en general take longer time to get running than any JSON rest service call I’ve ever set up. Even when the XML interprets the same on both ends, though I’m not sure why that is exactly. So it’s fair to say that I love JSON. The article outlines it as being easier to read, and there is certainly that, but for me it’s the efficiency. Working with JSON never takes longer than it should.

humbleMouse 8y ago
> 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 store big maps that hold the state of different things. Dont even get me started on avro/kafka/etc....
- taeric 8y ago
  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...)
  - TuringTest 8y ago
    That may be because you don't need to keep track of how many commas are there, you can just throw them in wherever you need one. Yet parentheses must always come in pairs, you need a pair for every term in the program (brackets are only needed for full statements), and they tend to pile down at the end of complex functions and data structures.
    - taeric 8y ago
      I have seen more than my fair share of build failures from missing or extra commas. Worse, they have odd behavior in some languages. That said, I cede that they are different. I just don't get the hate of parens.
      - sli 8y ago
        My frontend builds fail because of trailing commas in the code (by design, so technically a non-issue). At the same time, my editors can balance parens but they can't really do anything but complain about trailing commas. It can't assume it's an issue and "fix" it because I just might not be done writing, yet. My editor can make more and safer assumptions about paren balancing, however, and so it does. I really have no horse in this race, neither of these things bother me. I just can't help but notice that the paren problem in particular can be easily rectified.
        TuringTest 8y ago
        Yeah, I concur. I mean, instances have a "global stream" where all posts from all users are sent? What's the use for that? It would be like Facebook or Twitter having a "front page" showing all posts from all their users. I don't want to read what something posted merely because they're subscribed to the same physical server. There should be some classification of affinity by common interests.
  - jcelerier 8y ago
    > (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 https://i.imgur.com/UTGjbI5.png
- gaius 8y ago
  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!
  - zmmmmm 8y ago
    Pretty much wrong on all counts - doesn't sound like you know very much about groovy at all?
    - gaius 8y ago
      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!
  - rhencke 8y ago
    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.
    - vorg 8y ago
      If you need to use the JVM ... > walk and modify the AST at compile time Clojure is best for this. A macro only a few lines long in Clojure will do the same as what a few hundred lines in Apache Groovy are required for. It's possible to walk the AST in Groovy but it's verbose and messy. > CompileStatic that go a long way Both Kotlin and Scala are both statically typed from the ground up, instead of having a @CompileStatic annotation tacked on later. > the brevity and expressiveness of Groovy Groovy started off in 2003 as a functionally similar clone of Beanshell, which had already existed since 1999, but with closures added. Someone then translated all the standard functional methods from Ruby into Groovy's codebase. Of course, Jython, a JVM version of Python, has been around since 1997. So Groovy is a relative late comer to the JVM in this regard. Groovy tried to be a bit of everything for everyone on the JVM, but has ended up being used only for 20-line build scripts in Gradle.
bouke 8y ago
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-/serializer, resulting in all sorts of errors. SOAP on the other hand takes care of this and even has a formalized date type and various number types. Your complaint is about two vendors creating incompatible inplementations/extensions. I’ve run into this as well and causes a lot of issues with compliant implementations that cannot work together. I think this has been a big reason why eventually SOAP will die.
- donmatito 8y ago
  I think parent's point was that with JSON you are, in most langages, a JSON.parse(payload) away from a message protocol. I am interfacing our startup's services with legacy (insurers) systems. We don't use the same programming langage. The docs are missing. Yet, we somehow manage to set up a functional API with minimal pain using JSON. When I compare that, to the amount of documentation a SOAP service requires (for another partner), I find JSON much more usable
- sametmax 8y ago
  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.
- sidstling 8y ago
  I did specifically say it wasn’t technically the languages fault, but you certainly have a point. I don’t think it’s completely unreasonable to bring in SOAP even though you’re talking about the language, because I’ve almost never worked with XML without also working with SOAP. But in not completely comparing it to JSON either, I mean, I love JSON for the efficiency of transferring it between systems, so I’m not completely comparing XML/SOAP to JSON the language either. As far as lifecycle goes, it’s not actually the SOAP call but the way the two tech stacks parse the XML that’s the problem. You can also do rest calls with livecycle, and you’ll run into the same problems trying to pass XML created by any of the standard .net libraries to it. I agree SOAP is terrible, but part of my point is that SOAP taints XML, because it’s a really common way to transfer XML. I do use XML in other ways of course. We get quite a few datadumps in XML, that I turn to SQL through Microsoft SSIS, and even here it’s annoying. Not so much the language, but the way it breaks your SSIS service if it’s not delivered exactly as specified in its schema. Obviously that shouldn’t happen, but it does. Sometimes a supplier delivers half a file, and everything because SSIS didn’t get the XML specified in the schematic. (The fact that this breaks this is another wonderful story, where multiple datasets gets delivered within the same XML file.) JSON and XML are languages, as you say, but their main usage (at least for me) is transferring data between systems and techs, and that is almost always easier, simpler and safer with JSON. Maybe it’s unfair to call JSON the better language because of that, but it’s certainly more useful to me.
collyw 8y ago
It does. Its not that much different from Python dictionaries, but those are so much more pleasant to work with. Trailing commas, comments (in large multiline dictionaries) and proper integers are some features I can think of. Small things like those can make a big difference in ease of use for many practical cases.
Zardoz84 8y ago
> I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break when they aren’t. So in order to make the two techs talk with each other through SOAP, we had to write a custom library to translate the .Net xml before we send it. And that’s just one in a long line of similar stories. Something similar happens me with Java. Our product have some legacy ancient code that serialize/deserialize XML to beans using a library (JOX) that works with pure reflection (pre Java annotations). I try to replace it for something more modern like Jackson or JAXB, but I hit a wall when I found that the XML that reads/writes these library are very different from what Jackson or JAXB expect to find. So, or we translate all XMLs to the new format or I write some translator to transform the old XMLs to something more standard.

saagarjha 8y ago

Of course, JSON has its own share of issues too, largely as a result of it trying to be as simple as possible. Many JSON parsers support nonstandard features such as comments and trailing commas, and in the process, create mutually incompatible "dialects". XML might be verbose and complicated, but I think JSON unfortunately is a bit too far in the other direction.

function_seven 8y ago
If a JSON parser ignores the JSON spec, is it the spec that went too far in the other direction? Or is that parser just badly-written? (Or misguidedly lenient?) You could say the same for an XML parser that allows a naked '&' between tags, or continues parsing a document that omits a closing tag somewhere. Your complaint is probably still valid, but I'd say it's better directed at the culture than the specs.

denormalfloat 8y ago

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 to look through. By that point a pretty printer is needed, and you might as well have picked any format that has a pretty printer. Can you add new fields easily? Yeah, but try changing a field name, or its type, or remove a field. This is guaranteed to break some client or server somewhere eventually. I've seen code that uses at least 5 permutations of "Zipcode", "zipcode", "zip_code", etc. I also wouldn't dare try to change it for fear of accidentally breaking our payments processing system. JSON trades ease of starting up, for suffering when the code base gets big. It's an incredibly alluring trap, as TFA's graph shows.

humbleMouse 8y ago
Why are you using wireshark to inspect json payloads? Your other complaints stem from poor system design and lack of shared data contracts. They could be complaints about any data format.
- foota 8y ago
  I would argue that the fact that json doesn't have schema support built in makes it more difficult to handle those issues though.
  - humbleMouse 8y ago
    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)
    - lmm 8y ago
      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.

Schwolop 8y ago

This article had a footnote linking to a snide Douglas Crockford retort to a blog post that was dismissive of JSON. The other discussion comments on that page are a fascinating history of the arguments for and against, through the lens of 2006. https://scripting.wordpress.com/2006/12/20/scripting-news-for-12202006/#comment-26383 https://scripting.wordpress.com/2006/12/20/scripting-news-fo...

joatmon-snoo 8y ago
Whoa, thanks for linking that. It's really interesting seeing all this talk about sandbox escapes. This is a particularly interesting quote: > One huge practical advantage to JSON over XML in the web browser is that you can load JavaScript from any site, while you’re restricted in which sites you can load XML from. I have no idea why browsers insist on limiting where you can load non-executable XML from, when they don’t bother to limit where you can load executable JavaScript from, but there you go: that’s how it is, and there’s nothing anybody can do about it. JSON nicely works around that limitation, instead of holding its breath and waiting until the world comes around to being fair. Surely you can appreciate that practical advantage.

Zamicol 8y ago

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.

stinos 8y ago
I too admit liking JSON for it's simple yet extremely useful in a whole lot of usecases, but calling it near perfect is a maybe bridge too far. Officially it doesn't have a representation for nan or infinity, otherwise perfectly valid floating point numbers.
gaius 8y ago
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.
- majewsky 8y ago
  > 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.
- Mikhail_Edoshin 8y ago
  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.

blauditore 8y ago

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

taeric 8y ago
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 wanting something different. JSON was born as much for basically being javascript literals minus functions as it was anything else. Most any other explanation is just someone selling you something. (Now, attributes did offer a technical way to ignore subsets of the attributes that would be hard to do any other way. But they didn't exactly make it easy, and namespaces did not compose nearly as well as people hoped they would.)
- tannhaeuser 8y ago
  JSON was just a quick shot by Douglas Crockford. No need to spin a genesis myth around it.
  - taeric 8y ago
    I don't know what genesis myth you mean. I do know that I was regularly serializing JavaScript literals for years before I heard of json. Basically just said I could no longer serialize functions. Or references. Which, to be fair, was not that common and I could easily live without. I do miss being able to have comments.
tannhaeuser 8y ago
It's funny how people often compare JSON and XML, but fail to see that XML/SGML is for document data (like whole web pages) whereas JSON is a clever reuse of JavaScript object literal syntax.

pingec 8y ago

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 such a pain to maintain, would be nice to have a tool that could translate xml schema to json schema and back.

lwansbrough 8y ago
I’ll pass on any serialization format that is itself vulnerable to RCE.
- eridius 8y ago
  You can easily create a parser with RCE using just JSON. Just define a simple schema that looks like { "type": "ObjectName", … } The only difference between this and e.g. YAML is YAML has specific syntax for declaring the object type whereas with JSON you need to declare it yourself.
senozhatsky 8y ago
> 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 https://github.com/stleary/JSON-java -ss
- bouke 8y ago
  I think parent was talking about the document definition (schema) instead. So not to rely on the document instance for the translation definition.
  - senozhatsky 8y ago

ToFab123 8y ago

So, when do we get a typescript for JSON? You mean a schema like XML has? It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.

ubernostrum 8y ago
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 never replace that, because JSON was so underspecified and unsafe. You could maybe get away with it for a couple requests to your puny baby child's "Fisher-Price My First Webservice" toy program, but JSON would instantly and completely fall over the instant any real-world problem presented itself. Yet here we are all those years later, in a world which largely runs on JSON as a data interchange format. Or, more concisely, as I wrote in 2006 in response to the Dave Winer piece someone else linked in another comment: And now here are these kids with their startup companies and their weblogs who are getting data exchange and even things that kind of look like APIs out of… JavaScript arrays? The XML guys are sitting up on the mountaintop like the Grinch, with his pile of stolen presents, wondering how Christmas still managed to happen: it came without specs! It came without hype! It came without angle brackets, envelopes or types!
- hguhghuff 8y ago
  There’s passion for you.
- donmatito 8y ago
  Or, "worse is better"
  - majewsky 8y ago
    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".

hguhghuff 8y ago

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.

wetpaws 8y ago
It's exactly as good as it needs to be. Trying to 'improve' JSON will turn it into xml again.
- tlocke 8y ago
  Surely it's a problem that in JSON, duplicate keys are allowed? https://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object https://stackoverflow.com/questions/21832701/does-json-synta...
tlocke 8y ago
Have you seen Zish? https://github.com/tlocke/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.

asavinov 8y ago

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 very typical example which is more than an anti-pattern: <books> <book id="1"><title>XML is evil</title></book> <book id="2"><title>XML considered harmful</title></book> </books> Here we see that semantically <books> is a collection while <book> is a tuple (where <title> is an attribute). Yet, they use one and the same structural construct. XML does not enforce the dual semantics of sets and tuples, and therefore XML files are frequently a conceptual mess. The above example is essentially wrong but XML does not care.

WorkLifeBalance 8y ago
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 expensive bugs in production, but in the real world the ability to mostly ignore types lets people get things done in a more hackish / amatuer way which eases the learning curve and helps popularity.
- zaarn 8y ago
  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.
  - tannhaeuser 8y ago
    No. JSON-LD aims at aiding interpretation of JSON as RDF data (semantic web, description logic). It's terrible IMHO.

lkuty 8y ago

XHTML is still alive as the section 13 "The XML syntax" in the "HTML Living Standard" shows us. Moreover XML comes with a host of useful technologies : schemas, XSLT, XQuery and namespaces. It is quite complex compared to JSON but more powerful when you consider the whole ecosystem. In the end, it depends on the need we have. Quick, small, simple XML is possible and easy.

cool-RR 8y ago

"JSON’s dominance is surprising when you consider that as recently as 2005 the web world was salivating over the potential of “Asynchronous JavaScript and XML” and not “Asynchronous JavaScript and JSON.”" "As recently as 2005," heh. In the frontend world, you might as well say "as recently as the Paleolithic age."

nebulous1 8y ago

I think the the only people who could be confused as to the reason for the rise of JSON are people who have never used XML

niftich 8y ago

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.

zde 8y ago

A message format that requires parser to understand both UTF8 and UTF16, cool!

pitaj 8y ago
Unsurprisingly, one of the most common data types is text strings, so most serializations need that anyways.

vertere 8y ago

> 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 https://youtu.be/-C-JoyNuQJs?t=730

sametmax 8y ago
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.

another-cuppa 8y ago

> only one API exposes data in XML rather than JSON They are not mutually exclusive. It should be trivial to offer the data as either JSON or XML at the user's request.

amaccuish 8y ago

I feel like the best takeaway here is that XML is a document format, and JSON is for programmatic interchange, e.g. APIs. That's at least how I operate, and I use both XML and JSON for various things. My APIs are all JSON, but if I'm serialising some data to disk, or for export etc, it's usually XML.

ktpsns 8y ago

One aspect about JSON is the lack of comments. This makes it mostly unsuitable as a configuration language and in fact simple "JSON for humans" such as https://hjson.org/ https://hjson.org/ and https://json5.org/ https://json5.org/ exist. In my opinion, this is a design flaw and if JSON would be a bit more human-oriented, it could be much more widespread in non-web contexts.

fenwick67 8y ago
I actually like that JSON has no comments. With comments in a data transmission format you will end up with things like "conditional comments" in IE. I agree there are certainly many better configuration languages.
- ktpsns 8y ago
  I agree, but you can do context switchs also without having comments. For instance, the JSON Schema defines (Source: https://json-schema.org/latest/json-schema-core.html#rfc.section.9 https://json-schema.org/latest/json-schema-core.html#rfc.sec...) { '$comment': "string that can hold whatever you want" } and it is obvious that you can embed any other language in a string.
rurban 8y ago
It is not design flaw, it was a conscious decision to enhance security. JSON is still the only secure (and fast) generic transport protocol, all others but msgpack are insecure by design. The various attempts to "enhance" json with types, datetime, comments, ... just make it worse, don't fall into that trap. The latest JSON changes also made it more insecure, while they didn't clarify the missing spec points, so even they fell into that trap. msgpack is more also a bit insecure than JSON, but not as dramatic as XML, YAML, BSON, ...

DonHopkins 8y ago

>Though one might think that a contest between data interchange formats would be unlikely to engender death threats, Winer wrote: >"No doubt I can write a routine to parse [JSON], but look at how deep they went to re-invent, XML itself wasn’t good enough for them, for some reason (I’d love to hear the reason). Who did this travesty? Let’s find a tree and string them up. Now." In retrospect, he should have said: "Let's find a tree and stringify it."

cpr 8y ago

Not: as groundbreaking as Scribe (Brian Reid at CMU) was, I don’t think SGML was inspired by it. They had parallel dev paths...