upvote
I challenge you to replicate something "simple", like an iMessage-style UI/UX in pure Win32 or WinForms.

The web views are entirely about productivity gains, not technological excellence. I don't know of many who would argue that the web view approach is superior from a purely technical perspective. It is mostly downsides in terms of performance, E2E latency, startup delay, security edges, etc.

reply
In WinForms?

Is that supposed to be a challenge?

WinForms is incredibly easy and simple to use...

Doesn’t mean you should use it for new things in 2026, but for building a chat app with? Yeah, it’d be very easy.

I’d know, because I’ve done it (granted it was over 15 years ago at this point, but I’ve done it). Was used internally, with a PHP backend. Worked great!

reply
You should try the last few Xcode versions some time. As far as I'm aware there's not a single line of Javascript in it, and all UI is 'native' (whatever that means these days), and the whole experience is such a janky and laggy mess that even VSCode feels slick.

It's trivial to write slow UI application in any tech stack, and just being 'native' really means nothing nowadays.

reply
I've seen variants of this comment for many years. The alternative to "web UI slop" would presumably be one of the many native toolkits.

I see it in a different way. The fact that "web UI slop" has managed to make great inroads on the desktop is an indictment of the state of native toolkits. If you think it's a problem that desktop apps are being written with web toolkits, the solution for that isn't to shame (as the term "web UI slop" clearly tries to do), but rather to figure out how to improve the native toolkits.

The opportunity to improve those toolkits was always there, and the ball was dropped.

reply
Yes, native UI toolkits are not perfect, even though I consider Qt very close to one (I'm sure naysayers will find nitpicks). In the end, the choice is between the apps that eat 1GB of your RAM and learning to deal with some idiosyncrasies of native toolkits.
reply
There's also just shipping with a Web interface that opens in a browser (like Jupyter, or WebUI apps). Plus there's the option to use the system Webview like Deno Desktop (this), Tauri and Electrobun do by default.

So thankfully we can still have our REPLs with live reloading and nice documentation (MDN, W3schools etc.) and large library of embeddable UI components without most the costs of using electron.

reply
It hasn't made any inroads on the desktop though... all anyone did was just package their own SWA into a self-contained browser that serves its own content. They continue to be websites, with all the pitfalls of them.

I don't need to spend 2GB-4GB of RAM just to have a over-glorified IRC clone!

Also, the native toolkits are fine. Windows has two toolkits, the ShellUI/MFC family (which does everything required, although it doesn't always get hidpi on legacy apps correct; it gets integration for blind people and also unicode/multilingual correct, and also works with touch interfaces), and WinUI does it more modernly (and ticks all the boxes). OSX has its toolkit, seems to nail everything correctly. Linux has Qt (lets ignore GTK for now, only reason you use GTK is if you want to appear Gnome-native), and Qt also does native++ uplifting on other toolkits (ie, native widget + additional feature expansion, plus perfect mimicry of native look for entirely new widgets), plus Qt does everything you need to do correctly and easily.

There are also new UI toolkits coming up through the ranks that are trying to knock Qt off that #1 position. None of the WebUIs would even place in this race.

Web UI toolkits always look non-native, are hard to interpret, often use low contrast (and frankly ugly) colorschemes, are easy to use in ways that do not comply with usability standards across OSes, and usually do nothing for A11Y.

The opportunity to improve those toolkits was always there, and the ball was dropped.

reply
I think the fact that you listed off five toolkits for three different OSes, all of which are "that OS's own toolkit," might point at the root of the problem here.
reply
Windows is so fucking old that I think it has a right to try again.

And, btw, the reason Microsoft even bothered is because (dun dun dunnnn) lots of internal apps at Microsoft were written with Qt, not MFC, and leadership got pissed when they realized (they couldn't tell the difference, since Qt does the native++ technique).

As for Linux, yeah, thats a shitshow. Qt was closed source, Linux isn't, so they made Gtk, but then Qt got open sourced, and then the Gtk guys just kept going. Qt can mimic Gtk3/4 themes and already uses 100% native rendering (same APIs Gtk does).

People keep writing Gtk apps for some reason, and I don't know why. I can get the C++ hate, but Qt has the cleanest C++ I've ever seen.

reply
Gtk is hardware (GPU) accelerated, while Qt Widgets is software/CPU-rendered.
reply
I notice you say, specifically, Qt Widgets.

Yes, classic Qt Widgets still doesn't allow for hardware acceleration.

However, the majority of Qt UIs you deal with are in Qt Quick, which is hardware accelerated. Almost all of KDE is Qt Quick, for example.

reply
Yes, I was considering C++ (and C) desktop UI toolkits. Unlike Qt Widgets, QML/JavaScript is a horrible mess and not suitable for desktop software.
reply
Even if SwiftUI, Qt and whatever Windows uses this morning were absolutely perfect, developers would write web UI slop to not have to write three frontends. That, and familiarity with JS are the whole reason.
reply