DioxusLabs / DioxusLabs/dioxus

Dynamically load parts of the UI for web/desktop

Open
#5,652 0 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.