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.
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 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.I had OpenSSL as a dependency, and if `PKG_CONFIG_PATH` changes it rebuilds it (this is correct), which means if you make an edit to a file and save it, rust-analyzer would blow away the cache, then you build it on the command line and it blows it away again.
To test:
1. If you quit VSCode and do an incremental build is it still slow? 2. Try `CARGO_LOG=cargo::core::compiler::fingerprint=info cargo build` (took me a while to find that; there is a bug open to make it less stupidly hard to find).
That will print a load of info about why Cargo is rebuilding stuff. Note that it isn't really in a sensible order - the first message isn't necessarily the cause. The message about the environment variable changing was somewhere in the middle for me, so read the whole log.
I actually figured out the issue! It turns out, I had unquestioningly transplanted the following from the blog post in discussion, and that is the cause of all my issues:
[profile.dev]
opt-level = 1
[profile.dev.package."*"]
opt-level = 3
(Worth noting: it was passing RUSTFLAGS=-Ztime-passes that made me look here because, apparently, `llvm_passes` was taking the majority of the time).
One thing that popped out is that you might want to try to define dependencies at the workspace level and then in the sub-crates point to those instead.
Otherwise you are correct, your setup is already very granular. Furthermore, I have no clue about why it takes so long on your end :/ . I am running on Linux, so I wonder if there's something in the MacOs stack that messes things up and so you end up recompiling dependencies over and over.
Another thing I noticed in my setup is that one of the biggest offenders was sqlx if the macro feature was enabled since the queries were ran at each incremental compilation.
I figured out the issue: I transplanted the bit about setting optimization levels from the blogpost into my setup (which sets opt-level = 3 for all dependencies), and when I removed that, my compile times went down by a factor of 5-10!
Make sure that your ide/vscode is using the exact same rust toolchain as you to build/check/run. Otherwise you don't get incremental compiling but recompilation a lot. I think there's an environment variable to force it.
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!
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.
I'm particularly excited about your research on actually hot-reloading Rust binary code. I hope it leads to reduced incremental compilation times (IIUC).
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?
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)
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.
I don’t see why volunteer dev work would be more valuable. It’s the same work. Those people have the same living costs.
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.