On one hand, you aren't wrong: XML has in fact been used for machine-to-machine communication mostly. OTOH, XML was just introduced as a subset of SGML doing away with the need of vocabulary-specific markup declarations for mere parsing in favor of always requiring explicit start- and end-element tags. Whereas HTML is chock full of SGMLisms such as tag inference (for example inferring paragraph ends on block elements), empty ("self-closing") elements and enumerated ("boolean") attributes driven by per-element declarations.

One can argue to death whether the web should work as a mere document delivery network with rigid markup a la XML, or that browsers should also directly support SGML authoring idioms such as the above shortform mechanisms. SGML also has text macros/shared fragments (entities) and even allows defining own parsing tokens for markdown, math, CSV, or custom syntaxes. HTML leans towards SGML in that its documentation portrays HTML as an authoring language, but browsers are lacking even in basic SGML features such as entities.

I do wonder what web application markup would look like today if designed from scratch. It is kind of amazing that HTML and CSS can be used for creating beautiful documents viewable on pretty much any device with a screen AND also for creating dynamic applications with pixel-perfect rendering, special effects, integrations with the device’s hardware, and even external peripherals.

If there was ever scope creep in a project this would be it. And given the recent discussion on here of curses based interfaces it reminded me just how primitive other GUI application layout tools can be while still achieving amazing results. Even something like GTK does not need the intense level of layout engine support and yet is somehow considered richer in some ways and probably more performant for a lot of stuff that’s done with it.

So I am curious what web application development would look like today if it wasn’t for HTML being “good enough”.

We just couldn't keeps apps' hands out of the cookie jar back then.

I will remind you that Swing sucked, hard in the 1990s. And HTML was pretty easy to write.

Suggesting something like HTML would have you laughed out of the room.

This is only the case because the BigTech view is one of an application platform.

Interesting take, but I'm always a little hesitant to accept any anthropomorphizing of computer systems.

Isn't it always about what we can reason and extrapolate about what the computer is doing? Obviously computers have no preference so it seems like you're really saying

"XML is a poor abstraction for what it's trying to accomplish" or something like that.

Before jQuery, chrome, and web 2.0, I was building xslt driven web pages that transformed XML in an early nosql doc store into html and it worked quite beautifully and allowed us to skip a lot of schema work that we definitely were ready or knowledgeable enough to do.

EDIT: It was the perfect abstraction and tool for that job. However the application was very niche and I've never found a person or team who did anything similar (and never had the opportunity to do anything similar myself again)

Names withheld to protect the guilty. :)

In fact the RSS reader I built still uses XSLT to transform the output to HTML as it’s just the easiest way to do so (and can now be done directly in the browser).

I wish someone would write "XML - The Good Parts".

Others might argue that this is JSON but I'd disagree:

- No comments is a non-starter

- No proper integers

- No date format

- Schema validation is a primitive toy compared what we had for XML

- Lack of allowed trailing commas

YAML ain't better. I hated whitespace handling in XML, it's a miracle how YAML could make it even worse.

XML is from era long past and I certainly don't want to go back there, but it had its good parts and I feel we have not really learned a lot from its mistakes.

In the end maybe it is just that developer ergonomics is largely a matter of taste and no language will ever please everyone.

I know it's passé in the web dev world, but in my work we still work with XML all the time. We even have work in our queue to add support for new data sources built on XML (specifically QIF https://qifstandards.org/).

It's fine with me... I've come to like XML. It's nice to have a standard, easy way to do seschemas, validators, processors, queries, etc. It can be overdone and it's not for every use case, but it's pretty good at what it does.

In my military work, I've heard the senior project managers refer to a modern battleship as a floating XML document.

That is because the web dev world is unfortunately obsessed with the current thing. They chase trends like their lives depend on it.

When was the last time you had an editor that wouldn't just auto close the current tag with "</" ? I mean it's a god-send for knowing where you are at in large structure. You aren't scrolling to the top to find which tag you are in.

what I really dread in XML though is that XML only has idref/id standardized, and no path references. so without tool support you can't navigate to a reference target.

which turns XML into the "binary" format for GUI tools.

Maybe, but XML tools are also just superior to JSON counterparts. XPath is fantastic, and so is XSD and XSLT. I also quite like the integration with .NET.

My general experience with JSON as a configuration language has been sad. It's a step back from XML in a lot of ways.

however most oss builds on libxml which is stuck in xslt 1 and xpath 2 iirc...

I recently stumbled upon James Clark's youngest brainchild the ballerina language.

https://ballerina.io/

https://en.wikipedia.org/wiki/James_Clark_(programmer)#Caree...

