This is probably one of the major things that Clojure gets right (ignoring EAVT databases) that no one copies

You don't need a CSS preprocessor if you can manipulate your CSS using the standard data manipulators in your given language, this applies to so many DSL languages like HTML, CSS, SQL, Clojure has Hiccup, Gardern and HoneySQL respectively

Here's a PHP SQL port I've been working on https://github.com/slifin/moonlight (keywords removed for ergonomics but it did lose power when I did that)

If a third party gives you a stringy language to work with you gain power back by creating a data representation, operating on that then converting it back to string at the execution point

In the case of PHP we took the Java route and put everything into objects: https://github.com/zendframework/zend-db, the amount of code required to do that is almost comical when compared, Zend DB also suffers from a lot of bugs/lack of features compared to honeySQL which is about 5 files of data orientated code: https://github.com/jkk/honeysql

I should mention Zend DB is not an outlier here for bulky code have a look at other PHP query builders they're all impenetrable

Not a fan. Given that in a template context the first atom will always be a symbol, all the : is just redundant. I despise visual noise.

The `:` is not visual noise, it indicates that it is a keyword. Without it, you're indicating that you're writing a symbol. Symbols are evaluated, so keywords is a better choice given that they always are what they say they are, whereas you could define `div` to mean `<p>`, point to a function, or any number of other things.

You could write a macro to use symbol names literally, so that `div` always means `<div>`, but then you'd have a macro where none was needed, and you'd have no obvious way of using symbols in a non-literal/evaluated way.

Fulcro[1] lies little closer to what you're after. The above would be:

  (div 
    (p "I am a component!")
    (p :.someclass
       "I have " (strong "bold")
       (span {:style {:color "red"}} "and red") "text."))

This is since Fulcro defines the element tags as functions, which are called in order, rather than as a data structure that's interpreted (a la Hiccup).

The immediate and obvious benefit of Hiccup over the function hierarchy is that Hiccup can be trivially (and safely) seralized/deserialized.

1: https://github.com/fulcrologic/fulcro

The advantage is that you can include normal Clojure expressions in it without any special syntax. Also lets you compose Hiccup data and forms without having two mental models of the data representation. Worthy tradeoffs IMO.