DioxusLabs / DioxusLabs/dioxus
Dynamically load parts of the UI for web/desktop
- Dominant language
- Rust
- Stars
- 39.1k
- Forks
- 1.9k
- Avg merge
- 4d 10h
- Merged PRs (30d)
- 4
Description
## Dynamic UI Loading / Plugin Architecture: What is possible today?
### Use Case
I want to build an application that can dynamically load parts of the UI via "plugins" at runtime (think of loading "VSTs" in a digital audio workstation or dynamic widgets in a dashboard).
### Ideally:
* Web: Load a separate `.wasm` file from a URL on demand and render it inside a specific container.
* Desktop: Load a native compiled library (`.so`, `.dll`) from the file system.
### My Understanding of Today's Building Blocks
From what I can tell, we have a few pieces of the puzzle available:
* Iframes (Web): Works for isolation, but feels clunky and limited for deep UI integration or shared state.
* (dioxus) `wasm-split`: Great for code-splitting a single crate, but doesn't seem to support loading completely separate, independently compiled plugin crates at runtime.
* Targeted Launching: We can launch a Dioxus app into a specific DOM node using custom root IDs.
### Am I missing something?
To make true runtime plugins work cleanly, it feels like we are missing an ergonomic way to export standalone components from a library crate and a safe lifecycle API to load/unload those binaries dynamically.
Is a decoupled micro-frontend or dynamic plugin architecture currently achievable with Dioxus without fighting the framework? If anyone has successfully implemented a pattern like this (especially across web and desktop), I’d love to know how you approached it!
### Related Issues?
https://github.com/DioxusLabs/dioxus/issues/540
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading related issue #540 and the issue's references to wasm-split, custom root IDs, and iframe-based integration. Before implementation, turn the feasibility question into a concrete proposal or minimal reproduction that defines supported web and desktop plugin boundaries, lifecycle behavior, and what a successful loading pattern would look like.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, wasm
- Domain
- desktop, frontend, web-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100