I thought the point was that Windows apps will run on Linux under Wine (and macOS?) so using VCL is a cross-platform GUI development environment.

> Wait you can make Android applications with Golang without too much sorcery??

Why don't you try it out: https://www.remobjects.com/elements/gold/

>React’s approach is very inefficient - the entire view tree is rerendered when any change happens.

That's not true. React only re-renders down from where the update happens. And it skips over stuff that is provably unchanged -- which, fair, involves manual memoization hints. Although with React Compiler it's actually pretty good at automatically adding those so in practice it mostly re-renders along the actually changed path.

>And the code to do diffing and reconciliation is insanely complicated.

It's really not, the "diffing" is relatively simple and is maybe ~2kloc of repetitive functions (one per component kind) in the React source code. Most of complexity of React is elsewhere.

>The solidjs / react model uses the compiler to figure out how variables changing results in changes to the rendered view tree.

I actually count those as "React-like" because it's still declarative componentized top-down model unlike say VB6.

Sure but the parents point was more about declarative UIs than React. SolidJS and Svelte are declarative.

Dioxus is halfway between React and Svelte, and is working on its own native renderer. Might be worth considering.

Except on the AOT experience and low level programming, which only started to be taken seriously during the last five years.

Performance?

Same, I used to use Office 2003 because it was so quick and the UI was exactly what you needed.

On later versions they had animated cursor positions which felt slow, the spellcheck squiglies were lethargic and menus convoluted.

That said, I've given up and mostly use Google Docs/Sheets now because of the features and cross platform support.

That sounds nice. I agree, not having a UI editor making apps is a step back. However, you seem to be discussing mostly in past tense.

Maybe one day something like Lazarus or Avalonia would catch up but today I feel that Electron is best at what it does.

Traditionally WINE uses QEMU on Apple Silicon to execute x86 binaries on an ARM CPU, so while I’m aware WINE Is No an Emulator there’s likely emulation happening in a lot of cases.

Whenever people bring this up I find it somewhat silly. Wine originally stood for "Windows Emulator". See old release notes ( https://lwn.net/1998/1112/wine981108.html ) for one example: "This is release 981108 of Wine, the MS Windows emulator." The name change was made for trademark and marketing reasons. The maintainers were concerned that if the project got good enough to frighten Microsoft, they might get sued for having "Windows" in the name. They also had to deal with confusion from people such as yourself who thought "emulation" automatically meant "software-based, interpreted emulation" and therefore that running stuff in Wine must have some significant performance penalty. Other Windows compatibility solutions like SoftWindows and Virtual PC used interpreted emulation and were slow as a result, so the Wine maintainers wanted to emphasize that Wine could run software just as quickly as the same computer running Windows.

Emulation does not mean that the CPU must be interpreted. For example, the DOSEMU emulator for Linux from the early 90s ran DOS programs natively using the 386's virtual 8086 mode, and reimplemented the DOS API. This worked similarly to Microsoft's Virtual DOS Machine on Windows NT. For a more recent example, the ShadPS4 PS4 emulator runs the game code natively on your amd64 CPU and reimplements the PS4 API in the emulator source code for graphics/audio/input/etc calls.