On: Web browser as GUI, with your preferred language i...

[apatheticonion]

I wish that Apple and Microsoft would work together towards making it easier for people to make cross platform desktop applications.

It's largely uneconomical for most companies to develop and maintain separate apps using two different teams with minimally interchangeable skills.

Tools like Electron are, essentially, not a choice

I also wish that wasm would come sooner so we could have more memory and CPU efficient (threaded, statically compiled) web applications (for apps like Slack, messengers, Jira and so forth).

I know people keep saying "wasm is not a replacement for JavaScript" - but perhaps it could be an alternative. I know I'd like to write a web application in Rust but as it stands now there is little advantage to that, particularly without threads and DOM access.

[armchairhacker → apatheticonion]

We have good cross-platform desktop UI solutions: Java Swing/JavaFX, C++ GTK/Qt/wxWidgets, Rust egui/iced/Slint, and of course HTML/CSS/JS Electron/Sciter.

The problem is that cross-platform UI will never look as well as native UI because it’s not native UI: control sizes are different, colors and elements don’t blend the same way, and some things (like menu bars) are completely different in mac, Windows, and Linux. It’s not a slowness issue (if your UI isn’t responsive on today’s computers, you’re doing something very wrong), it’s not a usability issue, it’s not even an appearance issue (even Java UI can be made to look OK fairly easily in embedded systems). It’s an “I’m accustomed to native UIs and everything else is native UI, so any non-native UI looks out of place” issue.

[tsimionescu → armchairhacker]

If that were the problem, then Electron wouldn't help in any way either. In fact, Electron is even less interested in platform conventions than something like Swing. There isn't even default styling that tries to copy MacOS/Windows that you can apply.

The bigger problem is actually desktop-mobile compatibility today. No one writes apps only for Windows and MacOS. You want an app that works on iOS, Android, Windows and MacOS, and typically on the web as well so people can occasionally access it from an unfamiliar computer. So, the only viable option unless you want to have 4 dedicated UI teams or so is to write it in the lowest common denominator of HTML/CSS/JS, and use Electron and WebView to distribute it.

To a very good approximation, no one whatsoever cares about platform look and feel. In fact, most people actively prefer if they're using an app for it to have the same look and feel across all systems where they use it, including the web.

[mbirth → armchairhacker]

This! I hate when an app's GUI is following Windows-principles (if at all) and the macOS version is basically the same with a macOS theme slapped on top of it.

About 10 years ago I've experimented with an early version of appcelerator Titanium for mobile app development. It was JavaScript but GUI rendering was transcoded to either Android-Java or Apple-ObjectiveC and the respective code was compiled natively (while running your main code via a JavaScript engine). With a bit of if-then-else you could make one app that compiled for both platforms and looked and felt native on both.

[nanaian → apatheticonion]

Wasm threads via SharedArrayBuffer have been a thing for like 5 years. In Rust you can use wasm-bindgen-rayon, for instance. DOM access is and has always been easily achieved through imports. It's performant, too: https://youtu.be/4KtotxNAwME

[apatheticonion → nanaian]

It's __doable__ but I can't yet in earnest recommend it for a serious project (outside of canvas controlled GUIs).

The SharedArrayBuffer implementation requires spawning the same wasm module multiple times and passing the SAB to each instance. This works but is no replacement for thread management by the module/process itself.

It also requires restrictive "Cross-Origin-Opener-Policy" and "Cross-Origin-Embedder-Policy" headers - making it largely impossible for applications with multiple subdomains (for instance apps that have their API on api.myapp.com, or assets on cdn.myapp.com). Not an easy change for an established enterprise application.

Glue code might be performant but I really just want to go

> cargo build --target wasm

and

> <script src="app.wasm" type="application/wasm"></script>

[38 → apatheticonion]

> Tools like Electron are, essentially, not a choice

yeah, they really are. people seem to forget that you can simply start a local web server, and direct the user to visit http://localhost:8080. here is one in Go, literally 8 lines of code:

    package main
    import "net/http"
    func main() {
       http.HandleFunc("/", func(w http.ResponseWriter, _ *http.Request) {
          w.Write([]byte("hello world"))
       })
       http.ListenAndServe(":8080", nil)
    }

[mgerullis → 38]

Wow thanks, I really needed to see a hello world server example

[38 → mgerullis]

you're welcome

[blululu → 38]

This is serious? Generally your app should aspire to having a better user experience than a low end phishing scam. Normal people really don't want to copy/paste a series of random looking computery numbers from one application into their web browser. At best it feels broken and more likely it feels like you are about to get hacked.

[38 → blululu]

yes, I agree. god forbid we ask someone to visit a web site. you are so correct, that is way beyond most peoples ability.

[hit8run → apatheticonion]

Isn’t that what Flutter is solving?