Again not great for bigger documents.

That was a huge reason JSON took over.

Another reason was the overall XML ecosystem grew unwieldy and difficult to navigate: XPath, XSLT, SOAP, WSDL, Xpointer, XLink, SOAP, XForms... They all made sense in their own way, but it was difficult to master them all. That complexity, plus the poor ergonomics, is what paved the way for JSON to become preferred.

I suspect it was SOAP and WSDL that killed it for a lot of people though. That was a typical example of a technical solution looking for a problem and complete overkill for most people.

The whole namespace thing was probably a step too far as well.

    <greeting attr="val" href="#">Hello <thing>world</thing><greeting>

    (greeting ((attr "val") (href "#")) "Hello " (thing "world"))

As in, I don't see a difference between `(attr "val")` which expresses an attribute key/value pair and `(thing "world")` which expresses a tag/content relationship. Even if I thought the rule might be "if the first element of the list is a list itself then it should be interpreted as a set of attribute key value pairs" then I would still be ambiguous with:

    (foo (bar "baz") "content")

    <foo bar="baz">content</foo>

    <foo><bar>baz</bar>content</foo>

See a grammar for the representation at https://docs.racket-lang.org/xml/index.html#%28def._%28%28li...

Most Scheme tools for working with XML use a different layout where a list starting with the symbol @ indicates attributes. See https://en.wikipedia.org/wiki/SXML for it.

    (foo (bar "baz") "content")

    (foo ((bar "baz")) "content")

I would prefer the differentiation to be more explicit than the position and/or structure of the list, so the @ symbol modifier for the attribute list in other tools makes sense.

The sibling comment with a map with a :attrs key feels even better. I don't work in languages with pattern matching or that kind of thing very often, but if I was wanting to know if a particular element had 1 or more attributes then being able to check a dictionary key just feels like a nicer kind of anchor point to match against.

Just remember that it's a markup language, and then it's not head-scratching at all: the text is the text being marked up, and the attribute values are the attribute of the markup - things like colour and font.

When it was co-opted to store structured data, those people didn't obey this rule (which would make everything attributes).

Namespaces had a very cool use in XHTML: you could just embed an SVG or MathML directly in your HTML and the browser would render it. This feature was copied into HTML5.

I mean, if I'm modeling a <Person> node in some structured format, making a decision about "what is the attribute of the person node" vs "what is a property of the specific Person" isn't an easy call to make in all cases. And then there are cases where an attribute itself ought to have some kind of hierarchy. Even the text example works here: I have a set of font properties and it would make sense to maybe have:

    <font>
        <color>...</color>
        <family>...<family>
    </font>

I just don't think the distinction works well for an extensible markup language where the nesting of elements is more or less the entire point.

It is much easier to write out though, which is why you see often see `<Element content=" ... " />` patterns all over the place.

  {:tag     :greeting
   :attrs   {:href "#" :attr "val"}
   :content ["Hello" {:tag :thing :content ["world"]}]}

  [:greeting {:href "#" :attr "val"} "Hello" [:thing "world"]]

I've written a rudimentary EPUB parser in Clojure and found it easier to work with zippers than any other data structure to e.g. look for <rootfile> elements with a <container> ancestor.

Zippers are available in most programming languages, thankfully, so this advantage is not really unique to Clojure (or another Lisp). However, I will agree that something like sexps (or Hiccup) is more convenient than e.g. JSX, since you are dealing with the native syntax of the language rather than introducing a compilation step and non-standard syntax.

Racket has helper libraries like TxExpr (https://docs.racket-lang.org/txexpr/index.html) that make it pretty easy to manipulate S-expressions of this kind.

There's something very zen-like with this language; you put a document in a kind of sieve and out comes a "better" document. It cannot fail; it can be wrong, full of errors, of course (although if you're validating the result against a schema it cannot be very wrong); but it will almost never explode in your face.

And then XSLT work kind of disappeared; I miss it a lot.

XML gives you an object soup where text objects can be anywhere and data can be randomly stored in tags or attributes.

It just doesn't at all match the object model used by basically all programming languages.

I think that's a big reason JSON is so successful. It's literally the object model used by JavaScript. There's no weird impedance mismatch between the data represented on disk and in your program.

Then someone had to go and screw things up with YAML...

JSON5 is the way.

There, I said it.

At the risk of glibly missing the main point of your comment, take a look at KDL. Unlike JSON/TOML/YAML, it features XML-style node semantics. Unlike XML, it's intended to be human-readable and writeable by hand. It has specifications for both a query language and a schema language as well as implementations in a bunch of languages. https://kdl.dev/