| > So you have a DOM, but if the target renderer is not webview or browser, you create a DOM in some other way? Yes - we have a project called Blitz which is trying to emulate just the DOM without the browser. It's built on Servo/Firefox tech. https://github.com/dioxusLabs/blitz > The browser is already there, and called webview on all major platforms. I'd say Electron is popular for maturity reasons, that architecture makes limited sense even if you are using web. Tauri would be a better comparison. The default dioxus desktop/mobile renderer uses the system's webview for exactly this reason. The blitz stuff is still young but is planned to eventually replace the webview renderer. Fortunately, webviews are on many platforms already. > .. That also means users have to come up with the cross-platform API surfaces themselves, right? Yes, but this is a challenge in every cross-platform framework. Flutter has pub.dev, react-native has expo modules, etc. In 2025 this will be a huge focus for us, and in all likelihood we'll just find a way to bind to existing widgets in the respective ecosystems. Easier than to try and bootstrap a pure-rust ecosystem (though it would be nice). Projects like our SDK do this, but the surface area is quite small when compared to what we eventually want to support. http://github.com/dioxusLabs/sdk |
> Yes, but this is a challenge in every cross-platform framework. Flutter has pub.dev, react-native has expo modules, etc.
I don't know about those, but I can say with confidence (from experience in Tauri) that the native integrations are absolutely crucial. Getting the API surfaces right, the plugin <-> core boundary right (with versioning, etc). It's hard as hell - do lots of research and try to learn from their mistakes.
> Easier than to try and bootstrap a pure-rust ecosystem (though it would be nice).
One thing I learned from the Tauri FFI story is that Rust mattered very little in the sense of hermetic and safe development. The boundaries get ugly and safety can be violated simply by misunderstanding the model of the other language (for instance, I've had an Objective C autorelease bug that caused a segfault on `drop`).
Investing in good infra, testing, debuggability around the FFI boundaries would have been the right thing to do. You often run into the same kind of problems in different "plugins" and features.