I'd take a Delphi/Lazarus UI over most Electron apps.
They started fast, took little RAM or disk space, used very little CPU, had fast response times, supported standard UI conventions.
Today, we have endless options. But most are not as comprehensive as what Delphi is/was. I'd rather write a UI in Delphi/Lazarus (LCL/VCL/FireMonkey) than any other UI framework even today. The trouble is, I don't want to use it for anything else other than the UI.
UI design and data binding should be a simple mouse driven activity. That's adequate for most designs. Why do we need code? It's like expecting everyone to use LaTeX than RTF. Sure, it's more flexible, but an overkill.
I wish there are more integrations with modern languages than 20 types of grids with overlapping functionality. I'd write my code in a language appropriate for the task and just use Lazarus for the UI. Currently, Python (Python4Delphi) seems to be the only one with components for that, but even that needs more polish (and largely stagnant for over 20 years). Most I can do is do shared libraries and call in.
Creating custom controls was difficult and considered to be for advanced programmers only. If you did create one, you'd get little to no help from the OS. You got lines and rectangles basically. You lost all layout support, there was no good typography features, etc. Coordinates would all be computed by hand. A real PITA. So everyone used the pre-made widgets even when they weren't really appropriate.
There were no icon packs and very few icons that were widely recognized by users anyway. So, everything was very text heavy.
There was a strong convention back then that you did not use scrolling to reveal controls. In other words, if you had more controls than fitted on the screen, you were expected to use button-like things to switch between pages of them, not expect the user to scroll down. The UI toolkits didn't support scrolling of widgets all that well as a consequence. This bias goes back very far and is partly due to the lack of compositing and pervasive optimizations for slow redraw speeds - it was more efficient to do a single redraw from old to new set of widgets than the constant rapid redraws required for animation.
All the UI code is being written in relatively bad languages like VB or C that aren't designed with refactoring in mind. The word "refactoring" doesn't even exist in this era, IIRC. Certainly, IDEs that help you do it don't exist.
Layout in this time is mostly absolute, or scaled to font sizes at best. Layout managers barely exist, so windows that aren't resizable are standard. As a consequence if you run out of space in a window, it can be disastrous - adding a new button or feature can become a tedious nightmare of relaying out everything by hand. So once code is written and app architecture is set early on, it's never changed. Features get added but redesigning the UI is so painful people just don't do it, and so if they run out of space you get ever more tabs, dialogs, buttons that open more dialogs that have more tabs, in an endless maze.
