Pluggable backends for react-native-like uses

[mike-marcacci]

Description

React native is a fantastic concept, but is seriously complicated by implementation details which are there to prevent javascript from causing a performance bottleneck. The RN team is currently working on a re-architecture (referred to as "fabric" internally) which should alleviate many of the tremendous issues with the current approach, but it is still subject to the constraints that come with composing the interface in javascript.

It seems to me that a similar framework written in a lower-level language could achieve superior performance and portability with less complexity.

Rust is the perfect modern language for such a task, and yew has already done a tremendous job in building an ergonomic "component centric" (react-like) UI framework for web targets. I'm curious if there's any interest in making backends pluggable, so that yew can be used for native targets?

[jeffvandyke]

I wonder how the fascinating Dear Imgui project (Rust wrapper) would work as a backend, given its immediate-mode render style. It even works in WebAssembly rendering to canvas, and is a pretty small, yet capable and themable library.

The immediate mode rendering style might mean everything would have to be re-rendered every update, but Yew components could still be very useful for app structure, message handling, and saving some computed state in intermediate components. The absolute best-case would be to somehow store the frame buffer output of a "pure-imgui output" (html-like components would have to be invented like react-native) and simply gpu-draw it in place if the final output would be the same.

[kinthaiofficial]

Pluggable backends for React Native-style targets is a fascinating design challenge — the core tension is that Yew's architecture is tightly coupled to the DOM API via web-sys.

A few design directions that could work:

1. Abstract renderer trait (most ambitious):

// Hypothetical trait for pluggable renderers
pub trait Renderer {
    type Node: Clone;
    type Text: Clone;
    
    fn create_element(&self, tag: &str) -> Self::Node;
    fn create_text(&self, text: &str) -> Self::Text;
    fn append_child(&self, parent: &Self::Node, child: &Self::Node);
    fn set_attribute(&self, node: &Self::Node, name: &str, value: &str);
    fn add_event_listener(&self, node: &Self::Node, event: &str, cb: Box<dyn Fn()>);
}

Problem: Yew's component model (hooks, context, signals) is deeply intertwined with DOM event bubbling and the browser's task queue.

2. Server-side rendering target (more achievable):
Render to HTML string for SSR — this is what Leptos has done successfully. No DOM required, just string building.

3. Native bridge (like React Native):

Yew components → JS bridge → Native views (iOS UIKit / Android ViewGroup)

This requires a mapping layer for every component type. React Native had years of investment in this.

Pragmatic path: Yew → WebView (for mobile via Tauri/Capacitor) is much more achievable than a native renderer. You get "write once" across browser + mobile via the same HTML/CSS rendering. The performance gap vs native is real but acceptable for most apps.

What's the target platform you're most interested in? Embedded, native mobile, or server-side?