[PaulDavisThe1st]

Thanks for the detailed response.

A few additional points. First, neither GTK nor Qt really represent a particularly standardized library of widgets. They are not particularly consistent across major versions, but then in addition if you compare to some other toolkit (e.g. Cocoa/NextStep on macOS), you'll find extras and omissions no matter how you do the comparison. Moving existing code between even just major versions of any cross-platform toolkit is painful and often triggers major rewrites/refactoring that quadruple whatever the time would have been anyway. Going between toolkits (e.g. Qt <-> GTK) is essentially a complete rewrite (you retain what you learned the first time, but very few lines of code will survive). Having said, the basic structure of your code will survive, because the fundamental model of a heirarchical structure of nested widgets that trigger callbacks in response to user input (and other) events remains in place.

One critical difference with native development is that we (the developer) control the event loop. This is important enough that even Qt was smart enough to allow you use it with a foreign event loop (e.g. the one from Glib that underpins GTK). In a browser context, the actual event loop is far below your JS that you could almost pretend there's another "virtual" event loop running (and this indeed matches some React-ish docs I've read).

> This is at odds with the native approach, where a button look like a OS button no matter what

Actually, this is less and less true, especially as "office productivity" apps migrate to the cloud and what's left "native" are "creative" apps. These typically have no (or at least, less) issue with adopting look-n-feel that is wildly different from platform standards, even for something as basic as a button. Even within Apple, there is apparently a separate toolkit that they use for some/all of their creative tools (e.g. Logic Pro) which overrides a lot of the default platform theme.