6 ms·

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 co

by ewuhic 2y ago

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.

diablozzq 2y ago
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.
- Evan-Almloff 2y ago
  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 https://crates.io/crates/daisy_rsx
davidatbu 2y ago
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).
- marcyb5st 2y ago
  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-by-seventy-five-percent https://benw.is/posts/how-i-improved-my-rust-compile-times-b... . Specifically the 2nd part of the post
  - davidatbu 2y ago
    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 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.
    - IshKebab 2y ago
      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.
      - davidatbu 2y ago
        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).
    - marcyb5st 2y ago
      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.
- bobajeff 2y ago
  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.
  - jkelleyrtp 2y ago
    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.
weinzierl 2y ago
Love Leptos! Consider what these guys built on a shoestring budget compared to Dioxus which raised at least half a million in venture capital.
- sedatk 2y ago
  Half a million means hiring two or three devs for a year.
  - weinzierl 2y ago
    The point is that Leptos became awesome even with no money.
    - jkelleyrtp 2y ago
      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.
      - weinzierl 2y ago
        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?
        jkelleyrtp 2y ago
        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 https://github.com/DioxusLabs/dioxus/releases/tag/v0.6.0 (scroll to contributors)
chromatin 2y ago
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.
huevosabio 2y ago
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.
solarkraft 2y ago
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 https://dioxuslabs.com/awesome

by ewuhic 2y ago

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.

diablozzq 2y ago

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.

Evan-Almloff 2y ago
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 https://crates.io/crates/daisy_rsx

davidatbu 2y ago

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

marcyb5st 2y ago
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-by-seventy-five-percent https://benw.is/posts/how-i-improved-my-rust-compile-times-b... . Specifically the 2nd part of the post
- davidatbu 2y ago
  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 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.
  - IshKebab 2y ago
    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.
    - davidatbu 2y ago
      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).
  - marcyb5st 2y ago
    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.
bobajeff 2y ago
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.
- jkelleyrtp 2y ago
  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.

weinzierl 2y ago

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

sedatk 2y ago
Half a million means hiring two or three devs for a year.
- weinzierl 2y ago
  The point is that Leptos became awesome even with no money.
  - jkelleyrtp 2y ago
    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.
    - weinzierl 2y ago
      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?
      - jkelleyrtp 2y ago
        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 https://github.com/DioxusLabs/dioxus/releases/tag/v0.6.0 (scroll to contributors)

chromatin 2y ago

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.

huevosabio 2y ago

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.

solarkraft 2y ago

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 https://dioxuslabs.com/awesome