(PART 2): ...so WPF is (was) completely unlike almost all previous (invariably OOP-inspired) UI frameworks. For context: previously, Win32 applications would c

(PART 2): ...so WPF is (was) completely unlike almost all previous (invariably OOP-inspired) UI frameworks. For context: previously, Win32 applications would create a top-level hWnd and populate it with composed child hWnd-based widgets and let USER32 handle the actual painting via GDI. This has a nice 1:1 conceptual mapping to how Smalltalk-style message-passing OOP is meant to work: objects (controls) are composed by some parent/container object and all these objects exchange messages between themselves to direct their behaviour. OS-level messages are received by the parent window object and passed-down hierarchically to child controls, which works nicely for things like painting and input processing... except when it doesn't: while tight-integration with an OS's widgets and window-manager means applications get lots of features "for free", especially with OS version updates (e.g. built-in spellcheck in normal textboxes, animated buttons, applications' visual appearance automatically matches each OS releases' distinctive UI theme, etc), but it also means that applications should avoid subclassing[4] Win32 controls to avoid things breaking in future OS updates[5] - or depend on the OS providing an older version of the widget for compatibility's sake and miss-out on any new, cool, exciting (or godforbid: actually useful) new features. Thus, OOP hell meets binary library versioning hell. Today's kids with their NPM doohickeys dependency hell and padleft nonsense don't realize how nice they have it compared to native GUI developers. ...so WPF is different: while WPF still uses Win32 hWnds for the top-level window with its titlebar etc), WPF completely opts-out of having Windows manage child hWnds for things like buttons, checkboxes, and the like. WPF's widgets can still be composed by a container or parent, but WPF's design discourages control subclassing (or at least, it eliminates the necessity for subclassing in order to extend or subtly modify binary/library controls and widgets) - so far, this doesn't sound too different to other GUI frameworks that also do-their-own layout and painting of child widgets (like Java's Swing), but the biggest, most fundamental difference in WPF is that the actual layout and appearance of a control/widget (i.e. its painting) is no-longer performed by a natively-compiled machine-code painting function making use of GDI or some other 2D drawing API: instead all controls/widgets everything has its appearance defined in XAML, and when a WPF control/widget library is compiled (be it an end-user application, a redistributable library, or WPF (or OS-provided) default control library) the XAML is still available at runtime. This is what makes WPF far, far, far more flexible and extensible than anything else before. And this was all designed in the early 2000s, long before CSS could even be used for web-page-layout or when HTML+DOM gained "web components". The 1990s way, of composed widgets/objects with subclassing, is OOP in a nutshell. In general programming we've seen OOP's limitations and the FP paradigm is now in-vogue, but FP depends on referential-transparency[6] (for things like function composition, not least for adequate runtime performance) - so if WPF can be compared to FP, it's that WPF's always-exported, always-reified, XAML is the GUI framework equivalent of referential-transparency. This is what allows applications to do previously-impossible things, like embed arbitrary controls inside a datagrid cells (e.g. checkboxes, picture boxes, numeric spinners, etc), whereas previously applications would depend on the datagrid control specifically supporting each of those input types, or resort to tedious hacks like owner-painting which would invariably break when updating dependencies.