You can also press `t` for `tracing` logs which will emit the relevant logs. I'm sure it's something pretty simple / easy to figure out like a wrong version.

It’s retained mode and stays close to the architecture of a React/Svelte app.

On the web, it talks DOM directly. We have SSR, hydration, streaming HTML, and a fullstack nextjs-esque framework to go with it. All done via webassembly.

The async story is great. Our state management is multithreaded and many users are using web workers and PWAs.

We have focused less on building a good multi-tenant story but you can definitely integrate React into Dioxus and Dioxus into React. We’re close to runtime compatible but React core is a shifting foundation to build on.

The API feels closer to solid now but the scope of the project is big and APIs are bound to change. This update, we changed a few things but upgrading is quick. It will be a while before we want to rework interfaces again, and we’ll likely provide codemods at that point.

I think the community is quite large (gaining critical mass for library support) picking up steam, but JS land certainly is going to be much bigger.

The sticky parts were where I needed more complex UI functionality. In the web world you can leverage mature, albeit heavy libraries for graphs and tables. In pure egui, you often need to roll your own and extend the basic features. Depending on how far you go down this road, it may make more sense to work within Bevy's UI entirely.

Dioxus looks like an interesting alternative here, but it also seems to be even heavier than egui, which isn't exactly a lite dependency.

https://dioxuslabs.com/awesome

The contrast is interesting because leptos was the brainchild of an individual (Anglican priest, too, IIUC) whereas Dioxus is venture-backed.

DIY components is rough for basic dev.

My feeling is that if you are going to use a webview, you might as well use Typescript and a battle tested framework.

Gleam looks great. Reading the FAQ, especially why the don't implement type classes, I am a bit worried though that it leans to much into trying to be simple.

Minimalism can work in dynamic languages because they impose basically no restrictions on your types and you can have crazy complex ones for free but in a purely static languages a lack of more advanced type system features can make writing library code very annoying and make the language feel very boilerplaty. The advanced type system features that languages like Haskell or OCaml provide are not purely for academic wankery, some of them are extremely useful. Even Golang had to add generics.

I hope they don't fall in the same trap as Elm did where it got so obsessed with simplicity that super knee-caped the language. I mean the Gleam devs seem already be way more pragmatic. At least it seems to have a decent FFI which provides an important escape hatch.

In Elm-likes you usually need to explicitly need to connect all child components in the model _and_ view _and_ update in a way that ultimately connects all leaf components to the root component. I know that there many Elm proponents that see that as a positive (as that makes execution more transparent). However in practice that usually ends up with either overly shared Message types where logic isn't contained to the widget it belongs to, or a boatload of boilerplate just to do .map operations between a child-Message-type and it's wrapping parent-Message-type.

I think this boilerplate can be solved by some degree with good framework support (and some try), but most Elm-likes don't and it makes scaling projects in them a pain.

To say if it succeeds that it could obsolete all other frameworks is an incredibly bold claim.

.NET already did that, several times over, over many years. Other frameworks still exist because not every problem needs a hammer, and the more use cases you try to solve the more you suffer from the jack-of-all-trades problem.

I’m interested in how this solves for the web and mobile. It references flutter in its marketing - is it doing its own rendering in these scenarios?

If so, it’s DOA for me for a whole host of reasons that have already sunk projects like this a lot of times over.

Then in 99% of cases you find out that those 3 have very few things on common. UI usually has to be completely re-designed for each platform, each has unique features that are not and will not be available on another platform etc.

You'll need to have a shit load if "if os=='desktop'" or even more granular like 'android' etc.

And if your app it not tiny - its just simpler to redo UI in a proper specialised framework.

Nowadays it is literally a very simple issue as existing frameworks are very mature.

> web

Aside from the fact this is for obvious reasons not happening, why would anyone want to replace something that's standardized, mature and effective with a VC-backed UI library with basic features? Because Rust? Sure, if you really, really like Rust for some reason, I can see the hypothetical appeal, but what I can't understand is the desire to throw away the web, which imo is like the 8th wonder of the world. But the DOM, accessibility, rendering, JIT and sandboxing? Starting from scratch on that is akin to building a new OS. And for what? Dislike for JS? Then WASM is the right solution.

And once you "get" The Elm Architecture it feels like you're in a whole different world that is equal parts beautiful and logical.

I think mobile is a different beast best served by native toolkits. But for a lot of people, what they really want is a website packaged into binaries for every platform, so their tradeoffs are different.

For everyone reading this who's considering iced, I'm on Discord daily trying to help newcomers get their bearings. I'm also on Discourse and GitHub but those just happen to be less active.

Rust is great for command line apps, tooling and well systems programming but UI stuff? Sure can be done but it doesn't really play to Rust's strengths.

Tauri at least allows people to use their JS knowledge so it is a much easier sell.

Of course if you just enjoy writing Rust that is fair, just saying it doesn't make business sense for most people.

There are many bindings to other languages[1].

[1] https://wiki.qt.io/Language_Bindings

Dioxus is a full UI kit for Rust. They stick as close as possible to React and even have CSS and Html syntax. But, it's not a web environment.

Dioxus appears to currently use Tauri for the desktop renderer (https://dioxuslabs.com/learn/0.6/guides/desktop/) so it seems like it's a cross-platform framework that uses tauri on the desktop.

However it seems like they to switch to their own html renderer for desktop at some point.

A similar comparison would be Electron and React / React Native.

Tauri is a way to package a web app (e.g. could be react or svelte written in typescript) in a window and interface with rust code.

Dioxus is a way to write web apps (and other applications) in pure rust.

https://freyaui.dev

WRT the other comment - `rsx!{}` is carefully designed to not leak details about the web. RSX is entirely abstract over the element+listener set so you can build whatever you want with it.

DX tries to be "rust only" but basically gives you a macro to write HTML-like components, which are obviously just a shim between layers and the abstraction is leaky. You don't get much from that.

You probably want egui.rs

If the culture of the Rust ecosystem was to publish a 1.0, we would do it. And frankly, I'd really like to have an extra "version" to play with - 0.x.y is quite limiting.

There's a few core things I want to clean up and split out in 2025. If all goes well, we might see a 1.0 next year.

At the end of the day we just use the Rust Struct parser!

It's very similar to JSON or RON if you're familiar.

https://github.com/ron-rs/ron