This demo shows how to load components dynamically and execute them safely inside a single web app—without iframes or limited JSON protocols. Components load at runtime, allowing the interface to expand on demand with new capabilities. It adapts to specific needs without getting bloated, resorting to lowest-common-denominator components, or excluding niche usecases. For visual consistency and safety, the runtime compiles Tailwind CSS and DaisyUI directly inside the browser while sanitizing all component HTML and CSS. Security relies on a strict capability-based model: the runtime explicitly restricts component access to specific allowed resources (such as clocks, randomness, and event output channels). By combining dynamic loading, in-browser CSS compilation, HTML/CSS sanitization, and capability-based security, this approach creates a flexible, secure foundation for generative AI frontends.

wait can WASM do DOM stuff?

yes? github.com/marianoguerra/tutuca-moonbit/blob/…/ffi.mbt

ok, thats a no in reality, its crossing the boundary every DOM call. Which I guess would be where there is a risk of some contamination of the WASM's purity.

it was never the plan to have "native dom bindings", this always "worked" the same way calling some js functions cross to c++

What's stopping a booby trapped component stealing Ur cookies and sending them afar. The wasm module is sanatizing the expressiveness down to a safe subset and then painting that rather than raw DOM?

yes, I implemented the html sanitizer logic while parsing the views and then run a subset of it on dynamic attributes whose values I can't sanitize at parse time developer.mozilla.org/en-US/…/HTML_Sanitizer_API

Yeah interesting

just made the bootstrapping declarative, this are the only imports of the todomvc component

OK I was plainy with it with my bot

Any view attribute whose value evaluates to a list or map becomes Data(Json) (render/values.mbt:18). UrlFilter then explicitly skips it — "A structured value is not a URL string" (vdom/filter/url.mbt:232). But set_prop routes Data straight to property assignment before the never_assign/has_property gates (vdom/to_dom.mbt:78), and the browser glue is an unguarded write: try_set_prop: (o, k, v) => { o[k] = v } (app/wasm/loader.mjs:113).

So for a guest with field links: list<string>:

<a href=".links">click</a>   <!-- links = ["javascript:alert(document.cookie)"] -->

a.href is assigned a real JS array (Data → JSON.parse, vdom/wasm/ffi.mbt:51), the setter does ToString, and a one-element array stringifies to its element. Live javascript: URL in the host's origin, untrusted tier, no host cooperation needed. href survives the lowercasing that saves innerHTML from the same path, because href is the lowercase IDL name.

but this is fixable I think.

yep, I care mostly that the design allows it to be safe, to be production ready it needs a couple of rounds of pollishing

yeah its a good idea, but I will probably still feel safer with iframe + postMessage

yep, but those aren't components 🙂

yes this is true

just be carefull that one of the miniapps is not an artifactory iframe with internet access 😛