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:

  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 also had an issue where Rust was recompiling dependencies unnecessarily. It turned out to be because rust-analyzer has one more level of `Bash` than VSCode's integrated terminal. My `.bashrc` was loading something unconditionally which meant if you nested bash sessions the PKG_CONFIG_PATH changed (duplicate entries).

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.

Thanks for that very helpful tip! According to the output of that, no unnecessary recompilation is taking place.

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

Removing that seems to give me an order (or two) of magnitude reduction in compile times.

(Worth noting: it was passing RUSTFLAGS=-Ztime-passes that made me look here because, apparently, `llvm_passes` was taking the majority of the time).

Just skimmed through it.

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 so deeply appreciate your time, thank you!

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!

Np! And glad you managed to also solve the issue! Sadly with niche things (leptos still is IMHO) hiccups are expected:)

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

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.

It turns out this wasn't my issue (more on this on other threads here), but I genuinely appreciate your time and help.

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.

This version fixes a lot of inconsistencies in our hot-reload. We can't reload all Rust code, but we can reload some simple Rust expressions and way more RSX.

Love Leptos! Consider what these guys built on a shoestring budget compared to Dioxus which raised at least half a million in venture capital.

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!

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

European programming salaries aren't that low. It's probably more like 6 for a year (remember companies pay tax and pension too).

It varies a lot. Are they in Bosnia or are they in Germany.

Fair enough :)

Only in the US. You could get 10 good Devs in London for this money, or even more juniors/internship.

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've raised 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.

Complexity can be almost as effective a moat as a CLA. If they went closed I doubt anyone would start an effective fork.

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.

There seem to be multiple component libraries and a „query“ library (inspired by tanstack query), which is the first thing I would’ve built:

https://dioxuslabs.com/awesome

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