What is the (minimum) application footprint?

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.

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

Looking for screen shot and capability description of the TUI renderer - how likely is it to be able to cross build the same UI across renders?

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.

I assume you can easily case for rendering specialization?

You can use rust's feature flags with one flag per renderer to specialize based on the renderer

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!

How's support for older systems? Will apps run nicely on older 32bit systems or older windows versions? What does the platform testing look like?

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

Here is a rough roadmap: https://github.com/DioxusLabs/dioxus/blob/master/docs/guide/...

The major projects for the next year are to improving the native render (Blitz), the full stack framework (Tokamak), Router, and subtree rendering.

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.

why not break the 0 and do major releases whenever you break something?

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)

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.

For Dioxus web and desktop (webview), we provide a use_eval hook to execute Javascript that should allow you to use interface with MIDI

very cool however

wifi scanner is named bluetooth scanner and doesnt show any networks. im typing this on wifi. also code has 15 levels of indentation.

weather app search doesnt work

e-commerce cant fake-buy anything

dog-app lit says instagram, nothing is clickable, tons of deeply nested jss

The frontpage doesn't mention microcontrollers. What's your plan for them, and what kind of microcontrollers will you target (memory and performance)?

I'm assuming there is a plan given "run anywhere".

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.

Thanks for the reply.

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.

Will definitely dig deeper, looks interesting.

[1]: https://slint-ui.com/

How do I import my UI files made with Design Studio?

How is the accessibility? I can't find it mentioned anywhere on your pages.

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.

I pressed the play button the the first example on the guide page and it gave an error about a missing macro.

The rust docs don’t run UI libraries with any helpful output.

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.