Dioxus uses the virtual DOM as the core that allows rendering to many different platforms. Yew and Dioxus are somewhat similar but Dioxus represents it's virtual DOM very differently internally. Because of the way Dioxus' virtual DOM is made unlike Yew, Dioxus will never diff the static parts of a component (read more here https://dioxuslabs.com/blog/templates-diffing)
Dioxus is still pre-1.0. We will try to minimize unnecessary changes, but there will be breaking changes between 0.x releases. This allows us to keep iterating to find the best approach. If you are willing to brave some breaking changes and bugs, try Dioxus. If you want a mature framework you might want to choose another project. I don't know of many mature rust frameworks but there are many more mature Javascript frameworks to choose from.
Thank you. That platform status might be moved to the home page, and also updated (e.g., to add TUI, clarify the state of Android, clarify when it relies on a partner project, etc.).
I hope this Dioxus is very successful, since I'd love to be doing all this work in Rust.
i wouldn't leave 0.x until its somewhat complete and stable. I'd be kinda mad as a consumer if it was labeled 1.0 but was missing half the essential features and 2.0 came out 2 months later (also incomplete)
Right now Dioxus uses webview for all platforms except TUI and blitz.
Why?
Choosing to use a webview renderer initially allows us to support many platforms quickly with fully featured renderer and accessibility built in. Comparing to Flutter targeting a web based model also allows our web renderer to render using elements instead of a canvas, and has a much smaller bundle size.
Dioxus is render agnostic and the plan for the future is to invest more time into blitz (our native renderer). This will allow us to achieve native performance on desktop and mobile.
Makes sense, thanks. What do you mean by native renderer, is it like React Native where Dioxus calls are transformed into native system UI calls but keeps a JS bridge (which can sometimes be slow), or like Flutter which draws every pixel on a custom canvas but which is able to be compiled to machine code?
So I use Flutter currently and it seems like they're doing quite a bit of work to get everything to work well together on all of their platforms, with varying levels of success. How do you plan to handle all of that complexity as well, and compete with them, so to speak? I don't mean compete in a negative way but as a developer, I should be able to look at the pros and cons of all these Flutter-like frameworks popping up in different languages and choose the best one.
Dioxus desktop uses Wry (one of the libraries Tauri is built on) which requires WebView2 on windows. You can install this on windows 7 or include a bootstraper. All windows versions after 7 have WebView2 pre-installed. In theory, 32 bit machines should work out of the box although I haven't tested it.
Dioxus runs its test suite on modern versions of windows, macOS and linux
Building an application that works with TUI, web, and desktop is possible but there are some differences you need to keep in mind. The TUI renderer has a different scaling factor than the web renderer. One pixel is one character and Widgets have start with a capital letter with the web renderer, but for the attribute and elements that the TUI renderer supports the goal is to behave as close to possible to the web implementation. There are some differences that will likely remain because of the differences of the terminal platform, but we would like to continue working on minimizing these differences in the future.
The homepage is built with Dioxus so it uses Javascript and WASM right now. Dioxus does support ssr (https://docs.rs/dioxus-ssr/latest/dioxus_ssr/) which could be an option to support better progressive enhancement in the future
