Which is a way of deciding that makes sense given that I think the purpose of this article is "use my language instead". Getting lost in the weeds about each language's original design intent would bloat the article without meaningfully contributing to their thesis.

Back when XML was first being developed, I was really anticipating having a standardized, easier-to-implement successor to SGML (which was hampered by its complexity and by the cost of the ISO standard) in the text markup space. It was that disappointing it ended up filling the vacuum in the space of serialized representations for for structured data, then getting rejected when it wasn't quite as suitable for that as alternatives such as JSON.

I was more commenting on comments such as this one under Pkl:

> This is not a markup language. This is a full-blown programming language.

And under Nickel:

> Nice programming language. Not a markup language.

It's like he's saying "we should use markup languages for configuration, not programming languages", which I don't think he means.

> The era of XML is in the past.

Which is about as deep as it seems to get. My suspicion is that the reason people don’t like it is because it’s a bit of a pain to work with in JavaScript

Once you have learned the DOM API, it’s pretty much universal. Things like Document.getElementsByTagName not only work in JavaScript but also in Python: https://docs.python.org/3/library/xml.dom.html#xml.dom.Docum...

The best configuration language is the one that is custom made for a specific application. A domain-specific language. But DSLs requires a parser and adding one is usually too cumbersome to merely parse a configuration. This is where XML comes in.