4 ms·

So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day (and it doesn't have to be comment-less... JSON with comments is a thing an

by umvi 5y ago

So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day (and it doesn't have to be comment-less... JSON with comments is a thing and VSCode has syntax highlighting for it - just strip out the comments before parsing).

posharma 5y ago
It's simple. For config files, choose the format that has the best tooling in your company and that supports comments. For data transfer, choose that supports schemas, backwards compatibility and good tooling (protobufs is just one e.g. that I'm most familiar with).
stavros 5y ago
> So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day Aren't we past basic false dichotomies?
- saurik 5y ago
  Nope: basic false dichotomies and JSON are both pervasive.
  - a9h74j 5y ago
    There is a corporate- and government-approved standard for false dichotomies, but it works as a de-facto standard, not published.
    - psd1 5y ago
      ifnot: - foo then_clearly: - 'some bar'
deleted 5y ago
[deleted]
zz865 5y ago
XML is perfect. + With all the fancy editors now its very easy to write. Easy schema to check, comments. Perfect.
- nsonha 5y ago
  not easy to read, it's the java of config, pages of code that express very little, by the time you find what you need, you forget the context and what level of nesting you're on already. It's also more wasteful as a transport.
  - KronisLV 5y ago
    > It's also more wasteful as a transport. This is most certainly true, however with GZip thrown into the mix, it's not quite as bad as one might imagine: https://www.codeproject.com/articles/604720/json-vs-xml-some-hard-numbers-about-verbosity https://www.codeproject.com/articles/604720/json-vs-xml-some... It compresses pretty decently and doesn't have too much of an overhead, in the example it being around 10% larger than JSON when compressed. I'd argue that if one were to swap out JSON for XML within all the requests that an average webpage needs for some unholy reason, the overall increase in page size would be much less than that, because huge amounts of modern sites are images, as well as bits of JS that won't be executed but also won't be removed because our tree shaking isn't perfect. Edit: as someone who writes a good deal of Java in their dayjob, i feel like commenting about the verbosity of XML might be unwelcome. I'll only say that in some cases it can be useful to have elements that have been structured and described in verbose ways, especially when you don't have the slightest idea about what API or data you're looking at when seeing it for the first time (the same way how WSDL files for SOAP could provide discoverability). However, it all goes downhill due to everything looking like a nail once you have a hammer - most of the negative connotations with XML in my mind actually come from Java EE et al and how it tried doing dynamic code loading through XML configuration (e.g. web.xml, context.xml, server.xml and bean configuration), which was unpleasant. On an unrelated note, XSD is the one truly redeeming factor of XML, the equivalent of which for JSON took a while to get there (JSON Schema). Similarly, WSDL was a good attempt, whereas for JSON there first was WADL which didn't gain popularity, though at least now OpenAPI seems to have a pretty stable place, even if the tooling will still take a while to get there (e.g. automatically generating method stubs for a web API with a language's HTTP client).
donmcronald 5y ago
For me XML and YAML are about the same. I think I'd also prefer comment-less JSON over both. However, XML wasn't that bad. With a decent editor and schema validation I would say there's a good chance I was more productive with XML than I am with YAML.
mindcrime 5y ago
So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day Sure, why not? XML rocks. I'll take it over JSON for many purposes.
int_19h 5y ago
Actually, yes, I do. XML syntax was far from stellar, and much of the ecosystem (e.g. XML Schema) was drastically overengineered... but even so, we had gems like RELAX NG to compensate. On the whole, it was better than the current mess.

by umvi 5y ago

posharma 5y ago

It's simple. For config files, choose the format that has the best tooling in your company and that supports comments. For data transfer, choose that supports schemas, backwards compatibility and good tooling (protobufs is just one e.g. that I'm most familiar with).

stavros 5y ago

> So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day Aren't we past basic false dichotomies?

saurik 5y ago
Nope: basic false dichotomies and JSON are both pervasive.
- a9h74j 5y ago
  There is a corporate- and government-approved standard for false dichotomies, but it works as a de-facto standard, not published.
  - psd1 5y ago
    ifnot: - foo then_clearly: - 'some bar'

deleted 5y ago

[deleted]

zz865 5y ago

XML is perfect. + With all the fancy editors now its very easy to write. Easy schema to check, comments. Perfect.

nsonha 5y ago
not easy to read, it's the java of config, pages of code that express very little, by the time you find what you need, you forget the context and what level of nesting you're on already. It's also more wasteful as a transport.
- KronisLV 5y ago
  > It's also more wasteful as a transport. This is most certainly true, however with GZip thrown into the mix, it's not quite as bad as one might imagine: https://www.codeproject.com/articles/604720/json-vs-xml-some-hard-numbers-about-verbosity https://www.codeproject.com/articles/604720/json-vs-xml-some... It compresses pretty decently and doesn't have too much of an overhead, in the example it being around 10% larger than JSON when compressed. I'd argue that if one were to swap out JSON for XML within all the requests that an average webpage needs for some unholy reason, the overall increase in page size would be much less than that, because huge amounts of modern sites are images, as well as bits of JS that won't be executed but also won't be removed because our tree shaking isn't perfect. Edit: as someone who writes a good deal of Java in their dayjob, i feel like commenting about the verbosity of XML might be unwelcome. I'll only say that in some cases it can be useful to have elements that have been structured and described in verbose ways, especially when you don't have the slightest idea about what API or data you're looking at when seeing it for the first time (the same way how WSDL files for SOAP could provide discoverability). However, it all goes downhill due to everything looking like a nail once you have a hammer - most of the negative connotations with XML in my mind actually come from Java EE et al and how it tried doing dynamic code loading through XML configuration (e.g. web.xml, context.xml, server.xml and bean configuration), which was unpleasant. On an unrelated note, XSD is the one truly redeeming factor of XML, the equivalent of which for JSON took a while to get there (JSON Schema). Similarly, WSDL was a good attempt, whereas for JSON there first was WADL which didn't gain popularity, though at least now OpenAPI seems to have a pretty stable place, even if the tooling will still take a while to get there (e.g. automatically generating method stubs for a web API with a language's HTTP client).

donmcronald 5y ago

For me XML and YAML are about the same. I think I'd also prefer comment-less JSON over both. However, XML wasn't that bad. With a decent editor and schema validation I would say there's a good chance I was more productive with XML than I am with YAML.

mindcrime 5y ago

So you prefer the "good old" XML days? I'll take comment-less JSON over XML any day Sure, why not? XML rocks. I'll take it over JSON for many purposes.

int_19h 5y ago

Actually, yes, I do. XML syntax was far from stellar, and much of the ecosystem (e.g. XML Schema) was drastically overengineered... but even so, we had gems like RELAX NG to compensate. On the whole, it was better than the current mess.