Web applications. If it is at all possible to make it a a web application why mess around with anything else? The other day I was struggling with "How the hell do I tell Android users how to find a QR code that really works in the play store" and then it hit me... Web based QR code reader and done!

It can be depressing that you have 20 electron applications running to put icons in the tray but heck... everybody wants to stuff icons in your tray and most of those x-platform frameworks can't make a tray icon. I did an evaluation of a whole bunch of x-platform frameworks and they all sucked, though I do like JavaFX best of all. There's a reason why Electron is as big as it is.

I agree but to go further, for an MVP: Just release a regular web app that does a decent PWA!

In Chrome you can turn any page into an taskbar iconned app from the menu now. Tell your users to do that. Actually an easier “install”. Web APIs do so much and you can integrate with Dropbox/OneDrive for file access (or use the apis if you want).

Offline is available using service workers. Camera, location, touch, gyro, etc. are all available.

JavaScript has accomplished this, though. It's just that React Native/Phone Gap isn't as performant as native. I'd argue though that the web is a "run anywhere front end" given that pretty much everything has a web client these days, even TVs.

The main issue around this is that there's not a great interface to use native functionality on the web, hence all of these compilation attempts.

My partner and I run a small video game studio and we wanted a bytecode format we could run on every device we owned, so we made a 100ish lines VM spec, and implemented these thin emulation layers for the different platforms. My wiki, our games, the compilers, linters and type checkers are all written in that same language, assembling to rom files that will run equally well on a GBA, Playdate, RPi, Thinkpad, PSP and so forth.

It's worth looking into. I hope you find something that works :)

https://100r.co/site/weathering_software_winter.html

For some things, uxn/varvara will do; it is simple enough that it can run anywhere.

For other things that can run by internet, a subset of telnet and terminal codes might do; however, that is only good for remote services and not for stuff that is more useful to run locally.

For some things, C will do, especially command-line stuff, but also is possible to use SDL, etc.

You do not need so much extra stuff that just makes it slow and takes up more memory and makes it difficult for the user with program working together; for this reason, UNIX pipes are useful because you can put any program together by pipes. (Like, another comment also mention something similar)

I have been on two projects now that use web frameworks to ship complex management applications and both were nightmares. The cost of doing even simple changes was not small. React has been way worse than angular on this front too. People do not understand it. They do not think "the react way". They invariably code something that doesn't consider reacting to change properly and now you have a complex component that is refreshing all the time

Half me wants to say that the SSR-based web application was a revolution. I had a boss who was both a sales genius and an obnoxious penny pincher and he had a pitch that "custom software development was more affordable than ever" and I would back up that with an explanation of the miracle of the relational database and the "stateless" applications that could be built out quickly.

The thing about React is it can be so much fun if you have a clear plan for how information flows in the application. If you don't it can be hell.

I was working on "Rich Internet Applications" based on Javascript not long after Google Docs came out and back then we were making knowledge graph editors, applications that could plan sales territories for organizations with a division (as in military) worth of salespeople, etc. All things you couldn't possibly do with SSRHTML (back then people knew how to implement both simple and complex forms that way.)

Then angular came along and all the little web agencies that were making Ruby on Rails apps with great success felt they couldn't sell those kind of apps anymore and instead they started struggling, struggling and struggling with Angular.

Back then I was making highly dynamic applications with property sheets and other UI elements that the user could control (think an IDE, Photoshop or Figma) and had developed frameworks for updating application state that would self-organize to handle this.

I laugh at Redux and most of the "state management" solutions out there. MobX looks a lot like the systems I used to build, but for some reason hardly anybody uses it.

Everyone bought into "immutable" "no side-effects" "one way data flow" as this ultimate goal. But never thought what the tradeoff is.

And people get FOMO that they need to use a big thing that they couldn't write themselves.

Whereas if you throw out everything and just build only what you need, you get something infinitely more understandable and simpler, probably with some hand-rolled data-binding thing that you actually understand.

Most people don't understand how their frameworks are working under the hood. They are just relying on a nicely documented API...until anything goes wrong.

Trying to debug React for example is insane. And if you build your own custom store it re-renders 6 times when in dev. When I saw this...I knew React's days were numbered.

Yeah that’s the ultimate interview question from Facebook: “explain why this component calls render() 46 times” and the answer is “it doesn’t, it renders 47 times” and they have to bring in one of the core developers to stop all the head scratching.

Yeah, the last paragraph is the clincher. When it's going wrong, on fire, lagging out your browser, and you're adding console logs in effects to chase what is driving changes you've lost.

Yeh, React is a nightmare. It's too easy to build a tangled, un-performant mess.

Do you have thoughts and opinions on the various options for Windows desktop development? I would be curious to know, I am starting to work on a Windows desktop app. I am assuming that the first, MVP-style, attempt will be using Electron.

But I am also wondering if Maui will end up being a better option, or if I will be able to have an excuse to use the Avalonia framework for F#

> the first, MVP-style, attempt will be using Electron.

Good choice.

If you want to stick to HTML...WebView2 is suppose to replace it, but it assumes your backend code is .NET or C++, instead of JS/Node.js. Microsoft Teams is using it.

If you want to use native Windows UI components from JS code, then React Native for Windows is recommended. Facebook Messenger is using it.

All approaches require C# or C++ modules to be used to interact with the Windows Platform. Or there is: https://github.com/tjanczuk/edge.

The recommended approach is WinUI 3 which would involve C#/C++ and XAML.

To SwiftUI/React/JetPack are called module-view-update (MVU). There is an MVU for C# called Comet. https://github.com/dotnet/Comet#key-concepts

Cool, thanks for this info.

Seems like there are kind of many, many options, but none of them are particularly great.

Just no obvious choice like every other platform.

I think avalonia is much more promising than Maui as the latter seems to be kind of mythical in nature.

What do you mean? That you've never seen anything actually built in Maui even though people mention it?

It seems not ready for commercial use, and perpetually not ready, which is unfortunate.

I’ve been working on a complex desktop WPF application and I’m happy with the results.

I don't know, I'm using Flutter just fine for all that you're saying.

What is wrong with Flutter it seems to satisfy your my needs of "Write once run every where" for frontends.

Livecode does all that stuff.