Creator here - ask away! We added a bunch of new features to master that haven’t been released yet, like liveview, WGPU renderer, instant hot reloading, autoformatting, and more.
What's the maturity of Dioxus right now, and what's the roadmap for that with rough dates?
After flipping through the different target platform info, looks like the front page claims are partly aspirational, not currently implemented or integrated.
(Reason I ask: Coincidentally, I'm just starting a new TUI project with Cursive tonight, but looked at Dioxus when I saw it on HN, because I'd love to not have to keep relearning different UI toolkit bureaucracies, for also doing Android&iOS, Web, and Linux desktop. But I've seen countless cross-platform GUI toolkit efforts over the decades, and unclear how mature Dioxus is going to become.)
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)
Maybe it's because I'm not very experienced with web development but I have a hard time wrapping my head around this and unfortunately the tutorials didn't enlighten me either.
How is this used on a very high level? Is this a pure front-end framework? So, let's say I write an app using Dioxus. Then the input are .rs files but what is the output? For desktops: an executable? For web: a folder with HTML/JS/CSS?
And how does this work under the hood? Is it drawing all UI elements from scratch using Canvas/WebGL? Or is it more like a translator that fills a regular DOM at runtime and uses that for rendering?
Dioxus is HTML native so it speaks in native HTML elements to solve the flutter problem.
It’s written in Rust so it doesn’t need a JS engine which gives it this huge portability. Your intuition on the outputs is correct. For the web, you get a folder of HTML, CSS, and the tiniest amount of bootstrapping JavaScript. For most other platforms you get a small binary that is self contained.
Hi, home site doesn't run without enabled js jit. Are there any plans to not rely on jit or that's not possible ? Or it's caused by 3rd party plugins ?
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
It uses HTML as the base so accessibility is built right in. As we stray into more custom solutions, then we’ll use accessibility kit, but since in the short term it’s all rendered straight to the DOM, we get it for free.
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
What’s the story surrounding cross platform MIDI support? I don’t expect it to be a priority but it’s something that I was looking into with Flutter/Dart, it would be killer to have.
What do you think the main challenges are with implementing LiveView? How do you think it will ultimately compare to Phoenix for web apps, and more generally? It looks like a good project!
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.
On the web, you can get the final bundle down to about 60k gzipped, which is comparable to react.
The average desktop/mobile binary is less than 2mb, but that’s with zero size optimizations to shrink the output. You can certainly get less.
Dioxus runs on a native thread and renderers into the webview, so there’s very little JS footprint and the render resources are shared among all webview on your system.
I haven’t experimented with it, but it’s entirely possible to run on a raspi with webkitgtk. We’re building a native renderer with WGPU and already support rendering to the terminal.
> Dioxus runs on a native thread and renderers into the webview, so there’s very little JS footprint and the render resources are shared among all webview on your system.
So I need to have some sort of WebView library pre-installed? What WebView would that be on, e.g., Linux? And is it possible to include it in the build to create a standalone binary? If so, how much would that make the binary size go up?
In my experience, relying on a system-wide WebView is a recipe for desaster.
For most platforms relying on the browser’s webview is fine since most platforms ship with a browser! But you can always specify WebKitGTK as a dependency which I think is a one time 2GB cost.
You can already run Dioxus on an SBC. I’m not sure it’s realistic to run on an stm32 without some real limitations. IMO “everywhere” means everywhere in the physical sense, like desktop, mobile, server, AR/VR, handhelds, etc. we can’t support something like a Pic-8 ever, so it’s not worth trying to qualify that.
Given Qt, Slint[1] and similar, and Rust being supported on a lot of embedded platforms, it didn't seem out of place to imagine it on an higher-end STM32, ESP32 or similar.