EGui/WASM = The New Mobile App Standard

[thomas992]

We already have a ubiquitous way to send C++ or Rust code to mobile phones in a secure way it is WebAssembly. WebAssembly could be updated to be applications on both iOS/Linux. Quick diagnosis of Apple and Google are doing.

Apple - unrestricted native applications

Unprecedented that a proprietary computer software company is expecting application developers to remake their application specifically for less than 10% of the market. Looking at hotfix code in user interfaces on the web made for Apple devices their computers interact different across the internet.

Google - Java virtual machines

Android applications are generally garbage, slower to load than iOS apps. Java/Kotlin nothing more to talk about.

Linux Future - WebAssembly

WebAssembly would open applications faster than Android in a sandbox environment. Real programming languages instead of the Java or Apple nonsense.

Rhai support

[stnbu]

[disclaimer: totally ignorant, but]

I feel like a missing thing, on any device/platform, is a kind of "wasm viewer". You can get most of the way there by picking one of several browsers, opening a separate window, undoing all the usual browser menu and UI garbage...

I guess Chrome "Apps" are what I'm thinking of, roughly.

It'd be nice if, for any platform you care to pick, there is a nice "wasm viewer" that does the above, more or less, but isn't a whole dern web browser that you have to install.

Does any of that make sense? I'm ready to blame myself if not.

And in the case of this fancy dedicated native application, wasm can still be "sandboxed", but YOU can decide what is plumbed up and what is not. You can have USB, bluetooth, direct disk access... whatever arbitrary thing you like... defined as a layer between your OS and the wasm "sandbox" provided by this hypothetical app. It might be something like a hypervisor, in the sense that it has complete control over the world view of whatever is running "inside".

So, this hopefully-simple app can be compiled for linux, mac, android, iOS ... ;-)

No idea what kind of gatekeeping exists for the various platforms (apple store would be an example of the most painful kind), but that's not a technical problem, and it only needs to be solved once. You just need to install "the iphone wasm viewer thing".

"That's so crazy it just might not work."

[thomas992]

According to the WASM Website clients include every major web browser I would expect mobile browsers to already support or soon to support WASM W3 specification Since writing this I learned of (dot NET Blazor and MAUI)[https://docs.microsoft.com/en-us/aspnet/core/blazor/] but I am skeptical of the Microsoft branding creating a walled garden for pre-existing software, it forces me to install Windows to compile to mobile. WASM seems like something that will HAVE to be adopted by the mobile operating systems as WASM gains a market share in the web space.

[coderedart]

as much as i like egui, its not the first thing that i think of mobile UI toolkits. battery life / native integration features like notifications or gestures / god tier text rendering / a decent number of pre-existing widgets / components etc.. are very important which egui doesn't provide by itself.

wasm is still not ready today. not even close. wasmtime / wasmer have probably gone through multiple designs at this point. the interface types proposal also changed with the component model. witx being abandoned for the new wit. for all the hype, there's still no stable proposal for WASI standards.
https://github.com/WebAssembly/WASI/blob/main/Proposals.md reference. out of phase 0 - 5, most proposals are still in phase 1 / 2.

wasmer is cool for when it is self contained serialized input / output like serverless functions / computing, but interaction with external world directly is pretty hard right now. not to mention it would still be hard to make rust <-> wasm bindings without a stable ABI. I know because i looked around for a plugin system to let mods use egui API. apparently, to expose bindings to wasm, you need to back to good old extern C bindings with no_mangle. wasm_bindgen is primarily for rust wasm <-> Js .

until component model becomes mainstream, wasm cannot really interact with outside world smoothly.

[stnbu]

Wow. I know I'm in the "everything's a nail" phase of my wasm fandom. that's a super informative response and a good calibration. Thanks!

I literally only learned the word "WASI" a few days ago :-)

[thomas992]

Looks dot NET is the only way to avoid relocating to WASMTime.

[coderedart]

@stnbu WASI is coming. the filesystem and other posix stuff is mostly done for mainstream targets like linux / windows. but they are all blocked on how the "interface" should be represented.
so, basically like C headers, you want a file to represent what objects / functions a certain wasm functionality exposes. with C, you usually compile / link at the same time, but still leave some dll / so links open in the final binary. when the OS loads the binary, it makes sure to dynamically link all those types / functions for the binary so that it can run / use them. that's what wit (wasm interface types) files are for Web assembly in general. and rust / other languages will use that file and assume that those objects / functions will be available somehow at link time (before you instantiate a compiled wasm module, you first provide the necessary imports for linking. wasmer / wasmtime both do this).

once that header syntax is standardized. the rest is just rust <-> wasm tooling which will develop at a rapid rate (as most of the webassembly is moved forward by rust devs and organizations already in rust foundation who are betting in rustwasm).

here's the issue of standardizing wit syntax WebAssembly/WASI#484 , here's the discussion for how to support extra markers for types and their contents to enable customization during code generation (languages bindings generated from wit files) before standardization (like taking arguments by value / reference which exists in rust, but might not exist in C / python or to mark the types Clone / Copy etc..) and finally the final design of wit-bindgen bytecodealliance/wit-bindgen#214 which has been the reference (well , most wasm stuff reference impl is in rust) impl of generating bindings from wit files to a particular language. you can see it live online https://bytecodealliance.github.io/wit-bindgen/