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.
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).
I've tried following that same guide, and I believe I've tried every thing on that blog post except the mold linker, because I'm on MacOS, and the MacOS version of the mold repo says "use the default linker if you have XCode 15 or higher."
And I do think I have a pretty granular crate system (would be _very_ happy to hear otherwise, because that would mean there's low hanging compile time fruit!): https://github.com/dnaaun/heimisch
My current _incremental_ compilation time swings anywhere between 15 seconds and 3 minutes (no, I'm not kidding). And I work on an M3 max macbook pro.
---
Things that I suspect are making my compile times worse:
1. The fact that I am doing SSR, which means my frontend code is included in the backend code as well.
2. I _think_ Rust is unnecessarily recompiling dependencies on incremental builds? (I don't understand how incremental compilation times can be so bad otherwise). But I'm clueless about how to go about debugging that.
Dioxus was awesome for a long time without money :)
As my little side project, we pioneered html-templates, wasm-bindgen string interning, macro hot-reloading, macro auto-formatting, multi-platform builds, native HTML/css rendering, and a number of other "awesome" things before raising a dollar.
Users want a guarantee the project isn't going to disappear tomorrow and sadly 100 bucks a month on open collective isn't a great guarantee.
As a leptos user, I just wanted to say that I appreciate everything you have outlined here (and more) that you have done for the Rust/wasm ecosystem (especially since other people here seem to be less appreciative of your contributions because you raise VC funds, and I feel like as an open source maintainer, you probably hear much more from 'dissatisfied customers' than the satisfied ones).
I'm particularly excited about your research on actually hot-reloading Rust binary code. I hope it leads to reduced incremental compilation times (IIUC).
I am sorry, but I have seen projects going down too often once VC capital got involved to be positive about it.
VC capital is just one indicator. Maybe you can answer:
Do you require a CLA or copyright assignment? I don't see it on the GitHub page but then again other projects (like MongoDB) have hidden theirs pretty well.
How many of the contributors are directly payed for their contributions?
In, my opinion it's good for ambitious projects to have a stable financial foundation. What negative things one project does because of venture capital does not mean another will.
There's no CLA. Dioxus is MIT/Apache-2 licensed.
> How many of the contributors are directly payed for their contributions?
I unfortunately feel like you're asking this in bad faith. Our team is very small, we're very lean, and we have funding sources that aren't just venture. We also have a very active community and people are building new libraries and becoming dioxus contributors every day.
I am sorry if this came across the wrong way. I am not trying to upset you with these questions.
If you say your team is small I understand that it is not the majority of contributors that are on your payroll and that is good enough for me to see Dioxus as a real community project.
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
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.
From a cursory look the Server Functions for Native seem like a what I imagined Tauri to be: A real RPC framework that skips you the anoyances of serialization.
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.
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.
It seems like an interesting project, but using Skia (or any canvas/GPU render) concerns me for a bunch of reasons, not unlike Flutter.
Have you given consideration to indexing, accessibility and durability when working the problem? These are often the critical features that are overlooked with these frameworks and if they’ve even thought about that it would set you ahead of several other attempts that have ignored them (and are therefore unfeasible for most use cases).
I don’t mean this to sound derisive, it’s intended to be constructive.
> Have you given consideration to indexing, accessibility and durability when working the problem?
This is actually a key area where we think we have an advantage over the competition. The model for Dioxus is to render to DOM on the web and only use the GPU renderer on native platforms (where we can integrate with system accessibility APIs directly).
The tradeoff for this is that our API on all platforms ends up being much closer to web APIs, our renderer has to implement a lot more of the web platform (e.g. we're shipping a full CSS engine, and using web-compatible Flexbox/CSS Grid for layout).
Perhaps I'm misunderstanding you, but Dioxus does not use the canvas when rendering in the browser. It uses the DOM with CSS just like any other JavaScript framework does.
> 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.
With ChatGPT they may not need to learn it the same way.
Easy enough to code something in html and JavaScript and let tools translate. Obviously not that simple, but an example of why it might not be as hard in 2024.
It’s a bold claim, but they are executing and have benchmarks for validating the performance and features.
Lots of work left to do - but the speed aspect is where other frameworks who have tried similar tend to choke. If you look at the web framework benchmarks on tech empower and the web frameworks for react, dioxus is ahead of 95% today. And the ones that are ahead, don’t support deployment to desktop mobile and web.
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.
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.
AFAIK, Tauri is an electron replacement: a portable web view container where you can use any web tech to build an app. So you can build with JS/TS or any language that compiles to WASM. You can use the Rust native host but you don't have to.
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.
Edit: apparently the documentation indicating this was inaccurate
--------
Original comment:
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.
We are great friends with Tauri but I think people misunderstand our architecture and philosophy just because we use one of their maintained libraries.
We’ve been working on a native HTML/CSS library for a while called blitz which is reaching stability soon.
I'm just going based off of the page I linked (which appears to be the documentation for version 0.6 which was just released) which says:
> Dioxus desktop is built off Tauri. Right now there are limited Dioxus abstractions over the menubar, event handling, etc. In some places you may need to leverage Tauri directly – through Wry and Tao.
Maybe that paragraph is out of date though?
From your comment it seems like wry is not (currently?) based on Tauri so it doesn't seem like it would make sense to "leverage Tauri directly – through Wry"; was wry previously based on Tauri and is that part left over from before that change? Or did the person who wrote the documentation misunderstand how it works?
Looking forward to this as I use Flutter personally but sometimes I write code for it via its FFI package flutter_rust_bridge, but it'd be nice to use Rust directly everywhere. I am also interested in the usage of the GPU as Flutter does because that way you get a consistent experience on the web as well as mobile and desktop. Flutter recently removed their HTML renderer because it was hard to keep both renderers in sync, but I don't believe Dioxus will do that as they started off HTML-first rather than mobile-first like Flutter.
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)
Sounds promising. I was looking at Tauri recently for an upcoming iOS/Android project but it doesn't seem mature enough. I will require bluetooth and with flutter I know how to go about it.
How do you, @jkelleyrtp, feel Dioxus would perform in terms of DX for a dev comfortable with flutter, react and rust but a bit of a novice with Xcode. Publishing for iOS just always seems such a hassle, but if I can't get the last step done the whole project is worthless.
With rsx, does Dioxus support more free-form layouts that are not the typical Gtk box in a box but more web-type layer over layer (i.e. absolute/static positioning in html or Flutter's Stack component)
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
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
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.
`cargo binstall dioxus-cli@0.6.0 --force`
try updating dx first
Dioxus drastically lacks in ecosystem. There is not a single component library out there. I'm also not sure about virtual DOM.
I do track and use their main competitor - Leptos.
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).
I had similar issues but I was able go largely solve them.
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
I've tried following that same guide, and I believe I've tried every thing on that blog post except the mold linker, because I'm on MacOS, and the MacOS version of the mold repo says "use the default linker if you have XCode 15 or higher."
And I do think I have a pretty granular crate system (would be _very_ happy to hear otherwise, because that would mean there's low hanging compile time fruit!): https://github.com/dnaaun/heimisch
My current _incremental_ compilation time swings anywhere between 15 seconds and 3 minutes (no, I'm not kidding). And I work on an M3 max macbook pro.
---
Things that I suspect are making my compile times worse:
Love Leptos! Consider what these guys built on a shoestring budget compared to Dioxus which raised at least half a million in venture capital.
Could be missing something on the Leptos site, but isn't this apples to oranges? Leptos is web only while Dioxus is web + mobile + desktop.
Half a million means hiring two or three devs for a year.
Or 10 european seniors
Fair enough :)
The point is that Leptos became awesome even with no money.
Dioxus was awesome for a long time without money :)
As my little side project, we pioneered html-templates, wasm-bindgen string interning, macro hot-reloading, macro auto-formatting, multi-platform builds, native HTML/css rendering, and a number of other "awesome" things before raising a dollar.
Users want a guarantee the project isn't going to disappear tomorrow and sadly 100 bucks a month on open collective isn't a great guarantee.
As a leptos user, I just wanted to say that I appreciate everything you have outlined here (and more) that you have done for the Rust/wasm ecosystem (especially since other people here seem to be less appreciative of your contributions because you raise VC funds, and I feel like as an open source maintainer, you probably hear much more from 'dissatisfied customers' than the satisfied ones).
I'm particularly excited about your research on actually hot-reloading Rust binary code. I hope it leads to reduced incremental compilation times (IIUC).
I am sorry, but I have seen projects going down too often once VC capital got involved to be positive about it.
VC capital is just one indicator. Maybe you can answer:
Do you require a CLA or copyright assignment? I don't see it on the GitHub page but then again other projects (like MongoDB) have hidden theirs pretty well.
How many of the contributors are directly payed for their contributions?
In, my opinion it's good for ambitious projects to have a stable financial foundation. What negative things one project does because of venture capital does not mean another will.
There's no CLA. Dioxus is MIT/Apache-2 licensed.
> How many of the contributors are directly payed for their contributions?
I unfortunately feel like you're asking this in bad faith. Our team is very small, we're very lean, and we have funding sources that aren't just venture. We also have a very active community and people are building new libraries and becoming dioxus contributors every day.
https://github.com/DioxusLabs/dioxus/releases/tag/v0.6.0 (scroll to contributors)
I am sorry if this came across the wrong way. I am not trying to upset you with these questions.
If you say your team is small I understand that it is not the majority of contributors that are on your payroll and that is good enough for me to see Dioxus as a real community project.
Thanks for your answers.
No. It just means some people gifted the project the same amount of money by volunteering.
I don’t see why volunteer dev work would be more valuable. It’s the same work. Those people have the same living costs.
I also use leptos, which appears to have a lively, developing ecosystem.
The contrast is interesting because leptos was the brainchild of an individual (Anglican priest, too, IIUC) whereas Dioxus is venture-backed.
Yea component library is a key feature they need asap. They did start one but development hasn’t taken off and prioritized.
DIY components is rough for basic dev.
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
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.
Totally agree. This is where you get to invest: They're still looking for monthly sponsors. https://github.com/sponsors/DioxusLabs#sponsors
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.
[1] https://www.ycombinator.com/companies/dioxus-labs
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.
From a cursory look the Server Functions for Native seem like a what I imagined Tauri to be: A real RPC framework that skips you the anoyances of serialization.
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.
[0]: https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...
[1]: https://www.weedonandscott.com/tech/project-realm
Tyrian is the Scala.js framework that follows TEA. https://tyrian.indigoengine.io/
What is wrong with the dioxis approach?
I’ve been watching this for a while. It’s the most promising tech framework I’ve seen. If they succeed, it could obsolete all other frameworks.
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.
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.
https://krausest.github.io/js-framework-benchmark/2023/table...
It seems like an interesting project, but using Skia (or any canvas/GPU render) concerns me for a bunch of reasons, not unlike Flutter.
Have you given consideration to indexing, accessibility and durability when working the problem? These are often the critical features that are overlooked with these frameworks and if they’ve even thought about that it would set you ahead of several other attempts that have ignored them (and are therefore unfeasible for most use cases).
I don’t mean this to sound derisive, it’s intended to be constructive.
> Have you given consideration to indexing, accessibility and durability when working the problem?
This is actually a key area where we think we have an advantage over the competition. The model for Dioxus is to render to DOM on the web and only use the GPU renderer on native platforms (where we can integrate with system accessibility APIs directly).
The tradeoff for this is that our API on all platforms ends up being much closer to web APIs, our renderer has to implement a lot more of the web platform (e.g. we're shipping a full CSS engine, and using web-compatible Flexbox/CSS Grid for layout).
Perhaps I'm misunderstanding you, but Dioxus does not use the canvas when rendering in the browser. It uses the DOM with CSS just like any other JavaScript framework does.
Bundle size and memory usage are still worse than leading js alternatives
> 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.
With ChatGPT they may not need to learn it the same way.
Easy enough to code something in html and JavaScript and let tools translate. Obviously not that simple, but an example of why it might not be as hard in 2024.
It’s a bold claim, but they are executing and have benchmarks for validating the performance and features.
Lots of work left to do - but the speed aspect is where other frameworks who have tried similar tend to choke. If you look at the web framework benchmarks on tech empower and the web frameworks for react, dioxus is ahead of 95% today. And the ones that are ahead, don’t support deployment to desktop mobile and web.
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.
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.
Is there really more potential compared to Capacitor or Tauri?
Imagine hitting deploy and your app builds for every platform that exists.
There’s this
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).
idk I do this in plain ol' C++ with Qt & CMake, every commit builds for mac, windows with msvc and mingw, 15-ish linux distros / configurations, web, bsd... https://github.com/ossia/score?tab=readme-ov-file#build-stat...
^ Like a website?
https://xkcd.com/1367/
Very cool demo, but If the application code is HTML/JS/CSS, then why do we need RSX?
Is the web framework necessary? How does this compare, to say Tauri w. React & Vite?
In the same way React Native still uses JSX, Dioxus uses RSX even if those widgets are rendered natively (say, on the GPU).
Is Tauri and Dioxus similar projects, or those are made for different purposes?
AFAIK, Tauri is an electron replacement: a portable web view container where you can use any web tech to build an app. So you can build with JS/TS or any language that compiles to WASM. You can use the Rust native host but you don't have to.
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.
a quick read shows it tries to be 'flutter but in rust'
Neither Tauri nor Dioxus is trying to be flutter. The only similarity is that those projects exists in GUI space.
Tauri is an electron alternative. It handles windows creation, rendering of web pages as well as IPC between frontend and backend.
Dioxus is a frontend framework similar to Next.js and other react-based frameworks.
Flutter uses an entirely different approach to GUI.
Edit: apparently the documentation indicating this was inaccurate -------- Original comment:
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.
We don’t necessarily use Tauri… Tauri has a library called wry that’s basically a more maintained fork of the Rust web-view library.
https://github.com/Boscop/web-view
We are great friends with Tauri but I think people misunderstand our architecture and philosophy just because we use one of their maintained libraries.
We’ve been working on a native HTML/CSS library for a while called blitz which is reaching stability soon.
https://github.com/DioxusLabs/blitz
I'm guessing some of that misunderstanding comes from the fact that it states "Dioxus desktop is built off Tauri" here: https://dioxuslabs.com/learn/0.6/guides/desktop/
Oh, my bad. That language has never been accurate and I'm not 100% sure why it's phrased that way. Just pushed an update.
I'm just going based off of the page I linked (which appears to be the documentation for version 0.6 which was just released) which says:
> Dioxus desktop is built off Tauri. Right now there are limited Dioxus abstractions over the menubar, event handling, etc. In some places you may need to leverage Tauri directly – through Wry and Tao.
Maybe that paragraph is out of date though?
From your comment it seems like wry is not (currently?) based on Tauri so it doesn't seem like it would make sense to "leverage Tauri directly – through Wry"; was wry previously based on Tauri and is that part left over from before that change? Or did the person who wrote the documentation misunderstand how it works?
Oh, my bad. That language has never been accurate and I'm not 100% sure why it's phrased that way. Just pushed an update.
Different purposes- at least that's how it started / feels like it currently is.
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.
"Pure rust" is not quite accurate given the rsx! macro DSL stuff
sure it is. the macro is written in rust and used in rust and compiled using the rust compiler
the tooling might be in Rust, but now I have to write some new DSL that isn't Rust
The DSL is basically just Rust structs with optional fields. We essentially use the same struct parser rust uses but with some small tweaks.
You want to use a macro for this so you can do hot-reloading - doing it with native Rust is currently impractical for rapid dev.
how pure though if it's using react.
it isn't. it's "like react"
Looking forward to this as I use Flutter personally but sometimes I write code for it via its FFI package flutter_rust_bridge, but it'd be nice to use Rust directly everywhere. I am also interested in the usage of the GPU as Flutter does because that way you get a consistent experience on the web as well as mobile and desktop. Flutter recently removed their HTML renderer because it was hard to keep both renderers in sync, but I don't believe Dioxus will do that as they started off HTML-first rather than mobile-first like Flutter.
Dioxus raised venture capital, so I'd be careful before betting my future on them.
Do they require copyright assignment or a CLA? I could not find anything on their GitHub.
How many of their contributors are payed?
It works amazingly well. Great crate!!
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)
Would be cool to see a front end for this in Mojo when the language matures a bit
Sounds promising. I was looking at Tauri recently for an upcoming iOS/Android project but it doesn't seem mature enough. I will require bluetooth and with flutter I know how to go about it. How do you, @jkelleyrtp, feel Dioxus would perform in terms of DX for a dev comfortable with flutter, react and rust but a bit of a novice with Xcode. Publishing for iOS just always seems such a hassle, but if I can't get the last step done the whole project is worthless. With rsx, does Dioxus support more free-form layouts that are not the typical Gtk box in a box but more web-type layer over layer (i.e. absolute/static positioning in html or Flutter's Stack component)
The username of one of the devs :) https://github.com/DogeDark