There's no reason that that can't all be done as part of the underlying IMGUI implementation; what you're working with above that is essentially a DSL that renders out to a workable set of controls. Layout management and the actual rendered graphics / animations are handled by the code you don't have to see.
If anything, this is actually a lot like Web 1.0 programming: server side rendering, often using templates that end up looking a lot like a DSL. Each page view is rendered based on those templates against data fetched in advance of the output.
You can get pretty deep with that kind of thing, though of course the page refresh time was what killed this otherwise fairly nice style of writing an application. Users expected actions like sorting a column to be as fast in the browser as it was in a Windows 95-era file explorer or Excel, and it simply wasn't happening.
(Imagine if first-class client-side-interactive UI components like a sortable table, tabbed panel, etc. like what XUL provides had been in HTML in the 90s. We wouldn't need half the Javascript bullshit people have to use now to replicate that functionality half-assedly...)
If anything, this is actually a lot like Web 1.0 programming: server side rendering, often using templates that end up looking a lot like a DSL. Each page view is rendered based on those templates against data fetched in advance of the output.
You can get pretty deep with that kind of thing, though of course the page refresh time was what killed this otherwise fairly nice style of writing an application. Users expected actions like sorting a column to be as fast in the browser as it was in a Windows 95-era file explorer or Excel, and it simply wasn't happening.
(Imagine if first-class client-side-interactive UI components like a sortable table, tabbed panel, etc. like what XUL provides had been in HTML in the 90s. We wouldn't need half the Javascript bullshit people have to use now to replicate that functionality half-assedly...)