It looked like JavaScript was going to be able to do it. React and React Native were very promising.
But since we now have Swift/SwiftUI and Kotlin/Jetpack, each platform has a language and framework specifically tailored for it. Except for Windows which is still a shit show.
Attempts to abstract this in a cross-platform layer are becoming more and more difficult, and offering less marginal value (e.g. we now have declarative frameworks natively whereas before we only had React).
Each platform has a recommended way to do everything, and we should follow the conventions of each platform.
I would be interested to hear if anyone has actually had successful though with frontend code sharing...
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#
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
Seems like there are kind of many, many options, but none of them are particularly great.
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.
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.
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.
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.
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.
It's worth looking into. I hope you find something that works :)
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)
Might not even be adjacent to the topic of this thread but I remember the one time I accidentally found out about UNIX pipes in a bioinformatics course. I didn't know you could use computers in a way that would help you get things done gracefully and without GUIs. I didn't know I could just type in `curl wttr.in` and get the weather results instantly. I didn't even know about vim. I didn't know that an OS could occupy less than 1GB RAM on idle and still let you fully operate and do all the work that you need to do.
You can't just keep abstracting things to work with ways of computing that are just more painful to work with. At one point the end-user has to adapt and simplify for his/her own sake. I wish I did sooner.
