[jkelleyrtp]

Not sure if you grok 100% what we're building.

Dioxus-web is basically React/SolidJS/Svelte. It writes to the dom and handles dom events just like any other web framework.

Where Dioxus differs is on native platforms, where we basically try to provide a Web-like API to native widgets. Think electron but you're not shipping a browser, just the rendering engine (that fits into 3.5mb!).

Our users on native platforms like being able to access system APIs with no intermediary. You can spawn threads, talk unix sockets, call FFI, etc. Stuff like electron is heavy, slow, and puts an IPC boundary between your UI and the system. We're trying to dissolve that.

Long term we want to expose JS and Python bindings for our native engine - Rust is not necessarily the "killer feature" there.

[klabb3]

> Not sure if you grok 100% what we're building.

Yup, fair point. Let me respond with a bit more context.

> It writes to the dom and handles dom events just like any other web framework.

So you have a DOM, but if the target renderer is not webview or browser, you create a DOM in some other way?

> Think electron but you're not shipping a browser

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.

> Our users on native platforms like being able to access system APIs with no intermediary. You can [...] call FFI, etc.

This is so difficult, and I applaud you for taking on the challenge. Rust is a decent choice for FFI, but still, FFI is a mess with largest common denominator being C. In the Tauri community, most users are intimidated by Rust alone. The number of devs who could fix segfaults related to Objective C bindings, wrangle Win32 syscalls and knew enough GTK could be counted on one hand (maybe one finger). So in short, can is doing a lot of heavy lifting here. That also means users have to come up with the cross-platform API surfaces themselves, right?

[jkelleyrtp]

> 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

[klabb3]

Ok, sounds more reasonable now. Being DOM-like or DOM-compatible sounds much preferable, even though I don't see the reason to abandon webviews - you get 30 years of battle-tested tech for free + massive ecosystem.

> 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.