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

151–160 of 252 posts

Re: JSON vs. XML

#151

Post by chrismorgan »

bambax wrote: post #90
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…

I first touched XSLT in 2010. I appreciated what it could do, but it was painful to work with due to poor documentation and tooling. This has only gotten worse by comparison with alternatives.

You can still do XSLT in the browser. You can serve arbitrary XML and transform it. As an example, Atom feeds on my website (such as https://chrismorgan.info/blog/tags/meta/feed.xml>) render just fine in all mainstream browsers, thanks to this processing instruction at the start of the file:
But working with it is not particularly fun, because XML support in browsers has been only minimally maintained for the last twenty or so years. Error handling is atrocious (e.g. largely not giving you any stack trace or equivalent, or emitting errors only to stdout), documentation is lousy, some features you’d have expected from what the specs say are simply unsupported (and not consistently across engines), and there are behavioural bugs all over the place, e.g. in Firefox loading any of my feeds that also fetch resources from other origins will occasionally just hang, and you’ll have to reload the page to get it to render; and if you reload the page, you’ll have to close and reopen the dev tools for them to continue working.

Re: JSON vs. XML

#152

Post by mastax »

goto11 wrote: post #132
PurpleRamen wrote: post #44

Earlier quoted context omitted.

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.

The new KiCad file formats are all S-expression based[0], except for the project files which are JSON IIRC. I think it works pretty well for representing a tree of typed objects textually. They don't even have any LISP connections. Haven't seen S-expressions used anywhere else, though.

[0]: https://dev-docs.kicad.org/en/file-formats/sexpr-intro/

Re: JSON vs. XML

#153

Post by acabal »

While both are good fits for their specific use cases, I think JSON won as an medium of exchange because unlike XML, JSON is dead simple to parse and ingest programmatically.

What makes XML so unergonomic to ingest is 1) attributes, which don't map cleanly to a basic data structure that you might find in a programming language, and 2) namespaces, which are extremely, extremely tedious to program against.

Programmers are going to use the format that's the easiest to ingest and manipulate. JSON wins in that regard, hands down. Every time I need to write logic to ingest a namespaced XML document I heave a deep sigh and brace myself for another long week of fighting with LXML. But with JSON it's as easy as `json_decode($str)` and move on with your life.

Re: JSON vs. XML

#154

Post by Kwpolska »

tracker1 wrote: post #136
Seanny123 wrote: post #48

Earlier quoted context omitted.

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.

VB.NET is masochism, and XML literals are a dumb, confusing, and unnecessary feature. Creating XML elements with regular code is quite easy, and at scale, you probably want templates.

Re: JSON vs. XML

#155

Post by twoodfin »

goto11 wrote: post #132
PurpleRamen wrote: post #44

Earlier quoted context omitted.

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.

I’d speculate that human minds and memories work much better with associative structures rather than sequenced ones. JSON draws a clean separation between these two and as a result has clearer syntax for the former.

ie, the benefits of simplicity have a limit.

Re: JSON vs. XML

#156

Post by preseinger »

taeric wrote: post #146
hot_gril wrote: post #142

Earlier quoted context omitted.

Every key is written twice, for opening and closing. Keys can be duplicated, and in fact that's what you have to do if you want a simple list. There aren't numeric types, so you have to parse strings. It also looks horrible. Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 or Led Zeppelin II Led Zeppelin 999 La Brise Arax 999 vs something like [ {"title": "Led Zeppelin II", "artist": "Led Zeppelin", "price": 999},…

If we are complaining about the closing tags, might as well add that embedding newlines or quotes into JSON is less than pleasant. Which is to say, this feels a touch of a non-issue. Yes, writing it by hand can get tedious, but that is true of any and every format. Is why you will almost certainly reach for other formats if doing a long list of data. And each and every one of them will fail for some form of input in…

you can't ignore ux stuff like this in a protocol that's meant for general use

something like duplicating info in closing tags in XML (which applies to every element) isn't really comparable to stuff like having to escape certain characters in JSON strings (which applies only to the values use those things)

perfect is the enemy of the good, and the good is the metric

Re: JSON vs. XML

#157

Post by hot_gril »

preseinger wrote: post #156
taeric wrote: post #146

Earlier quoted context omitted.

If we are complaining about the closing tags, might as well add that embedding newlines or quotes into JSON is less than pleasant. Which is to say, this feels a touch of a non-issue. Yes, writing it by hand can get tedious, but that is true of any and every format. Is why you will almost certainly reach for other formats if doing a long list of data. And each and every one of them will fail for some form of input in…

you can't ignore ux stuff like this in a protocol that's meant for general use something like duplicating info in closing tags in XML (which applies to every element) isn't really comparable to stuff like having to escape certain characters in JSON strings (which applies only to the values use those things) perfect is the enemy of the good, and the good is the metric

Don't you also have to escape stuff in XML? Like &gt, which is even worse.

Re: JSON vs. XML

#158

Post by duffyjp »

Kuyawa wrote: post #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

I like this! It's like YAML but you can learn the entire spec in 15 seconds.

Re: JSON vs. XML

#159

Post by sumtechguy »

bayindirh wrote: post #8
adamgordonbell wrote: post #4

Earlier quoted context omitted.

This is about JSON being created or discovered and Doug struggling to convince people it was relevant when everyone was so bought in on XML. Are you saying you think JSON shouldn't exist and everyone should use XML for everything? Tooling around XML was certainly more established, but man there was a lot of complexity built up around it.

No. JSON is great as Javascript's serialization format, but it's not as readable and robust as XML, period. I use both extensively, and for bigger objects and definitions, XML is a very clear winner. I'm a big believer in horses for courses type of approach, and my personal gripe is the push to replace one thing with another. These data types can coexist, and can be used where they shine. XML can be read and written…

My only quip is both are basically unreadable in most use cases. Most programs worth anything that use these formats usually strip out all the extra spaces and formatting. You usually have to take an extra step to 'reformat' just so you can read it. And anyone who has had an open paren or carrot or missing could show how painful manually parsing a 400+ field one of these is. Trying to say one is better than the other ignores the use cases for both. One being good at slugging data into javascript/python. The other being good at light typing, annotation and transform.
Post reply on HN