Wasi support

[SamuraiCrow]

I noticed on Wasmer's Slack channel that there is already an attempt at making bindings for Wasmer to use React Native. The code doesn't appear to have been publicly posted on the guy's GitHub account but he also seems to be learning Rust as quickly as I am.

This leads me to the question: Would such a binding be sufficient to wrap with macros to supply a GUI for the mobile version of GXI until a better solution is available?

[aniketfuryrocks]

any widget-based graphics library can easily be integrated with gxi-rs

[SamuraiCrow]

Okay, that's cool.

[syrusakbary]

Adding @NathHorrigan to the thread, as he has been working on iOS integration for Wasmer

wasmerio/wasmer#2516
TL;DR: the PR is already capable of running Wasm with Wasmer in iPhones :)

[SamuraiCrow]

Thanks! I should have done that myself!

[aniketfuryrocks]

After researching and trying out different native widget frameworks with wasi, no directions point to a successful build. This is not a limitation with gxi but with wasi as of now. (As far as I know)

Possibilities:

1. If WebGL becomes a thing on wasi, then something like flutter-core can be used with gxi, to provide an easy-to-use UI component system, with minimal overhead.
2. If native calls become a thing then, native widget systems like gtk can be used without issue.
3. Otherwise an extension of wasmer has to be built which switches wasm files depending on the host system, but it will defeat the purpose of wasm since you can't use wasmer inside wasmer.
4. Option 1 and 2, seem to be valid options that might become a thing with time.

As always if the community brings in a widget system or any method which can create a platform-specific or independent window then it can be used with gxi

[SamuraiCrow]

Ok. So WASI basically needs a new subtarget for each OS to get its native platform code in there. I guess that's not too surprising that WASI was designed to target servers.

[aniketfuryrocks]

I was thinking hard about this lately. Now I think the best solution to this problem is by creating a wasi extension. the code will use all react-native-like components and compile them to one wasi executable. To execute this, you'll need a specific runner supporting our version of wasi extension. Similar to how java works. I think this idea is quite interesting to work on. The runner will convert those wasi extension calls to platform-specific GUI calls.

This will allow features similar to react-native. Like on-the-fly updates and one app for multiple frontends. The developer might also opt into compiling his code to a native executable.

[SamuraiCrow]

Cool. I'm hoping for a somewhat Java-like WebAssembly environment. Haiku and AROS are cross-architecture operating systems that are very compact and fast. Since they are cross-architecture, they currently require source code be made available to add new architectures as they emerge. Java wasn't originally open-source so it only spread to the companies that implemented their APIs. The VM was easy to implement as open-source but the Java Classpath was more difficult.

Object-oriented frameworks are very reusable but bindings to operating systems are often hard to come by. Would the VM for GXI be minimal cost abstractions? I prefer the Rust approach to the Java one, if possible.

[SamuraiCrow]

Got my wires crossed in my previous post. What I started out to say was that because Haiku and AROS are such lightweight operating systems, would it be possible to keep abstraction levels so light-weight that they'll run like native code? I like portability but if it comes at too high of a cost, as Java's Classpath did, it will likely be ignored by most. I want to provide an escape route for big, heavy modern systems.

I've pitched using WebAssembly as a cross-architecture package system but got mixed reviews. It seems like it will be a lot of work to some. I think it will be less work than trying to limit all software offerings for Haiku as being only open-source. A bytecode will allow support of all architectures at once regardlless of the distribution model and source code license.

I tried figuring out a way to do it in AROS but it was definitely too much work. The closest I could come was Andreas Falkenhahn's Hollywood which has a cross-platform plugin called RapaGUI. It defines its GUI as an XML file that gets parsed at runtime. It's not so fast but at least it works. It is not Flutter by any stretch of the imagination though.

[SamuraiCrow]

The WebAssembly Micro Runtime seems to have such a WASI extension now. I thought I'd send a "heads up". Their example GUI is based on LVGL if you'd like to take a look.

[SamuraiCrow]

Just a follow-up on bytecode API designs: WebAssembly/WASI#501