News for hackers. Stuff that matters.
Re:JSON as configuration files: please don’t (2016) by Thiez on Saturday April 13, 2019 @02:22PM (#19654759)
How does it suck harder? Sure, the closing tags can be a bit annoying (but decent editors can insert those automatically), but attributes don't have that problem, and contrary to JSON it has comments.
Re:JSON as configuration files: please don’t (2016) by revvx on Saturday April 13, 2019 @02:51PM (#19654980)
Closing tags is not really an issue with XML.

In my experience, the biggest reason people hate it is because it has too many ways of structuring data, and it allows people who design the schemas to go overboard. Attributes or child nodes? Multiple namespaces or just extend the one you have? CDATA or embedding?

That said, simple XML is as good as simple JSON. XML is fine if you keep it simple when designing the schema. AND of course one can screw up with JSON too. But after almost 20 years of people over-engineering their XML schemas, I can't fault anyone for choosing a simpler data format.

Re:JSON as configuration files: please don’t (2016) by jandrese on Saturday April 13, 2019 @05:17PM (#19655798)
The big difference is that mapping that XML into native data structures in your language is a mess in the general case because XML has so damn many ways of structuring the data. JSON maps more or less directly into JavaScript/Python/Perl or really any untyped language with arrays, hashes, and scalars.
Re:JSON as configuration files: please don’t (2016) by michaelmior on Saturday April 13, 2019 @03:17PM (#19655158)
Personally, the main reason I don't like XML is that it's too verbose.
Re:JSON as configuration files: please don’t (2016) by torbjorn on Saturday April 13, 2019 @02:59PM (#19655037)
I think part of it is the context that JSON and XML are used in, particularly the era of software that uses these formats for configuration and the design implications that has.

Recently I've had to work with XML config files for a tool called Oozie, which is a data pipeline scheduling tool within the hadoop/spark ecosystem, and it has been soul crushingly tedious for me. Everything feels verbose and opaque, the documentation seems to prioritize enumerating every possible configuration option over providing minimum viable configs for common use cases.

JSON configs often just feel more simple and developer friendly. I'd say this has less to do with technical differences between JSON and XML and more to do with how "modern" software systems have been designed to be more ergonomic for developers/administrators and these modern systems happen to be more likely to use JSON.

It's also fun to hear non-technical people at work talk about "Jason files".

Re:JSON as configuration files: please don’t (2016) by koolba on Saturday April 13, 2019 @03:13PM (#19655127)
> It's also fun to hear non-technical people at work talk about "Jason files".

Ha! That one always makes me smile. One of the best exchanges I’ve heard was something like:

“... and we’ll have JSON handle all the serialization”

“Jason? Oh we hired a new engineer?”

Re:JSON as configuration files: please don’t (2016) by eismcc on Saturday April 13, 2019 @03:38PM (#19655286)
This is a great point: correlation between tool and era/ergonomics. My current role is swimming in XML and abides in the XML era design philosophies.
Re:JSON as configuration files: please don’t (2016) by TeMPOraL on Saturday April 13, 2019 @04:04PM (#19655423)
> It's also fun to hear non-technical people at work talk about "Jason files".

I usually go the other way; Jasons I know have their names represented as "JSON" in my mind, and sometimes in written form.

Re:JSON as configuration files: please don’t (2016) by vturner on Saturday April 13, 2019 @05:03PM (#19655710)
There's a flip side to the common use case of documentation... How do you solve the uncommon use case when all the docs it seems are showing "how easy it is to do xyz." A month ago, I started on a new web front end. It was set up with React, Redux and webpack. Since it was primarily going to be me solo on the project, I wanted to integrate TypeScript. There are tutorials everywhere for starting with TypeScript but good luck finding something to say how to integrate it in.
Re:JSON as configuration files: please don’t (2016) by neogodless on Saturday April 13, 2019 @03:36PM (#19655269)
You might be able to guess my name by my comment.

I really wish everyone would think of JSON as a French word. "Jay-sonne" (or jay-SAWN). Not "Jase-in"... it would help keep the confusion to a minimum.

Ha - https://www.youtube.com/watch?v=zhVdWQWKRqM He starts by saying "Jason" but then suggests the French version. Love it!

Re:JSON as configuration files: please don’t (2016) by thechao on Saturday April 13, 2019 @02:35PM (#19654850)
I find it interesting you're being downvoted. I think your question is reasonable: why does XML suck "harder" than JSON? This just seems a bit faddish to me. Things like namespaces and attribute/child distinction in XML are super annoying ... until you really need them in your ML (JSON, in this case). Then, suddenly, you're reinventing a wheel, hoping all of your downstream tools 'agree' on the behavior.
Re:JSON as configuration files: please don’t (2016) by Thiez on Saturday April 13, 2019 @02:49PM (#19654962)
The votes seem to be going the other way now :-)

I've heard people prefer JSON over XML because XML is too complex... and now we have json schemas, jsonpath... the namespaces can't be far away.

I'll admit that XML probably would be better without entities and the crazy whitespace handling.

Re:JSON as configuration files: please don’t (2016) by joezydeco on Saturday April 13, 2019 @06:02PM (#19656020)
Why does it suck harder? I’ll give one example: arrays.

In JSON they’re plain and simple. You even get to use good ‘ol [ ] delimiters.

In XML? It’s a sea of open and close tags.

Now do an array of arrays. Then hand-edit it.

Like I said, it’s no better. But it’s way easier to read.

Re:JSON as configuration files: please don’t (2016) by tuesdayrain on Saturday April 13, 2019 @04:26PM (#19655517)
I can easily import/export the JSON and share it within my codebase. The XML is much worse in that regard (unless there's some clean way to do the same thing that I'm not aware of).