The nice thing about separating the view definition from the controller code is you can work on the view without actually running code. Most retained mode GUIs have standalone view editor. That's essentially not possible in immediate mode guis without a lot more mocking of code.

What if you have stacked elements, or elements within elements.

<Box> <Button> <Icon/> </Button> </Box>

In code it's something weird like

Box(button( Icon() )))

How is:

  Box(
    Button(
      Icon(...)
    )
  )

Weirder than:

  <Box>
    <Button>
      <Icon ... />
    </Button>
  </Box>

Now attach some callbacks.

With XML I'm attaching my callbacks via code while defining the UI elsewhere.

With pure code, I have to attach the callbacks directly to the object.

Theirs a reason you don't just use JavaScript to define React components

You're in the wrong thread. :-)

The main benefit of most immediate mode guis I've seen is that it's trivial to expose internal values to a ui in one line of code. No callbacks, no looking for the right place in any XML file or similar. Instead you add these lines when you need them and they show up in a ui:

   checkbox(&godmode, "Activate Godmode")
   slider(&enemy_aggro, "Enemy aggression", 0, 100)

> Now attach some callbacks.

Not that any of this is relevant to immediate mode GUI, but the actual attachment of callbacks can be done identically in code no matter how the base UI design is done if you want it separately, but if you do it in code (whether with normal syntax or a funky transform like JSX) you can also have the option of direct attachment.

> With pure code, I have to attach the callbacks directly to the object.

No, you don't, but you can, and as it turns out, that's kind of popular.

> Theirs a reason you don't just use JavaScript to define React components

You can, in fact, but even when you use JSX, there is a reason you don't use actual (HT/X)ML code, but instead a language that compiles to, and let's you freely mix in, JavaScript.

Let's say you have a really complex UI.

Would you really define your UI in code over XML or HTML

Yes.

The more complex and more dynamic the UI, the worse the separation gets. The worst of it being when you’re writing code to generate your XML/HTML, and probably introducing a third “templating” language to continue the pretense that HTML/XML is not just standard data structures defined in a different syntax.

The purpose of XML/HTML is to make your GUI specification independent of the programming language itself, and independent of any particular library (anyone can spit out an HTML <button>… it’s quite difficult for C++ to construct a Java Button class).

And there’s some notion that it’s easier for “non-programmers” to edit, without being bogged down programming language details (its “easier” to learn HTML than Java… and as programmers we eat the cost by now having to learn both)

So now I'm assuming, you're approach would be to just have classes for your custom UI elements.

It might just be a Unity thing, but up until they released their XML UI tools, I could not build a decent UI for the life of me. Basic things like getting buttons to appear where I want them to are very hard without XML

It’s ultimately the same; XML largely maps to a class with attributes (and an identifier/navigation through XPATH) fairly strictly.

And it should largely take you the same amount of effort;

    Div ( 
      button(…)
    )

And

    <Div>
       <button>…</button>
    </Div>

is equivalent. Things like separating your definition from your styling isn’t a feature of HTML/CSS, it’s a feature of the API design — the API just happens to be encoded one way or the other. In-line callbacks vs a selector + callbacks is the same as well (you still need a way to navigate the hierarchy, but XPATH & co. makes just as much sense on an object tree as it does on XML — although with code, you could also just keep the pointer around)

I don’t know unity’s API’s, but I’d bet that their GUI API doesn’t actually look much like their XML API; and that if they did, you’d have had just as much, or little, trouble picking it up.

I prefer the best of both worlds. I've been making a YAML like widget syntax in code using an immediate mode GUI written in Nim. It let's me write things like:

    Horizontal:
      box 10.WPerc, 100, 8.Em, 2.Em

      Button:
        text: fmt"Clicked4: {self.count:4d}"
        setup: size 8.Em, 2.Em
        onClick: self.count.inc()

https://github.com/elcritch/fidget/blob/devel/tests/basicwid...

Its entirely dependent on how w/e library your using implements that pattern. For the code I just recently wrote that does a similar thing, its literally just:

button.SetIcon(<icon-path-or-font-glyph>)

box.add(button)

Doesn't really seem all that weird to me.