There are many things I don't love about how tech has evolved, but when I look at a massive blob of XML and a lengthy explanation of "why this is better than just writing code!" I feel a little a bit more accepting of the current state of things.

▲

lenkite 4 days ago | parent | next [-]

I find massive blobs of XML easier to grok than massive blobs of JSON, esp well-designed XML with namespaces and use of attributes. XML is self documenting.

JSON is just a homogeneous unnamed bunch of braces and key-val pairs that you loose yourself in once you are several MB in and deeply nested. Need to resort to CLI tools like jq or hunt for the schema or docs.

Massive blobs of YAML, well - they should be simply categorized as a war-crime.

	▲	arcfour 3 days ago \| parent [-]
		Hell, you can parse XML and infer complex types! Good luck doing that with JSON though.

▲

wrs 4 days ago | parent | prev | next [-]

Sure, it's so much better to be writing massive blobs of YAML.

There just seems to be some misguided human impulse to take every data serialization language and force it to be a programming language, instead of just using a programming language.

▲

jact 4 days ago | parent | prev | next [-]

It is “just code.” It’s good at what it does too.

Although for my purposes, I find myself reaching for xquery a lot more often which is a very good and elegant programming language and template language although it was billed as “SQL for XML.”

▲

_heimdall 4 days ago | parent | prev | next [-]

XML and XSLT are a bad fit in many common uses, that's why the argument is frustrating. If you are almost always working with projects where you own the frontend and the backend, just stick with JSON and RPC.

▲

Telemakhos 3 days ago | parent [-]

If you’re only using XML for AJAX style communication of fragments of data between a model and view, sure, use JSON or whatever. If, on the other hand, you’re encoding a representation of a text and need to mark it up to indicate bibliographic features and textual variation between editions, you need TEI XML. If you want a dataset to be available in a machine-readable format at a particular address and also have that data look good for humans, you want XML. XML is for more than passing messages from a backend to a frontend.

	▲	_heimdall 3 days ago \| parent [-]
		I wasn't meaning to imply that XML is only for backend to frontend communication. I only mentioned they as it seems to be the most common task in web jobs today and is usually what a person does most often when I hear the complaint that XML is pointless and we should just use JSON.

▲

greggman65 4 days ago | parent | prev | next [-]

Agreed. I tried XSLT once. I made an XSLT for RSS. Coding in XSLT really sucked.

▲

_heimdall 4 days ago | parent | next [-]

Were you using XSLT 1.0 for native browser support? If so, yeah its pretty damn frustrating both in the APIs and the lack of browser support for basic debugging.

▲

vgr-land 4 days ago | parent | prev [-]

LLMs make it much easier. Then you get all the benefits with few of the frustrations

	▲	xyz_opinion 3 days ago \| parent [-]
		!

▲

hackrmn 4 days ago | parent | prev [-]

Current state of things is a mixed bag, in my opinion. XSLT wasn't perfect, and XML required a lot of repetition and neither got the amount of scrutiny both deserved to advance past their own inconvenience. But a lot of what we have today has just as many drawbacks, and that _despite_ WHATWG and Google hawking over it all. XML had namespaces, which alone were quite a potent feature that allowed to manage _semantics_ of data with more rigor and flexibility -- compared to the in my opinion amateur-ish "custom elements" HTML 5 approach, and how Apple refuses to implement parts of the spec., because they "don't believe in inheritance" (I am being liberal but those who know know). Then there is the HTML 5 parser itself -- "for the masses" -- with its idiotic and incomprehensible rules that are element specific, for which reason noone ever remembers these. Forgot a `</p>`? No problem, you can discover your omission after you've shipped! HTML 5 parser never aborts!