I'd like to report my experience trying out this release.
I did a cargo install. I then used the dx command line app to create a new project. After initialization I ran dx serve in the directory as instructed, but it gave me a compiler error with seemingly no feedback on what specifically went wrong. And again, this is for a hello world app that they generated for me. I'm unsure how to obtain more information on why it failed.
I feel like I'd have more insight and ability to debug this if I were trying to compile using a standard rust workflow rather than their CLI tool.
You can press v to enable verbose logging, but this doesn't add information which provides clarity to me. Here's the compiler output with verbose logging, though heavily edited to be readable in this HN comment box
There is a weird issue with `cargo`'s output that not all errors get emitted as an "error" - I just kicked off a new `binstall` build `cargo binstall dioxus-cli@v0.6.0 --force` that fixes the filtering issue.
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.
I had the same problem, but it turned out to be a missing dependency: my webkit2gtk was 4.0 instead of 4.1. Another one, to my surprise, was xdotool.
Why does a Linux webview app built with Dioxus require it? I'm asking, because software inserting simulated HID inputs to arbitrary windows is not exactly my cup of tea. ;) And xdotool doesn't work on Wayland anyway, by design. Apparently there are similar programs for Wayland, but AFAIK they require the user to belong to the input group, which in turn gives any app run by such user access to /dev/uinput - a security risk.
In general, though, Dioxus looks interesting and I wish you all the best in your endeavour!
I've been interested in Dioxus, Leptos, egui, etc. for awhile, but I have to admit I don't know the technical workings of the framework.
On desktop/mobile, does Dioxus run as a native app? Is it an immediate mode renderer like egui? How do you style it? Or is it JavaScript + webview/electron?
On the web does it run as a WASM binary against a canvas renderer, or is it write to DOM? How does it talk to the DOM? WASM, JavaScript transpilation, etc.?
Can you do multithreading on web with web workers? Is the async story good? HTTP/gRPC clients?
Do you have to build your entire app in Dioxus, or can you incorporate other web (eg. React) apps? Can it talk to JavaScript?
How solid is the API now? Is it going to change a lot in the near future?
Do you think it'd be trivial to stuff a Bevy game inside of a Dioxus shell? We've thought it might be easier to prototype the UX outside the engine, especially since web is a deployment target.
How big is the community?
Looking into this for a project soon, so if any of the Dioxus devs can answer some of this, I'd super appreciate it. (Sorry for all the questions which may already be answered in the FAQ/docs.)
Dioxus is similar to modern React Native in architecture. Your rust code is running natively and you can call into JNI and Objective-C freely without a VM in your way.
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.
> Dioxus is similar to modern React Native in architecture. Your rust code is running natively and you can call into JNI and Objective-C freely without a VM in your way.
Given the similarity, would it be feasible to add a compatibility layer to bring in React Native Turbo Modules? (Fabric support would be unlikely I'd imagine)
I looked at rewriting a canvas + loads of HTML, tables etc. game in Bevy with egui. Most of the things you mentioned were trivial, async RPC queries with callbacks, all of that worked fine out-of-the-box.
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.
Every six months or so I long for a consensus rust gui framework and try this one and run into an error from downloading the demo or playground or something like that.
Some of us want to invest many years of time and money into stuff and have to make the decision carefully.
Don't fool yourself, they've taken VC money [1], even being one of the top sponsored projects of all time on Github will not satiate the investors who want returns.
I want to invest in making an app out of this framework and not be a sponsor. Another thing that concerns me about this one (at least it did a while ago when I looked) is the general team size. This is a company yet there was only one employee the first couple times I looked at it.
It's not neccessarily a resource thing, but also, maybe primarily, a priorities thing. If they don't value stability now, they will probably use extra resources to build new features faster, at the same level of quality.
Another shoutout for leptos, which I'm also currently using, and loving (except for compile times (a Rust problem, not a leptos problem), and other smaller annoyances).
Yeah compile times were an issue back when i was trying Dioxus out too. Their `hot reload` was noticably not terribly hot for me. Stark contrast to what I'm used to in the node.js world.
I can only speak for myself (myself here = gbj/Greg of Leptos) — I'm in a happy situation in life that allows me to spend a bit of time working on open source, but can't and don't want to do it full time, let alone start a start up; a bit of GitHub sponsorship money pays my coffee bills and so on, but Leptos is not (and won't ever be) a commercial venture.
And at the same time: I am absolutely delighted that Dioxus has managed to raise some money so Jon can work full time and bring others into the work full time. This really, really is a "rising tide lifts all boats" type of situation... I would 100% rather capital go toward things like building out a viable Rust ecosystem and improving build tooling than the alternatives ("it's TikTok, but with an LLM!" etc.) Our two projects have collaborated successfully and will continue to collaborate and inspire each other in the future, I'm quite sure.
This isn't meant as a rebuke to your very kind comment about the work I've/we've managed to do for free, I just wanted to chime in to say that in my opinion, both of these are good!
There are several good community component libraries now. daisy rsx is one that is already updated with 0.6 support: https://crates.io/crates/daisy_rsx
My understanding of Leptos is that it is based in WASM, right? So this is in case you want to use Rust and deploy in Web, but it isn't a native solution. I guess you can use Tauri and then its Rust all over.
My feeling is that if you are going to use a webview, you might as well use Typescript and a battle tested framework.
After discovering and adopting[0] Lustre, I can't think of using anything other than The Elm Architecture. It is so much more ergonomic it's not even comparable to today's mainstream state management techniques.
I'm also building a screenplay editor prototype[1] in the Rust equivalent, Iced, and while not as ergonomic as Lustre and Gleam, it is TEA. Iced is still in flux but I have trust, considering System76 uses it to build Cosmic.
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.
One thing I always dislike about Elm and most of its offshoots is the lack of good composability of widgets. In most other architectures, most widgets are registered with their parent component in one single location, and are otherwise fully self-contained.
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.
Yes, that is the major problem I have with TEA. The best thing about Flutter's design is that it employs a "reverse iceberg" where many of Flutter's own widgets are composed with other widgets, leaving few architectural details "under the ocean".
That experience is lacking in TEA, although better in immutable languages like Gleam where it is easier to keep functions pure. Even in Iced, I'm going to side with those Elm proponents here and prefer Elm's function composition approach any day over guarding React or Flutter state from becoming spaghetti.
I wouldn't say it's outright wrong, I just much prefer the ergonomics of an orderly, TEA-like state management. Many of the projects I make lend themselves well to that approach.
It could well become very popular, but using words like “magical” and “blazing fast” immediately triggers my framework fatigue.
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.
Our hot-reloading is "magic" for the Rust ecosystem (this post's original intended audience). Hot-reloading formatted strings and simple Rust code is basically magic in Rust land.
I use blazing-fast tongue-in-cheek but Dioxus is really really fast. We did a ton of R&D into making Rust<->DOM very fast - our sledgehammer binding layer is faster than SolidJS on the JSFrameworkbenchmark [0].
As for rendering - we have two options: webview and GPU. The GPU stuff is nascent but capable. The final vision is something like React Native Skia where the majority of the interface is drawn on the GPU but interactions are done via Native System APIs. That way you get apps that look the same across platforms but "feel" native. To render, we have to step through the platform's native containers anyway, so you can always composite in a native system widget as a component.
> To say if it succeeds that it could obsolete all other frameworks is an incredibly bold claim.
2nd that. For example I doubt that most people are willing to learn Rust in the short time. People are still relying on JQuery and PHP because it does the job.
All in one (Mobile, desktop, web) always sounds nice until you actually do a multi platform app.
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.
> If they succeed, it could obsolete all other frameworks
> 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.
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.
For cross-platform desktop (and WASM), I'm still betting on iced, which I use daily. It's just so. blazing. fast.
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.
I don't see any use case where you couldn't write your app in a garbage collected language.
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.
Readit News
I did a cargo install. I then used the dx command line app to create a new project. After initialization I ran dx serve in the directory as instructed, but it gave me a compiler error with seemingly no feedback on what specifically went wrong. And again, this is for a hello world app that they generated for me. I'm unsure how to obtain more information on why it failed.
I feel like I'd have more insight and ability to debug this if I were trying to compile using a standard rust workflow rather than their CLI tool.
You can press v to enable verbose logging, but this doesn't add information which provides clarity to me. Here's the compiler output with verbose logging, though heavily edited to be readable in this HN comment box
14:17:49 [dev] Building server...
14:17:49 [dev] Building app...
14:17:49 [dev] Executing cargo...
14:17:49 [dev] cargo args: ["--profile", "server-dev", "-- verbose", "--features", "dioxus/server", "--bin", "hack"]
14:17:49 [dev] cargo args: ["--verbose", "--features", "desktop", "--bin", "hack"]
14:17:49 [dev] cargo args: ["--profile", "server-dev", "--verbose", "--features", "dioxus/server", "--bin", "hack"]
14:17:50 [dev] Setting builder to failed state
14:17:50 [dev] Build failed: Other(Cargo build failed, signaled by the compiler)
Status: Failed
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.
Why does a Linux webview app built with Dioxus require it? I'm asking, because software inserting simulated HID inputs to arbitrary windows is not exactly my cup of tea. ;) And xdotool doesn't work on Wayland anyway, by design. Apparently there are similar programs for Wayland, but AFAIK they require the user to belong to the input group, which in turn gives any app run by such user access to /dev/uinput - a security risk.
In general, though, Dioxus looks interesting and I wish you all the best in your endeavour!
On desktop/mobile, does Dioxus run as a native app? Is it an immediate mode renderer like egui? How do you style it? Or is it JavaScript + webview/electron?
On the web does it run as a WASM binary against a canvas renderer, or is it write to DOM? How does it talk to the DOM? WASM, JavaScript transpilation, etc.?
Can you do multithreading on web with web workers? Is the async story good? HTTP/gRPC clients?
Do you have to build your entire app in Dioxus, or can you incorporate other web (eg. React) apps? Can it talk to JavaScript?
How solid is the API now? Is it going to change a lot in the near future?
Do you think it'd be trivial to stuff a Bevy game inside of a Dioxus shell? We've thought it might be easier to prototype the UX outside the engine, especially since web is a deployment target.
How big is the community?
Looking into this for a project soon, so if any of the Dioxus devs can answer some of this, I'd super appreciate it. (Sorry for all the questions which may already be answered in the FAQ/docs.)
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.
Given the similarity, would it be feasible to add a compatibility layer to bring in React Native Turbo Modules? (Fabric support would be unlikely I'd imagine)
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.
Some of us want to invest many years of time and money into stuff and have to make the decision carefully.
[1] https://www.ycombinator.com/companies/dioxus-labs
I do track and use their main competitor - Leptos.
Break down your project in crates in a cargo workspace. My reload time went from 10/15s to ~4.
I followed the instructions here: https://benw.is/posts/how-i-improved-my-rust-compile-times-b... . Specifically the 2nd part of the post
And at the same time: I am absolutely delighted that Dioxus has managed to raise some money so Jon can work full time and bring others into the work full time. This really, really is a "rising tide lifts all boats" type of situation... I would 100% rather capital go toward things like building out a viable Rust ecosystem and improving build tooling than the alternatives ("it's TikTok, but with an LLM!" etc.) Our two projects have collaborated successfully and will continue to collaborate and inspire each other in the future, I'm quite sure.
This isn't meant as a rebuke to your very kind comment about the work I've/we've managed to do for free, I just wanted to chime in to say that in my opinion, both of these are good!
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.
I'm also building a screenplay editor prototype[1] in the Rust equivalent, Iced, and while not as ergonomic as Lustre and Gleam, it is TEA. Iced is still in flux but I have trust, considering System76 uses it to build Cosmic.
[0]: https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...
[1]: https://www.weedonandscott.com/tech/project-realm
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.
That experience is lacking in TEA, although better in immutable languages like Gleam where it is easier to keep functions pure. Even in Iced, I'm going to side with those Elm proponents here and prefer Elm's function composition approach any day over guarding React or Flutter state from becoming spaghetti.
Mobile, desktop, web, rust
They have an eye on performance up front which is where most previous attempts fail.
And rust gives them the security and performance foundation up front.
.5 was a huge leap, this looks like the polish that should make it viable.
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.
I use blazing-fast tongue-in-cheek but Dioxus is really really fast. We did a ton of R&D into making Rust<->DOM very fast - our sledgehammer binding layer is faster than SolidJS on the JSFrameworkbenchmark [0].
As for rendering - we have two options: webview and GPU. The GPU stuff is nascent but capable. The final vision is something like React Native Skia where the majority of the interface is drawn on the GPU but interactions are done via Native System APIs. That way you get apps that look the same across platforms but "feel" native. To render, we have to step through the platform's native containers anyway, so you can always composite in a native system widget as a component.
https://krausest.github.io/js-framework-benchmark/2023/table...
2nd that. For example I doubt that most people are willing to learn Rust in the short time. People are still relying on JQuery and PHP because it does the job.
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.
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.
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.
https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
And to a lesser extent this:
https://expo.dev/
(It won’t target games consoles or non-headless edge devices, that I know of).
https://xkcd.com/1367/
Do they require copyright assignment or a CLA? I could not find anything on their GitHub.
How many of their contributors are payed?
The way you write components is really great and the overall developer experience is very good.