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

131–140 of 252 posts

Re: JSON vs. XML

#131

Post by Joker_vD »

recursive wrote: post #86
dylan604 wrote: post #78

Earlier quoted context omitted.

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.

Ah yes, "this cereal is asbestos-free!" kind of marketing. It's on the same page with non-GMO salt.

Re: JSON vs. XML

#132

Post by goto11 »

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.

If we are going for simplicity, surely S-expressions wins? You can support structures similar to JSON or XML on top of it, but the baseline is simpler.

Re: JSON vs. XML

#133

Post by dylan604 »

Joker_vD wrote: post #131
recursive wrote: post #86

Earlier quoted context omitted.

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.

Ah yes, "this cereal is asbestos-free !" kind of marketing. It's on the same page with non-GMO salt.

Exactly. It doesn't really matter that the claim is technically true, it just has no bearing whatsoever on the product itself.

Re: JSON vs. XML

#134

Post by tracker1 »

adamgordonbell wrote: post #14
meepmorp wrote: post #9

Earlier quoted context omitted.

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.

Scala had XML literals as part of the language! Apparently Philip Wadler was the person who told them needed it, because the future was XML. ( Walder is big Haskell/PL person)

ActionScript 3 as well as the E4X support in Mozilla's Browser+JS/XUL engine for a while (removed now afaik).

Around that time it was pretty nice passing around XML, as I was forced to work with VB.Net which also had an XML literal syntax on the backend and Flash/AS3 on the UI.

I had built a POC with E4X that was VERY similar to React/Redux over a decade before React, but the other browser vendors didn't have it... At the time IE and Chrome were shifting towards JSON.

Re: JSON vs. XML

#135

Post by taeric »

slaymaker1907 wrote: post #123
taeric wrote: post #57

> Turned out JavaScript was the first language to give us lambdas, and that was an amazing breakthrough. I mean... with charity I can see the context and get it. But. What!? Overall fun read through history, even if definitely from Doug's perspective only. (As evidence by JavaScript being an originator of lambdas...) I do find the idea that JSON was as novel as history says it was kind of odd. I remember inlining jav…

The current XML standard is hot garbage since it completely disallows null characters even via "�" despite most languages now supporting nulls in the middle of strings. Also, JSON definitely allows schemas, primarily through the JSON schema standard, but I've also seen TypeScript notation used for this as well which has the convenience of being readable by more people (I strongly suspect more people know TypeScrip…

JSON is garbage to read largely due to how much needs escaping. This is largely fine for smaller documents, but there is a reason yaml and toml both gained traction over raw json for config files.

And I don't make any real defense of some of the darker corners of XML. In particular, I already criticized entities being a bit too much. Namespaces are also something that, while I can see the desire, the implementation is way too much for most of us.

JSON schema is going to be cursed for a long time. Just the odd treatment of it will be a problem. (In particular, that it is a subset of the numbers that javascript itself supports is... awkward.)

I also confess, though; that I'm not clear why I would want a null in the middle of a string? That feels like a gun loaded and aimed squarely at a foot.

Re: JSON vs. XML

#136

Post by tracker1 »

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.

Honestly, if you just need a one-off transformer, VB.Net is probably one of the better options. The .Net XML library is pretty good in the box, and VB.Net has XML literal support on the top... if you just need to read, then C# is a better language imo.

Re: JSON vs. XML

#137

Post by orthoxerox »

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.

If your XML is written the way people write JSON, then the stack isn't enormous. But XML is usually wrapped in layers of additional complexity. SOAP envelopes and namespaces they require, XSLT that someone invariably used to write an XML transformer, etc.

Re: JSON vs. XML

#138

Post by taeric »

radicalbyte wrote: post #76
taeric wrote: post #55

Earlier quoted context omitted.

Adding to the problems of generated schemas, Microsoft and Sun both had different views on how they should be generated. I bought into the promise of "build a wsdl" and you can get clients from .NET and Java. I lost all of that buy in. Hard. I don't know that I can lay the blame on either one of them directly, mind. But the industry definitely suffered from the bad faith cooperation of those companies.

Microsoft, Sun, IBM, HP, Oracle et al explicitly made WDSL and related technologies not interoperate... and that is where JSON + universe has been a delight.

Totally fair. Not sure why I limited my memory to just the two companies.

I'm not clear on how JSON as a format has helped interaction. I'm reminded of like efforts to standardize how information is stored on pages. By and large, that ship sailed and sites that have remained somewhat stable have driven how we look for information on them. All without having to add new schema languages or tools.

Re: JSON vs. XML

#139

Post by tracker1 »

wil421 wrote: post #30
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 dislike SOAP and avoid working with it when I can. However, the WSDL is an excellent part of SOAP that really makes it easier to work with. Teams tended to over engineer their APIs and all kinds of cruft would develop. I like the HTTP operations with REST. I can remember hardcoding and manipulating a bunch of non-sense legacy fields just to get a ticket created via their SOAP enterprise service bus. Not to mention…

Unless the implementation defines too many things as just "Object" and you're consuming from a stronger typed language... and the generated library doesn't give you anything resembling a real interface. I've used a dynamic language (Node) a few times to bridge such wsdl/soap services to consume from C# and similar.

Consuming SOAP/WSDL from languages other than the one it's published in isn't fun. Man, some of the PHP implementations were beyond horrible... well defined REST/RPC +_JSON is generally much easier in the end.

Re: JSON vs. XML

#140

Post by tracker1 »

wil421 wrote: post #30
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 dislike SOAP and avoid working with it when I can. However, the WSDL is an excellent part of SOAP that really makes it easier to work with. Teams tended to over engineer their APIs and all kinds of cruft would develop. I like the HTTP operations with REST. I can remember hardcoding and manipulating a bunch of non-sense legacy fields just to get a ticket created via their SOAP enterprise service bus. Not to mention…

> I dislike SOAP and avoid working with it when I can.

Well, I'm about to take a shower now, and shame on you.

Post reply on HN