Comment by PaulHoule
1 day ago
The churn would have been much worse if Microsoft was rolling out successful GUI framework after GUI framework. As it is you can still write a Win32 app if that pleases you, or still write .NET (and damn that runtime download!)
Microsoft has bought into ‘make a web app’ since 1988, they introduced AJAX, they got flexbox and grid into CSS and numerous HTML 5 features to support application UIs. They ‘frikin bought npm!. I use Windows every day but I almost exclusively develop cross-platform systems based on the WWW, Java, Python, etc. Whenever I have developed with .NET it has been for a cross-platform front-end like Silverlight or Unity/itch.io.
I can’t say I have a desire to make a native Windows GUI app when I could make a web app: like if it worth doing from my computer isn’t it worth doing it on my iPad from anywhere with Tailscale? For all the complaints about modern JavaScript it gives you the pieces to make a very pleasant world in terms of DX and UX and you certainly don’t need to ship an Electron runtime for many applications.
Your post is touching on a key question: why write a Windows-specific app?
I'm a developer who has built and published several apps. I want the biggest possible audience for those apps. Why would I limit those apps to Windows? (Or even to any single platform/OS?)
Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS? Doesn't make sense.
Just build for the web. You can package web apps for all the major app stores using PWABuilder[0], no Electron needed. Just fast, lightweight apps distributed by app stores and accessible from the web.
[0]: https://pwabuilder.com. Disclaimer: I work on this
> Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS? Doesn't make sense.
For me, I see these following advantages:
- Performance; Native & compiled is king.
- Ram usage; Kilobytes vs Mega(giga?)bytes.
- UI control which integrates with the rest of the OS (and updates when the underlying OS tweaks the UI)
From a business standpoint, I get your point that these points don't really matter. Users have shown to not care in the slightest at the bloat in programs.
However for code I write in my spare time, I would much rather write my native Linux program in compiled code than to ship a subpar experience to the few who will interact with it.
> Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS? Doesn't make sense.
You mean the hypertext platform that has been shoehorned into Java's paradigm, suffering from the same boof-o-rama as Windows, and whose lowest common denominator to support must be Safari for iOS?
Safari isn't that bad for most applications.
Sure it is a hassle to get notifications working, but my take on that for years as a desktop user was "I need another source of spam about as much as I need to get raped". For years I had bottom of the line Android Tracfones and wondered "how is it people get so excited about apps?" because they just didn't work but once I got an iPhone I started to appreciate that the McDonald's app would send me a notification when my food was ready. Recently it was pointed out to me that the application behind these cards
https://mastodon.social/@UP8/116086491667959840
really would benefit from notifications ("your photos are ready!") and I am looking at the hurdles I can jump through and it looks possible but weird. Like why would I want people to install my app on the homescreen where it will get lost on page after page of twisty little app icons that all look alike?
Then there is that PWA boondoggle, there is another app in that system that I can use to register those cards and it is a clear case where I might want to do it outside of cell coverage (say I was in the woods) save a form submission and upload when I get back in range.
What can I say? That service worker system is insane, something like Kubernetes that only Google could subject us to. I mean, Google could have worked out the math for synchronizing a local database to a remote database, by then the Lotus Notes patents were mostly expired, we could have gotten something good. Or Google could have added an API to control the behavior of the browser cache. Instead we got something half baked and barely reliable and then Apple went out and made something a little bit worse. Had it been a good standard to begin with the outcome could have been entirely different.
still works everywhere? the snark doesnt get you firther than that
3 replies →
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".
1 reply →
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.
7 replies →
Because many of those features aren't Web, rather Chrome OS Application Platform, but apparently folks forgot everything about IE history lesson.
What happens when the user doesn't have internet access, or only has very slow internet? What if they're on a metered connection?
Seems to me the point of the web is: no app store bullshit.
On the web if I want to publish a web app... I publish the app. If Apple things my app isn't good for their business... tough luck for them.
If I want to update a web app... I update the app.
If a user wants to use an app... They visit a URL and the app is there! No having to face id, go looking for the app in an interface that's designed to hide the search function, that is filled with spammy trash imitation apps (that somehow get approved by the app store anyway)
All the time I hear somebody crying that their developer account got canceled and I want to say "what did you expect? the contract for a developer account is a suicide pact for your business." Stay free!
>Your post is touching on a key question: why write a Windows-specific app?
Why write an anything-specific app?
> Web apps work everywhere. The web has grown increasingly powerful and capable. Why would I invest in a technology that can only run on a single OS?
There are other options besides "web app" and "only one OS". A cross platform app which uses something like GTK or QT will be a massively better experience for your users, one a web app cannot hope to equal.
I know one of the GTK developers who dropped out of my research group in the 1990s who's been in charge of triaging tickets and he's the kind of guy who doesn't care if there is just 1.05:1 contrast between text and background and will refuse a one-line patch to make menus render right in rootless X windows because he wants to punish you for doing things in a way he thinks is wrong.
And he probably wonders why it is never "the year of the Linux desktop" but hey it is OK because Red Hat Linux is something enterprises subject their users to and if it had the slightest bit of flair customers would complain.
So when I hear GTK I think Nein Danke!
In general Linux has the kind of fanbois problem that MacOS had maybe 10 years ago. There are so many things that still "just don't work" after years and they never get fixed because you can live without them. For instance I can tell you how to install some package like
and that's all! I can make 10 pages of screenshots to tell you to click and click and click and click and click to install "mypackage" with the GUI [1] and you may wind up looking at a spinner for 10 minutes or longer (eventually you give up) and you might wind up corrupting your package database and not being able to install or update anything until you look up how to rebuild it. The Linux desktop is stuck with having done the 20% of the work that gets it 80% done and never does the rest of the work because you can use the command line anyway.
[1] and you still might misunderstand it and need intensive tech support
What’s an example of a well made GTK or QT app in your opinion? And what would be the steel man Web app to compare that to?
4 replies →
A lot of grandeur but zero substance. Aside from performance, what would being written in GTL/Qt bring to VSCode or Obsidian?
[dead]
[dead]
Features. Speed. Do your web apps only work in Chrome by the way?
I am a Firefox-first developer, almost everything I write works in Firefox/Chrome/Safari without a lot of drama.
I have one application at work that loads a table with 40,000 rows into a data grid that works really well on Chrome and lags on Firefox, that's the one case where the performance difference matters.
This year I've been interested in biosignals applications that read data with the Web Bluetooth API and Web Serial API which are ordinarily Chrome-only. I was about to get one of my junk Android tablets out of mothballs when I found there is Bluefy for iOS which supports the Bluetooth API so I have no problem going to labs where they have a really klunky HRV system based on a PC and show them something sleek on my iPad and in 20 minutes i can demonstrate to you, with your own physiology, everything you actually need to know out of a big review paper on HRV.
[dead]
Windows until 24H2 (when Edge and the last remnants of IE were replaced by Chrome) supported HTML apps [1], introduced with Windows 98 Active Desktop. They weren't used much but actually not that bad for end-user needs.
[1]: https://learn.microsoft.com/en-us/previous-versions/ms536495...
It was decent, we shipped one but switched to .net because of high dpi scaling issues IIRC
> For all the complaints about modern JavaScript it gives you the pieces to make a very pleasant world in terms of DX and UX
There is no such thing as pleasant UX in a web app. The best experience will always be a native app, a web app is at best a port in a storm solution.
When Windows wants to nag you it makes marketing-oriented screens that I think are visually attractive in a commercial way if not quite as 'cute', 'cool' and 's--y' as a gatcha screen from a mobile game. These sure look like they were drawn with an HTML-based rendering system and if they weren't, they were certainly inspired by commercial art on the web.
When MacOS wants to nag you it pops up a Liquid Glass vandalized version of the 1999 retread of the modal confirm dialog from the 1984 MacOS.
I wish both of them had NEVER OPEN A MODAL DIALOG THAT I DIDN'T ASK FOR EVER AGAIN button that took 80% of the space and a tiny little greyed-out link at the bottom that said "maybe just maybe I want to hear about this in three years" but from a graphic art viewpoint I laugh at MacOS.
> The best experience will always be a native app
Nonsense. The best experience is the one that solves user’s issue. Technology choice is orthogonal to that.
Figma is far superior to the native apps it replaced. As is VS Code. Slack.
One could (and I would) argue that they achieved that despite their web-tech-based UIs, not because of. At least those of us who were around for the days when most apps were still native, do notice and get bothered by the input lag, for instance.
Slack is, in fact, one of the worst offenders. It is so incredibly sluggish. And it doesn't need to be, when I compare it to the speed (and memory consumption) of Pidgin with the Slack plugin.
2 replies →
> As is VS Code.
That is, uh, controversial.
Along both "alleged replacement" and "alleged superiority" axes.
1 reply →