Live data from Hacker News

Web browser as GUI, with your preferred language in the backend

github.com

111–120 of 187 posts

Re: Web browser as GUI, with your preferred language in the backend

#111

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 (…

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

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

>

Re: Web browser as GUI, with your preferred language in the backend

#112

Technically interesting, but no thanks. Imagine a Firefox user downloading the latest LibreOffice and being greeted with the warning "Better run through Chrome", or writing a dashboard on a small embedded system, and the memory footprint goes like 20x because now you need a browser in between in place of native controls. The idea is interesting but there are so many caveats, and the industry is famous for choosing th…

[deleted]

Re: Web browser as GUI, with your preferred language in the backend

#114

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 (…

[deleted]

Re: Web browser as GUI, with your preferred language in the backend

#115
post #100

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 (…

> 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", n…

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.

Re: Web browser as GUI, with your preferred language in the backend

#116
post #77

Earlier quoted context omitted.

Could it be you forgot how fast native GUIs are? Every WebGUI I used lacks the snappiness of old school native ones.

Native GUIs are fast, but they are not powerful. You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. The web browser gives you a full package with standardized commands to control all those aspects, which is also portable between different implementations. If your rendering needs are limited to a few buttons and a canvas…

> You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features.

Even Java UIs supported dynamic layouts 20 years ago.

C# had a flex box based layout (called flow layout) since 2006.

Re: Web browser as GUI, with your preferred language in the backend

#117
post #79

Earlier quoted context omitted.

You mean that the fornt end devs aren't actually responsible for the rendering, but the browser devs are? Would you apply the same logic to game optimization? That's it's not the responsibility of game devs, and instead we can shift all the blame to the gpu sdk team?

> You mean that the fornt end devs aren't actually responsible for the rendering, but the browser devs are? Not at all. Quite the opposite, in fact. My position is that the browser is fast enough, and that any slowness is exactly the fault of the site devs. You said the browser wasn't fast enough. Previous poster: The reality is that web is fast enough You: No its fuckin not.

Fair.

I took 'web is fast enough' as in 'current state of web is fast enough'. But if we are still sticking to the actual internals of web browsers, i don't doubt they are quite 'state of the art'. It's just the outcome for the end user sucks

Re: Web browser as GUI, with your preferred language in the backend

#118

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 (…

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.

Re: Web browser as GUI, with your preferred language in the backend

#119
post #20

Is this basically Tauri, but with zig instead of Rust? Or are there some bigger, inherent differences? (Besides tauri being more mature, that is). Pretty cool

Very different. Tauri directly embeds/links to the web view runtime, and calls the APIs directly to setup the window. WebUI finds a browser installed or already running, and launches it to a localhost server hosting custom content.

Re: Web browser as GUI, with your preferred language in the backend

#120

Technically interesting, but no thanks. Imagine a Firefox user downloading the latest LibreOffice and being greeted with the warning "Better run through Chrome", or writing a dashboard on a small embedded system, and the memory footprint goes like 20x because now you need a browser in between in place of native controls. The idea is interesting but there are so many caveats, and the industry is famous for choosing th…

This is a replacement for electron/tauri, and should be able to use much less RAM
Post reply on HN