dman-os (Apr 19 2026 at 11:13): dman-os (Apr 19 2026 at 11:13):So I'm thinking about the problem space of Plugins + GUI. Most apps that support this kind of plugins this are usually running on Electron or QT and already have a DOM or JS based surface that they can expose to plugins. I'm not using either technologies and I'm also experimenting with using WASI + WASM as the only plugin surface. I'm trying to figure out how to best approach this problem this world.
A lot of wasm related GUI projects are indeed for browser usecases (with the only exception I found being https://github.com/orca-app/orca). I also understand that wasm-based UI is an explicit goal for was-gfx but I wonder how sensible that'd be in this usecase in the long term. Each plugin having to ship it's full graphics stack in a way even though most won't need that kind of customization.
But then again, basic canvas and input primitives are probably more efficient/easier to express compared to...a full fledged widget tree, reactive state and more APIs across what's effectively an FFI boundary? But maybe host+guest WASI is fast enough?
I guess I'm asking if there's any prior art here I should be looking at. To articulate more, I need plugins that to be able to program small widgets as part of the app's UI across a wasm boundary. I'm using Compose Multiplatform so I can't expose DOM programming. I don't necessarily want to use Compose to render the plugin's API and if I'm going to build this out, I'd prefer to stand on more generic/standard primitive as opposed to directly expose Compose specific semantics to plugins.
So far, I'm just leaning to adapting the wasi-gfx or the browser's canvas and input APIs from the DOM. There are libraries that already target this specific subset of the DOM.
Sorry if this is the wrong place to ask this but I'm not sure where else.
guest271314 (Apr 19 2026 at 15:54):What do you mean by "Plugin"? In general the only _browser_ "plugin"s left are for PDF viewing, if that. Generally, "plugins" in the browser have moved to Web extensions.
dman-os (Apr 19 2026 at 17:48):@guest271314 Plugins as in user code. Many names for this and plug-in is an overloaded concept but...code not avail in the app's source tree but added by users.
guest271314 (Apr 19 2026 at 18:20):If the context really is the browser I think you can use binaryen.js to compile source to WASM in the browser and "plug" that resulting WASM into your application.
dman-os (Apr 19 2026 at 19:52):@guest271314 the context is not the browser but a desktop/mobile app. I meant to write "adopting" instead of "adapt", sorry.
guest271314 (Apr 19 2026 at 20:47):Why is the browser, DOM, and canvas mentioned?
Not sure what is holding you up?
Maybe try a few different approaches for a "GUI", see which works as expected, which don't, for your use case.
guest271314 (Apr 20 2026 at 00:07):Some stuff I've come across during some experiments and trying to achieve my own use cases
dman-os (Apr 20 2026 at 12:35):guest271314 said:
Why is the browser, DOM, and canvas mentioned?
Because most of the prior art for WASM gui is for the browser. If the host offers similar enough APIs to wasm GUI solutions that render to canvas, that's a free lunch.
dman-os (Apr 20 2026 at 12:45):Thanks for that interesting list. I'm already using WASI over wasmtime for running plugin code so I'd prefer the GUI solution to align somewhat with it.
Night_Hunter (Apr 22 2026 at 02:56):@dman-os You might find my iced gui bindings worth looking at. I wouldn't say its the greatest but it does work
https://github.com/n1ght-hunter/igloo
dman-os (Apr 22 2026 at 11:34):@Night_Hunter thanks, looks very interesting and viable. Do you have a write up on this anywhere? Curious to your thoughts on this approach with regards to performance, expressiveness and cross-lang adaptability to name a few rubrics.
My usecase doesn't exactly need winners on those but...there's so many ways you could cut this and I'm very unsure.
dman-os (Apr 22 2026 at 11:39):There's also the question of weather the guests are expected to run on the same GUI solution like Iced or the DOM or do you want them to work across diverse targets. Seems silly and asking for much but cross-platform-including-the-browser is a fad.
Night_Hunter (Apr 22 2026 at 14:29):There is no write up sorry. performance hasn't been tested alot but works pretty well.
cross lang seems to work pretty well. Iced is built around simple functions following the elm style which woulds pretty well anywhere. The way these bindings are written means not everything in iced is possible over wasm but most of it is.
It should be pretty efficient its mainly built around two functions view and update.
view is a function that expects a simple widget tree returned describing the gui. some of the widgets also have a Message param that update is called with on events.
update is another simple function that is called when an event happens and passes in the message.
I did think about rendering to a frame buffer but that meant consuming was alot more work where i just wanted widgets to be able to describe the gui simply in any lang without much boilerplate.
In this case the bindings are purely for iced. i think if you wanted a solution for allowing other gui frameworks it would be better to build out wasi wgpu bindings and just render to a texture then use that in the host gui.
Just fyi these bindings are very experimental and i think could probably be improved quite a bit. I have done some work on updating them to use wasi preview 3. though there are a couple lifetime issues i so far have had trouble with to make the api work how i want.
Last updated: May 03 2026 at 22:13 UTC