Live data from Hacker News

JSON vs. XML

corecursive.com

61–70 of 252 posts

Re: JSON vs. XML

#61
post #56

Earlier quoted context omitted.

I just had to comment on the irony of this comment being embedded in a document that is delivered via HTTP and very close to valid XML. Even if XHTML died on the wayside, HTML is imho a stereotypical example where XML is a good fit. Most of the complexity has valid use cases, and it's mostly obvious what should be an attribute and what should be content of the tag. And at least in HTML 4 you even had a doctype tag fi…

In broad strokes, I suppose you're right to see the irony. Even with that, we need specific client applications (aka browsers) to translate that into something readable.

(X)HTML can be pretty readable, if it's formatted well. If it wasn't, JSX wouldn't be a thing.

I think it's not so much about readability but about complexity. XML is meant to represent complex data, like complex rich text or nested vector graphics. That makes XML complex, conceptually, visually, and in implementation. If you use it to represent something that could have been a csv you're going to have a bad time (as everyone had in the 90s).

Re: JSON vs. XML

#62

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.

What I appreciate compared to xml is: - generic concepts like arrays and maps - lack of opportunity to invent names Every xml schema is a potential DSL that reinvents things they might now. Other than that it's true that the xml era was just addressing a lot of important stuff early, I guess it was only compatible with big corp mindset and not early web dynamic / fluid / small scale apps. (a bit like how PHP started…

Every JSON schema is also a potential DSL that reinvents everything. Yes, there seems to be some convergence on things, but object arrays in XML aren’t really any more complex than object arrays in JSON — there just might be multiple ways to represent them.

For this JSON:

    {
      "part_numbers": [1, 2, 3, 4, 5]
    }
You have two main ways to represent these in XML:

    
    
      1
      2
      3
      4
      5
    

    
    
      
        1
        2
        3
        4
        5
      
    
Is this better than JSON? No, not particularly. But it’s no less clear than the JSON, and it compresses pretty well (it compresses better for larger documents, obviously).

The larger problem with XML is that the tooling is often lacking outside of Java and C#/.NET and none of the tooling is well-built for the sort of streaming manipulation that `jq` does (it exists, but IMO one of the least usable ideas from the XML camp is XSLT), and JSON support is pretty universal everywhere, even if the advanced things like JSONpath and JSON Schema aren’t.

I also think that there’s a problem when you have to choose between SAX and DOM parsing early in your process. Most JSON usage is the equivalent of using a DOM parser because the objects are expected to be relatively small, but many XML systems are built for much larger documents, and therefore need to parse the stream because the memory use otherwise would be unacceptable. The use of a JSON streaming parser is much rarer, IME.

Re: JSON vs. XML

#63

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.

With XML, the complexity is the baseline, and it only goes up from there. With JSON, the complexity is just an option, the baseline is pretty simple. Also, good XML-tools are rare or expensive.

Here to say this too. Compositional complexity is an advantage.

As a human in a repl, I appreciate the balance of readibility between XML which uses a larger set of syntactical characters, and YAML which uses fewer.

I also appreciate JSON's ontological simplicity over XML. This primarily boils down to the lack of attribute nodes and explicit difference between objects (lists of key-values) and arrays (lists of values).

Re: JSON vs. XML

#64
post #5

Earlier quoted context omitted.

I really respect that you provide transcripts. It's terribly important for accessibility and for getting what people have said into the various search engines. I was sad to hear that Crockford is not aiming to be the author of "the next language" anymore, but I wonder how sincere that really is. His thoughts on actor-based languages are interesting.

Thanks! Crockford's thoughts on actors are really interesting. I tried to pull them apart but I didn't get very far and ended up not including them in the episode. What he is envisioning is not exactly like Erlang but not exactly like Scheme. He said that Carl Hewitt had a lot of ideas and they were hard to unpack. If you're interested though, I would reach out to him. He is very approachable and excited to talk to p…

I do wish some more details about his current thoughts on actors had been included, though I can understand if they were hard to tease out. I would guess that may go back to his work on Electric Communities as E was a message passing system. Would be interested in hearing more of where his mind is on actors today.

The closest thing we have right now I think is Spritely Goblins, though that is Scheme. (Not coincidentally, one of the other Electric Communities co-founders is also a Spritely Institute co-founder: https://spritely.institute/about/)

Re: JSON vs. XML

#65
post #29
post #16

Earlier quoted context omitted.

> I started my career during peak XML crazy and while I liked parts of it at the time, the number of things it was used for was quite insane. I had to maintain a system once where a major part of it was XSLT, when could have just been a simple imperative algo with some config settings. Same here. XML was going to save the world! Remember XML data islands with data embedded in page source and displayed via XSLT? The c…

I remember the XML is everywhere phase. The community that hasn't retired or passed on has largely come off of that. You can return JSON natively from XSLT 3.0 now. I've been on both sides of the love/hate fence with XML, but these days when I have the need to work with it I leave the projects really satisfied.

The best part of the XML craze was the deprecation of proprietary binary file formats. I had to work with some software that was truly awful but since it saved it's data as XML,I could skip the software entirely and work directly with the data.

Re: JSON vs. XML

#66
post #9

This quote is funny: Douglas: The first time I saw JavaScript when it was first announced in 1995, I thought it was the stupidest thing I’d ever seen. And partly why I thought that was because they were lying about what it was. A bigger more interesting thing though is how his company failed, in part, because they used hand-rolled JSON for messaging. Douglas: And some of our customers were confused and said, “Well, w…

I remember a meeting where a consultant from an MCP excitedly told our mutual client that the XP in the upcoming version of Windows stood for 'XML Protocol.' More innocent times.

I had a power strip which had "works with windows 95" on the packaging box.

Re: JSON vs. XML

#67
post #26

I have huge respect for Doug Crockford, and I never imagined I would disagree with him. However I think by now we've seen that a lot of that "unnecessary" XML complexity was not, in fact, entirely unnecessary. These days we use JSON for everything, but now we've got JSON Schema, Swagger/OpenAPI, Zod, etc etc. It's not really simpler and there's a lot of manual work - we might as well be using XML, XSD & SOAP/WSDL.

JSON is great, but I surely wish it supported comments. That's the nature of its failings: too minimal.

Comments are simple to parse, but preserving them on the dump is complex. I guess they were sacrificed for the simplicity.

Re: JSON vs. XML

#69
post #41

Namespaces, schemas, custom elements, client side templating, XML has so much stuff that the web threw away, so now its forced to reinvent worse versions of it every few years, a shame. Abandoning XML was the webs biggest mistake.

XML is oversized for the majority use case.

It's easier to extend a simple standard than to amputate a behemoth with unneeded appendages.

Re: JSON vs. XML

#70
I remember one time designing the simplest and most readable data format ever and came up with Dixy [0] after removing all I could and still make it usable

I'm leaving it here because it will never be used for anything but at least it may inspire somebody design a better format with simplicity in mind

[0] https://github.com/kuyawa/Dixy

Post reply on HN