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

JSON vs. XML

corecursive.com

Post reply on HN
Print view View original

81–90 of 252 posts

Re: JSON vs. XML

#81

Post by bryik »

Seanny123 wrote: post #48
adamgordonbell wrote: post #3

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…

What are some examples of the "enormous tool stack" required for XML? I ask, because I came into software development after everyone adopted JSON. When I do need to parse XML, there was a library I could use, although I will admit that needing xpath was a bit annoying.

This was before my time, but I believe the WS-* series of specifications is an example.

> Like with the original J2EE spec, which sought to complicate the basic mechanics of connecting databases via HTML to the internet, this new avalanche of specifications under the WS-* umbrella sought to complicate the basic mechanics of making applications talk to each other over the internet. With such riveting names as WS-SecurityPolicy, WS-Trust, WS-Federation, WS-SecureConversation, and on and on ad nauseam, this monstrosity of complexity mushroomed into a cloud of impenetrable specifications in no time. All seemingly written by and for the same holders of those advanced degrees in enterprisey gibberish.

https://world.hey.com/dhh/they-re-rebuilding-the-death-star-...

Re: JSON vs. XML

#82

Post by giantrobot »

Devasta wrote: 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.

Whenever XML gets discussed here it's interesting to see what people complain about. In my completely unscientific assessment most things people hate(d) were the overwrought "Enterprise" uses/systems.

Very unfortunately for everyone XML came up at the same time as peak "Enterprise" moat building. No design pattern went unused everything was built with mind numbing "configuration". XML got used heavily in that space because it allowed massive "Enterprise Objects" (local branding varies) to be serialized in a way another system might have a chance to read.

Meanwhile the features you mention got thrown out with the bath water because everyone hated Enterprise style architectures. While I don't love, for instance, everything about XSLT it's built directly into browsers as native code. How many person hours, megabytes of JavaScript, and wasted CPU cycles have been spent reinventing client side templating using JSON? XSLT is already right there and will happily convert serialized data to your presentation format. You also get the ability to have comments in the data and a built in schema validation.

On my current project I'd much weather be emitting and consuming XML rather than JSON. But alas everyone hated Enterprise XML so we're stuck with JSON and the inability of some parsers to handle trailing commas and ambiguous definitions of numerics and not a comment to be found.

Re: JSON vs. XML

#83

Post by dylan604 »

sanitycheck wrote: post #18

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.

I have to say that I was bit disappointed the first time I learned about JSON Schema. My immediate reaction was to wonder if they were trying to become XML.

Re: JSON vs. XML

#84

Post by andyjohnson0 »

PurpleRamen wrote: post #44
sanitycheck wrote: post #18

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.

Baseline for XML would be a document that doesn't use schemas, namespaces, attributes, or any of the SGML legacy stuff like DTDs and PCDATA.

Such a document is essentially as simple as the equivalent JSON.

Re: JSON vs. XML

#85

Post by pointlessone »

PurpleRamen wrote: post #44
sanitycheck wrote: post #18

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.

I guess, it depends on how you define XML baseline. You can have a very simple XML with only bare tags. It will work just fine. Arguably, it's even simpler than JSON that way. A basic parser for that it probably not more complex than a JSON parser.

All the optional complexity that can go on top, though, is probably better specified for XML. Transformation is well defined for XML (XSLT) but not at all for JSON (I guess, you write your own code to manipulate native objects).

Schemas are basically a native feature for XML. Not so much for JSON.

All sorts of specialised vocabularies are defined for XML. A few are defined for JSON, too.

Re: JSON vs. XML

#86

Post by recursive »

dylan604 wrote: post #78
lowercased wrote: post #66

Earlier quoted context omitted.

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

This is just an example of how marketing knows nothing about the products they are marketing, or are just flat out snake oil sales. Like packaging for bacon exclaiming "gluten free"

I mean... but it is? They're not wrong. Either the marketing works or it doesn't, but it's not false. If it works, then it's good marketing. If it doesn't, then the marketers don't know their market.

Re: JSON vs. XML

#87

Post by Marazan »

PurpleRamen wrote: post #67
adamc wrote: post #26

Earlier quoted context omitted.

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.

They were excluded so people wouldn't use them to insert meta-processing instructions into the JSON doc.

In reality people insert those meta-processing instructions in other ways.

Re: JSON vs. XML

#88

Post by hiccuphippo »

Ygg2 wrote: post #34
dvh wrote: post #15

For me 3 killer features of JSON are: 1. Parsing JSON doesn't require adding new firewall rules 2. There are no comments, so nobody will try to invent their own meta format or annotations in comments and instead they will put data in the JSON as they should 3. (When compared to JS) someone finally had the balls and picked one type of quotes, this makes making parser so much simpler.

> There are no comments, so nobody will try to invent their own meta format or annotations in comments and instead they will put data in the JSON as they should It also means it's worse format for configs where you sometimes need to annotate a few nodes with comments.

For configuration files I add an extra key "_" and a string with the comment as the value. I even add multiple "_" keys to the same object and never seen something break.

Re: JSON vs. XML

#89

Post by recursive »

Zamicol wrote: post #69
Devasta wrote: 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.

The problem with extending a standard is that there are so many ways to do it.

Re: JSON vs. XML

#90

Post by bambax »

adamgordonbell wrote: post #3

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 had to maintain a system once where a major part of it was XSLT

Every time the topic comes up I feel the need to say that I loved XSLT. It was so nice. XML frankly was kind of simple, too. It had elements and attributes and that was it. And it had xpath, which offered, among other things, a parent axis, so you could walk the node tree upwards.

In JSON you can't get to the parent from the child. And walking down a tree is unintuitive, because nodes can be of different types, and if you want to maintain the order, or use successive instances of the same things (that would have the same name) you need to use arrays, and arrays of arrays of arrays look bad. Schemas are an afterthought.

JavaScript is cool -- it has mostly eaten the world anyway. But JSON is not so good IMHO.

Post reply on HN