Not sure how homoiconicity is related to this at all. Macros don't seem involved.

But I do think s-expressions are an improvement over HTML in certain scenarios.

That said (talking to OP now), why is the control handler outside the button?

In actual HTML, we have [button onclick="codeToBeEvaled()"]

In this thing, you have [button][onclick [sub-expressions]]

With s-expressions, at least you have some semblance of function calls, which would make control flow operators seem slightly more natural, but this hybrid of semantic and syntactic choice just seems bizarrely limited.

>But I do think s-expressions are an improvement over HTML in certain scenarios.

I agree. S expressions are a data interchange format. HTML is a markup language. They solve different problems.

S expressions define nested lists of atoms. HTML describes semantic hypertext documents defined by a document tree made of element nodes as subtrees, attribute nodes as subtree metadata, and text nodes. In some scenarios a uniform data structure like s expressions is nicer to work with.

To be honest it boggles my mind that XML was ever used as a universal data format.

> Not sure how homoiconicity is related to this at all. Macros don't seem involved.

"Code is data" is more general and fundamental idea; it's a fact of nature. Homoiconicity is a way to try and embrace it instead of fighting it.

For most tags you can also put the event handlers as first children inside the element, but self-closing tags like <input> don't support that. I'm now putting the event handlers always outside (as next siblings) for consistency.