Live data from Hacker News

JSON vs. XML

corecursive.com

101–110 of 252 posts

Re: JSON vs. XML

#101
I bought one of the first books about XML, read it cover to cover; started writing my own parsers and generators, designed a custom XML protocol for a network server at work.

Then I had to live through the whole SOAP-drama, and Java EE; and ended up promising myself to never touch it again.

It has too many degrees of freedom for its own good, the C++ of data formats.

JSON is in many ways the other end of the spectrum; simple but underspecified and painful to deal with in anything but JS.

I often dream of something in-between.

Re: JSON vs. XML

#102
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.

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

Did it work with 98?

Re: JSON vs. XML

#103
post #99

Earlier quoted context omitted.

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 particu…

Where XML shines is when you pass more complex data types than numbers and strings. If you repeated your example for an array of dates, as an example, strictly speaking you can't even generate the JSON. We'd first have to agree on what string representation of a date we want to use. For XML it's built into the spec.

Okay, so the point at which you need to adopt a schema language in toy examples is earlier with JSON, but in most practical cases you’ll want to do that in either JSON or XML (because, even if you are only using built-in types, you’ll still want to communicate the shape), so this objection is kind of meaningless.

Re: JSON vs. XML

#104
post #90

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…

JavaScript is as good as JSON. It has eaten The world jest because it was in every browser. Similarly Chrome, advertised on the biggest search engine.

Re: JSON vs. XML

#105
post #90

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…

I would describe it something like: XML is great as a document format, but shitty as an RPC format. JSON is vice-versa. Web developers spend a lot of time with JSON as an RPC format, so they tend to put it on a pedestal. But try keeping your recipe collection structured in JSON text files and the pain will start immediately. YAML is even worse.

XSLT was (and still is) great for transforming documents. Want that recipe collection as HTML? Easy.

Re: JSON vs. XML

#106
Doug says there's not a conservation of complexity, but I kind of disagree with that - the problem he was getting hung up on back in 2000 was that the original XML complexity was frickin' useless but the consultants and the capital were trying to keep it around anyway. If you don't know why a complex condition exists, you can't abstract the complexity away.

Re: JSON vs. XML

#107

What if I hate both formats? XML is overly verbose, while JSON isn't specific enough or precise enough for a lot of my needs. - This message brought to you by TOML gang

I just checked out the spec, and it gets pretty ugly in the Table section. A lot of the json examples are both shorter and IMO more precise. Stuff that’s not allowed with [table] is allowed with [[table]], and it’s confusing to understand what level of depth I’m at.

I’ll take edn over any of “em. https://github.com/edn-format/edn

Comments and time stamps allowed, arbitrary nesting of data structures, make your own tagged literals if you need them. And commas are whitespace, mostly unnecessary.

Re: JSON vs. XML

#108
> And after years of being too early at everything, the world had caught up to Doug.

Have we though? Earlier, the article even has Douglas saying:

> It turns out it, well, it’s a multi paradigm language, but the important paradigm that it had was functional. We still haven’t, as an industry, caught up to functional programming yet. We’re slowly approaching it, but there is a lot of value there that we haven’t picked up yet.

I do love the very ending:

Adam: What do you think is the XML of today?

Douglas: I don’t know. It’s probably the JavaScript frameworks.

They have gotten so big and so weird. People seem to love them. I don’t understand why.

For a long time I was a big advocate of using some kind of JavaScript library, because the browsers were so unreliable, and the web interfaces were so incompetent, and make someone else do that work for you. But since then, the browsers have actually gotten pretty good. The web standards thing have finally worked, and the web API is stable pretty much. Some of it’s still pretty stupid, but it works and it’s reliable.

And so, when I’m writing interactive stuff in browsers now, I’m just using plain old JavaScript. I’m not using any kind of library, and it’s working for me.

And I think it could work for everybody.

------

Earlier in the interview where they were talking about how people behind XML and SOAP wanted complexity and were upset by the simplicity of JSON, I was thinking that this was resonating with me and how I feel about how complex web development has become with babel/webpack, transpiling, react/vue, etc. It feels like complexity for complexities sake.

Re: JSON vs. XML

#110

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.

The last time I worked with XML, using an external library wasn't really a great option. I ended up writing my own parser in C++. It took about a week to get all the features required for my purpose.
Post reply on HN