I used to get hung up on this native vs web thing. But when it comes down to it, it's just one renderer or another unless you're actually drawing the controls yourself pixel by pixel. The sticking point is following the system style / theme. But all the popular desktop OSs seem to have deviated on this so much themselves I'm not sure how important this is.
The inconvenient truth here is also that following the system theme is an anti-feature for most apps. On the desktop, you want your app window to be recognizable at a glance, meaning the primary color should be the brand color, etc.
I currently have open Chrome, Spotify, Discord, Aseprite, and Zed. All of them look completely different, and that's actively helpful for me, the user.
It's nice to follow the system's light/dark setting, and obviously the behavior of basic UI controls should be unsurprising, but beyond that there's no point in "consistency".
This. So often features to use system colors can cause apps to be unreadable or just look like crap. The first time I get a bug report that people can't read something I will lock the colors the down, I just don't have time for that.
Who says the system theme is well designed at all? Back in the 1980s you could count on most text color combinations on a Commodore 64 or an IBM 3279 or a PC with a CGA working.
Today it is absolutely normal to type
on a Linux machine out of the box and if you are running X or Wayland some of the file names are dark blue on a black background and completely un-readable. To be fair, if you are logging into a Linux machine on Windows with ssh on CMD.EXE or most terminal software you get similarly poorly chosen colors. (To be fair, MacOS does do better!)As a web developer it pisses me off because I am expected to follow
https://www.w3.org/WAI/standards-guidelines/wcag/
and regularly my management gets legalistic looking documents from customers complaining that we only have 6.5:1 contrast on something and you know what I do... I fix it. I wouldn't send anything to my tester that was unreadable and if I did I'd expect her to put in a ticket and I would... fix it. When MUI computes the coordinates wrong and something draws 20px right of where it should be... I fix it.
Whenever I've put similar tickets to the various parts of the Linux desktop mafia they close it as "won't fix" and often give me a helping of verbal abuse. Even Microsoft occasionally fixes something (even if half a decade late) and their people are polite.
yea there's so many ways through this now. golang and wails is great, rust and tauri is great. both seem to not feel like the slug that is electron because they just use whatever os native web view your os has.
for the dedicated more native stuff dioxus is kinda cool if you don't want a web stack in the mix.
i'm enjoying golang and wails though paired with whatever front end i want, all apps i've made perform execellent on windows. bottom line = yeah i can't really think of a scenario where i personally would ever write an app for windows specifically.
i, like you, used to get hung up on native vs web framework. i'd encourage you to give it a go, possible you cede that mayhaps the native thing isn't as important as you thought.
The DOM is very ill-suited for most UI. Too complex and lots of missing features. It’s a whole bag of unneeded code and the resulting UI doesn’t fit anywhere.
> The DOM is very ill-suited for most UI. Too complex and lots of missing features
Can you expand on this, because I'm not seeing it myself. The DOM, html+css is very flexible. It easily encompasses most UI. Most UI is some kind of data display, so lists, trees, tables, forms.
The need for JS might be what you're complaining about. I think we might be stuck with it as a UI control language forever.
The DOM(and CSS) is primarily built for documents and forms, even with the latest addition like Flexbox or Grid layouts. It is closer to typesetting tools like troff, latex, texinfo than any UI engines you can think of. And some that are not needed, like the difference between <i>, <a>, <span>, <strong>,...
Also with most GUI frameworks, there's some difference between widgets like label, button, menu, checkbox,... and containers that does layout management. And there are not a lot of elements in both sets. This is the reason why React Native has a very sparse components library. With simpler implementation, you have a simpler rendering path, and the developer have less elements to deal with.
Also some have ready-made implementation of really useful widgets, like tree, grids, tables, lists, and other dynamic things. You can find libraries for those on the web, but the web implementation of scrollable container is janky.
The GUI system for the NeXT was based on the Display PostScript system which in turn was based for the PostScript system designed for rendering to printers. Quartz in MacOS X is a further evolution of that.
Inside HTML 5 you can find facilities for rendering documents and you can find facilities for rendering applications, including those forms. There is not a clear line between one and the other.
PostScript was for rendering graphics to a printer with a good emphasis on texts. Most of HTML is about marking up and styling interactive documents. There’s no clear line between the two, but an API for applications UI has different goals than one for document typesetting (even interactive one).
HTML have a lot of tools for devex, but if you’re going for a good codebase and simple implementation for a desktop application, QT is way easier.
I don't know about "most UI" but it's sure as shit ill-suited for CAD (what I work on).
In which case you get canvas, WebXR, etc.
Why don't we have more great UI toolkits for the canvas?