Really impressed by the depth and breadth of this project, well done!
A particularly interesting part is the socket layer inside the browser. Other people solving this problem have previously used a proxy to a server that does the real socket implementation. This means you can't have a "browser-only" solution.
That does have some major caveats of course: some headers will be totally ignored by the browser due to web restrictions, some will be added/overridden (e.g. user agent), and CORS will apply (which will seriously surprise most Linux tools!).
Still, very neat, agreed. Almost certainly the best you can do without having some kind of backend proxy running on either the server or the user's own machine.
I've been looking for a way to run GUI applications remotely for a while, specifically on a wlroots compositor. Projects like this (maybe one day) and https://github.com/udevbe/greenfield are interesting since they essentially make access universally accessible.
Dear ImGui is small and fast enough for running in browsers (it will add up to a few hundred KBytes of WASM byte code). If this is too much "bloat", there are smaller, but also less powerful alternatives like microui: https://github.com/rxi/microui)
I don't know about GTK, QT, and the like, but there's a whole budding ecosystem purporting to solve it WASM-native.
Dioxus [1] and about a dozen other libraries are attempting to be write-once, deploy web, mobile, desktop with native performance. They adopt a React-like component UI.
The Rust ecosystem is full of stuff. There are lots of different approaches too - immediate mode drawing, canvas drawing [2], etc.
Choosing a winner is the hard part. There are too many projects and no clear community-elected leader.
GTK+ has Broadway to render GTK applications to the web browser. Qt has some ActiveX support, but you don't want that. Java/Kotlin has a bunch of frameworks, like TeaVM to run .JAR files in the browser, or Vaadin to write web GUIs like you would desktop applications.
I think most languages that have been around for more than five years have some kind of GUI framework that'll run in the browser.
Very worst-case scenario, you could compile a Windows executable and run them in BottledWine :P
I wrote a simple chord finder for learning to play guitar with it pretty quickly [2], and would use it again to solve a problem like this, though I'm told immediate mode UI frameworks aren't good for things other than quick prototypes, or in my case, scratching a quick itch.
Flutter is looking to do so, it was just waiting for WASM-GC support which has now shipped on Chrome. Rust is another good one as the other commenter stated. I personally use Flutter for the UI and Rust for the business logic, using libraries like flutter_rust_bridge and rinf as FFI between the two.
I'm curious how flutter apps will do on visionOS. I suspect apps using native widgets will be great because the OS can change to UX for the app. Flutter apps on the other hand may all have to be re-shipped since they're doing it by hand.
Not exactly what you are looking for, probably, but Leptos[1]. Dioxus[1.1], Yew[2] and almost all "frontend web frameworks in rust" run primarily/only on WASM. Larger list here[3]
I’ve used ImGui with success. I specially was also using webgpu so I used the glfw+webgpu backends. I had to fix a few issues in both halfs of the backend and there remain some little interaction bugs (mostly because browsers capture some keychords and mouse actions and you have to work around a number of them).
ImGui makes a specific design choice and isn’t amazingly documented. I don’t think it’s a good choice for larger scale apps. But good for tools or UIs in games, etc.
Accessibility is a nightmare with pretty much anything skipping browser layout of course.
Wow, haven’t seen Bochs mentioned since I was doing hobby OS development 15 years ago. I guess there’s not a ton of emulators that don’t use JIT or hardware extensions these days.
Downloading a 50MB WASM blob to run an emulator to boot a Linux kernel and then start an HTTP server to handle a single request is utter madness, which is probably why this will become popular to do.
There is support in Docker to run wasm-wasi binaries directly (see: https://wasmlabs.dev/articles/docker-without-containers/). The downside compared to OP's approach is that whatever you're running has to have already been compiled to wasm-wasi. The upside would be much faster execution time (no emulation overhead for x86).
Readit News
A particularly interesting part is the socket layer inside the browser. Other people solving this problem have previously used a proxy to a server that does the real socket implementation. This means you can't have a "browser-only" solution.
The author has solved this (for HTTP/S only) by proxying HTTP requests and then re-creating them as fetch requests (details here: https://github.com/ktock/container2wasm/tree/main/examples/n...). I'm very interested in using this approach for my own project Runno (https://runno.dev).
Still, very neat, agreed. Almost certainly the best you can do without having some kind of backend proxy running on either the server or the user's own machine.
Powered by a x86->Wasm JIT. Technical writeup: https://labs.leaningtech.com/blog/webvm-server-less-x86-virt...
I got as far as "powered by cheerpx", which leads me here: https://leaningtech.com/webvm/
And I'm also guessing that you guys just allow free use of the compiled wasm for demos such as this?
I've been looking for a way to run GUI applications remotely for a while, specifically on a wlroots compositor. Projects like this (maybe one day) and https://github.com/udevbe/greenfield are interesting since they essentially make access universally accessible.
- https://floooh.github.io/visual6502remix/
- (start the emulators by clicking the little "UI" icon to get the debugger UI) https://floooh.github.io/tiny8bit/
- (start by clicking the little "UI" icon) https://floooh.github.io/sokol-html5/
Platform abstraction is handled through the sokol headers: https://github.com/floooh/sokol
Dear ImGui is small and fast enough for running in browsers (it will add up to a few hundred KBytes of WASM byte code). If this is too much "bloat", there are smaller, but also less powerful alternatives like microui: https://github.com/rxi/microui)
Dioxus [1] and about a dozen other libraries are attempting to be write-once, deploy web, mobile, desktop with native performance. They adopt a React-like component UI.
The Rust ecosystem is full of stuff. There are lots of different approaches too - immediate mode drawing, canvas drawing [2], etc.
Choosing a winner is the hard part. There are too many projects and no clear community-elected leader.
[1] https://dioxuslabs.com/learn/0.4/getting_started/wasm
[2] https://www.egui.rs/#demo
I think most languages that have been around for more than five years have some kind of GUI framework that'll run in the browser.
Very worst-case scenario, you could compile a Windows executable and run them in BottledWine :P
Deleted Comment
I wrote a simple chord finder for learning to play guitar with it pretty quickly [2], and would use it again to solve a problem like this, though I'm told immediate mode UI frameworks aren't good for things other than quick prototypes, or in my case, scratching a quick itch.
[1] https://www.egui.rs/
[2] https://kelvie.github.io/chord-finder/
[1] https://github.com/leptos-rs/leptos, https://github.com/dioxuslabs/dioxus
[2] https://yew.rs/
[3] https://github.com/flosse/rust-web-framework-comparison#fron...
ImGui makes a specific design choice and isn’t amazingly documented. I don’t think it’s a good choice for larger scale apps. But good for tools or UIs in games, etc.
Accessibility is a nightmare with pretty much anything skipping browser layout of course.
winit: https://github.com/rust-windowing/winit
https://ktock.github.io/container2wasm-demo/
But at the same time, please tell me this is not the future of software packaging.
Everything is on track.
Ripley: Yes, there are, aren't there?
Newt: Why do they tell little kids that?
Ripley: Most of the time it's true.
---
But yes, I do believe this has a strong, serverless future.
Then I am all for it.