Dioxus 0.6 – Crossplatform apps with Rust(dioxuslabs.com)
dioxuslabs.com
Dioxus 0.6 – Crossplatform apps with Rust
https://dioxuslabs.com/blog/release-060/
138 comments
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 [email protected] --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.
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!
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!
`cargo binstall [email protected] --force`
try updating dx first
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.)
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.
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)
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.
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.
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
[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.
+1. Frameworks learning costs are non-trivial. After you worked so hard to become productive in a particular framework it's frustrating to see its core and/or ecosystem fizzle --- especially when your existing code already tied the framework's unique constraints, making it a hassle to port to other frameworks. In this sense the "bus factor" / resilience of the framework dev does matter to the app dev building on top of it.
It's fine to downvote me. I do contribute $50 a month to an open source repo that I use commercially, so I'm not opposed to giving money to OSS projects.
Dioxus is a private company though. It is fine if people want to contribute, or if Dioxus wants investors. But isn't it a little weird trying to influence me/someone to donate to a private company to improve their _product_?
They are YC: they should raise more funds and get serious IMO. Hire more people, fix the broken stuff in the DX and more people will use the product. It's that simple.
Also if you want people to contribute money I would work on getting the product to a more usable state. People don't want to buy products that don't work, software or not. If the first experience is repeatedly one of not working software, people will not want to use it.
Dioxus is a private company though. It is fine if people want to contribute, or if Dioxus wants investors. But isn't it a little weird trying to influence me/someone to donate to a private company to improve their _product_?
They are YC: they should raise more funds and get serious IMO. Hire more people, fix the broken stuff in the DX and more people will use the product. It's that simple.
Also if you want people to contribute money I would work on getting the product to a more usable state. People don't want to buy products that don't work, software or not. If the first experience is repeatedly one of not working software, people will not want to use it.
Just chiming in because I think the discussion is interesting (creator/founder here).
We don't need the OSS crowdsourced funding. Early 2025 I have plans to distribute whatever OSS capital we still have back into the Rust community, so at least donors won't feel like their money went directly into a company.
Fortunately, we did raise a good round and have plans to get "more serious" about it. Hiring is hard and this year it was challenging to balance hiring with solving users' issues in a timely manner. It's my first time doing it. Lots of the project's details are tucked deep in the depths of my brain.
We sadly have the curse of maintaining a project where the devtools need to work on mac/win/linux/wsl and the apps need to work on mac/win/linux/wasm/wsl/android/ios. I don't think people grok the scope of this work and the permutation explosion it brings. We test against mac/windows/linux of course, but there's always some weird issue with WSL or Windows Paths or some dependency's missing system library.
For example, we had to drop 3rd party tooling for mobile this release since that was constantly breaking our setups. There's still more dependencies we don't own completely that break frequently. I'm hopeful that hiring a larger team and prioritizing quality for the next few months will "solve" the majority of issues people run into.
We don't need the OSS crowdsourced funding. Early 2025 I have plans to distribute whatever OSS capital we still have back into the Rust community, so at least donors won't feel like their money went directly into a company.
Fortunately, we did raise a good round and have plans to get "more serious" about it. Hiring is hard and this year it was challenging to balance hiring with solving users' issues in a timely manner. It's my first time doing it. Lots of the project's details are tucked deep in the depths of my brain.
We sadly have the curse of maintaining a project where the devtools need to work on mac/win/linux/wsl and the apps need to work on mac/win/linux/wasm/wsl/android/ios. I don't think people grok the scope of this work and the permutation explosion it brings. We test against mac/windows/linux of course, but there's always some weird issue with WSL or Windows Paths or some dependency's missing system library.
For example, we had to drop 3rd party tooling for mobile this release since that was constantly breaking our setups. There's still more dependencies we don't own completely that break frequently. I'm hopeful that hiring a larger team and prioritizing quality for the next few months will "solve" the majority of issues people run into.
Just know that I am rooting for you, Dioxus and every other Rust GUI framework out there.
I really hope one cements itself as the "go to" framework in the next couple of years. Good luck!
I really hope one cements itself as the "go to" framework in the next couple of years. Good luck!
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.
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.
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
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:
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.
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:
(Worth noting: it was passing RUSTFLAGS=-Ztime-passes that made me look here because, apparently, `llvm_passes` was taking the majority of the time).
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).
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.
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!
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.
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!
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
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 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'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?
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)
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.
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.
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
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.
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.
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
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.
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.
[0]: https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...
[1]: https://www.weedonandscott.com/tech/project-realm
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
The Elm architecture is amazing!
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.
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.
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.
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.
Tyrian is the Scala.js framework that follows TEA.
https://tyrian.indigoengine.io/
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.
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.
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...
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? 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).
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).
> where we can integrate with system accessibility APIs directly
Is this something Flutter doesn't do?
One of the most jarring experiences I have with Flutter Desktop was it lacked MacOS Emacs-style key bindings for text editing (ctrl-a, ctrl-e, etc.). Not sure if Dioxus solved this?
Is this something Flutter doesn't do?
One of the most jarring experiences I have with Flutter Desktop was it lacked MacOS Emacs-style key bindings for text editing (ctrl-a, ctrl-e, etc.). Not sure if Dioxus solved this?
> Is this something Flutter doesn't do?
Flutter does do this (at least to some extent) on Desktop/Mobile. It attempts to create a hidden DOM tree for accessibility on web. Which generally doesn't seem to be thought to work very well.
> One of the most jarring experiences I have with Flutter Desktop was it lacked MacOS Emacs-style key bindings for text editing (ctrl-a, ctrl-e, etc.). Not sure if Dioxus solved this?
Ah, we're nearly there on that one. We have a PR [0] accepted into Winit (the underlying windowing library we use) which will allow us to access those events. We're just waiting on Winit to do a new release and then we can integrate it into Dioxus.
[0]: https://github.com/rust-windowing/winit/pull/3824)
Flutter does do this (at least to some extent) on Desktop/Mobile. It attempts to create a hidden DOM tree for accessibility on web. Which generally doesn't seem to be thought to work very well.
> One of the most jarring experiences I have with Flutter Desktop was it lacked MacOS Emacs-style key bindings for text editing (ctrl-a, ctrl-e, etc.). Not sure if Dioxus solved this?
Ah, we're nearly there on that one. We have a PR [0] accepted into Winit (the underlying windowing library we use) which will allow us to access those events. We're just waiting on Winit to do a new release and then we can integrate it into Dioxus.
[0]: https://github.com/rust-windowing/winit/pull/3824)
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.
> our sledgehammer binding layer is faster than SolidJS on the JSFrameworkbenchmark
What new WebAssembly things will make sledgehammer faster? JS string builtins? Direct DOM access?
What new WebAssembly things will make sledgehammer faster? JS string builtins? Direct DOM access?
Both would help. Sledgehammer is fast because it batches and interns strings on the Rust<>JS boundary.
Rust strings are utf-8 and JS strings are utf-16 (don't ask me why...).
The Dioxus VirtualDom is ridiculously fast - it's closer to the micro-dom SolidJS has (yes there's a micro-dom) than an actual virtualdom that React has.
Sledgehammer queues up all the Dioxus mutations into one fat binary batch and then runs a hand-rolled utf-8 -> utf-16 converter since the browser's converter is so slow. All the dom mutations are done from javascript. If direct DOM access landed, then we'd be able to do that from Rust directly.
And ultimately, all this work is like 10% of the actual "time" taken that you see on benchmarks. The vast majority of time is the browser running layout and re-painting. Reconciling a dom is not that hard or expensive of a task, frankly.
Rust strings are utf-8 and JS strings are utf-16 (don't ask me why...).
The Dioxus VirtualDom is ridiculously fast - it's closer to the micro-dom SolidJS has (yes there's a micro-dom) than an actual virtualdom that React has.
Sledgehammer queues up all the Dioxus mutations into one fat binary batch and then runs a hand-rolled utf-8 -> utf-16 converter since the browser's converter is so slow. All the dom mutations are done from javascript. If direct DOM access landed, then we'd be able to do that from Rust directly.
And ultimately, all this work is like 10% of the actual "time" taken that you see on benchmarks. The vast majority of time is the browser running layout and re-painting. Reconciling a dom is not that hard or expensive of a task, frankly.
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.
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.
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.
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.
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.
> 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.
Not sure if you grok 100% what we're building.
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.
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.
> Not sure if you grok 100% what we're building.
Yup, fair point. Let me respond with a bit more context.
> It writes to the dom and handles dom events just like any other web framework.
So you have a DOM, but if the target renderer is not webview or browser, you create a DOM in some other way?
> Think electron but you're not shipping a browser
The browser is already there, and called webview on all major platforms. I'd say Electron is popular for maturity reasons, that architecture makes limited sense even if you are using web. Tauri would be a better comparison.
> Our users on native platforms like being able to access system APIs with no intermediary. You can [...] call FFI, etc.
This is so difficult, and I applaud you for taking on the challenge. Rust is a decent choice for FFI, but still, FFI is a mess with largest common denominator being C. In the Tauri community, most users are intimidated by Rust alone. The number of devs who could fix segfaults related to Objective C bindings, wrangle Win32 syscalls and knew enough GTK could be counted on one hand (maybe one finger). So in short, can is doing a lot of heavy lifting here. That also means users have to come up with the cross-platform API surfaces themselves, right?
Yup, fair point. Let me respond with a bit more context.
> It writes to the dom and handles dom events just like any other web framework.
So you have a DOM, but if the target renderer is not webview or browser, you create a DOM in some other way?
> Think electron but you're not shipping a browser
The browser is already there, and called webview on all major platforms. I'd say Electron is popular for maturity reasons, that architecture makes limited sense even if you are using web. Tauri would be a better comparison.
> Our users on native platforms like being able to access system APIs with no intermediary. You can [...] call FFI, etc.
This is so difficult, and I applaud you for taking on the challenge. Rust is a decent choice for FFI, but still, FFI is a mess with largest common denominator being C. In the Tauri community, most users are intimidated by Rust alone. The number of devs who could fix segfaults related to Objective C bindings, wrangle Win32 syscalls and knew enough GTK could be counted on one hand (maybe one finger). So in short, can is doing a lot of heavy lifting here. That also means users have to come up with the cross-platform API surfaces themselves, right?
> So you have a DOM, but if the target renderer is not webview or browser, you create a DOM in some other way?
Yes - we have a project called Blitz which is trying to emulate just the DOM without the browser. It's built on Servo/Firefox tech.
https://github.com/dioxusLabs/blitz
> The browser is already there, and called webview on all major platforms. I'd say Electron is popular for maturity reasons, that architecture makes limited sense even if you are using web. Tauri would be a better comparison.
The default dioxus desktop/mobile renderer uses the system's webview for exactly this reason. The blitz stuff is still young but is planned to eventually replace the webview renderer. Fortunately, webviews are on many platforms already.
> .. That also means users have to come up with the cross-platform API surfaces themselves, right?
Yes, but this is a challenge in every cross-platform framework. Flutter has pub.dev, react-native has expo modules, etc. In 2025 this will be a huge focus for us, and in all likelihood we'll just find a way to bind to existing widgets in the respective ecosystems. Easier than to try and bootstrap a pure-rust ecosystem (though it would be nice). Projects like our SDK do this, but the surface area is quite small when compared to what we eventually want to support.
http://github.com/dioxusLabs/sdk
Yes - we have a project called Blitz which is trying to emulate just the DOM without the browser. It's built on Servo/Firefox tech.
https://github.com/dioxusLabs/blitz
> The browser is already there, and called webview on all major platforms. I'd say Electron is popular for maturity reasons, that architecture makes limited sense even if you are using web. Tauri would be a better comparison.
The default dioxus desktop/mobile renderer uses the system's webview for exactly this reason. The blitz stuff is still young but is planned to eventually replace the webview renderer. Fortunately, webviews are on many platforms already.
> .. That also means users have to come up with the cross-platform API surfaces themselves, right?
Yes, but this is a challenge in every cross-platform framework. Flutter has pub.dev, react-native has expo modules, etc. In 2025 this will be a huge focus for us, and in all likelihood we'll just find a way to bind to existing widgets in the respective ecosystems. Easier than to try and bootstrap a pure-rust ecosystem (though it would be nice). Projects like our SDK do this, but the surface area is quite small when compared to what we eventually want to support.
http://github.com/dioxusLabs/sdk
Ok, sounds more reasonable now. Being DOM-like or DOM-compatible sounds much preferable, even though I don't see the reason to abandon webviews - you get 30 years of battle-tested tech for free + massive ecosystem.
> Yes, but this is a challenge in every cross-platform framework. Flutter has pub.dev, react-native has expo modules, etc.
I don't know about those, but I can say with confidence (from experience in Tauri) that the native integrations are absolutely crucial. Getting the API surfaces right, the plugin <-> core boundary right (with versioning, etc). It's hard as hell - do lots of research and try to learn from their mistakes.
> Easier than to try and bootstrap a pure-rust ecosystem (though it would be nice).
One thing I learned from the Tauri FFI story is that Rust mattered very little in the sense of hermetic and safe development. The boundaries get ugly and safety can be violated simply by misunderstanding the model of the other language (for instance, I've had an Objective C autorelease bug that caused a segfault on `drop`).
Investing in good infra, testing, debuggability around the FFI boundaries would have been the right thing to do. You often run into the same kind of problems in different "plugins" and features.
> Yes, but this is a challenge in every cross-platform framework. Flutter has pub.dev, react-native has expo modules, etc.
I don't know about those, but I can say with confidence (from experience in Tauri) that the native integrations are absolutely crucial. Getting the API surfaces right, the plugin <-> core boundary right (with versioning, etc). It's hard as hell - do lots of research and try to learn from their mistakes.
> Easier than to try and bootstrap a pure-rust ecosystem (though it would be nice).
One thing I learned from the Tauri FFI story is that Rust mattered very little in the sense of hermetic and safe development. The boundaries get ugly and safety can be violated simply by misunderstanding the model of the other language (for instance, I've had an Objective C autorelease bug that caused a segfault on `drop`).
Investing in good infra, testing, debuggability around the FFI boundaries would have been the right thing to do. You often run into the same kind of problems in different "plugins" and features.
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.
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.
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.
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).
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/
https://xkcd.com/1367/
I'm using Dioxus on the server side and have written about it here. https://rust-on-nails.com/
The way you write components is really great and the overall developer experience is very good.
The way you write components is really great and the overall developer experience is very good.
Dioxus is the only web-platform technology toolkit that I see having the ability to be cross-platform and use Javascript as little as possible - glad to see their native WGPU rendering stack progress (check out the videos by Nico Burns on Blitz, Taffy etc)
I tried Dioxus out earlier this year - I wanted to make a little SSHFS GUI client. Think Google Drive UI but in a dedicated window and it's SSHFS instead of some cloud nonsense. Everything went swimmingly until I needed shared state between different contexts. From that point, the code got really messy, really quickly. I don't know what the right solution is for this problem. What I can say is Dioxus hasn't found it yet.
The static HTML templating thing is pretty damn good, though. I actually use it to render parts of my blog.
The static HTML templating thing is pretty damn good, though. I actually use it to render parts of my blog.
The new hot-reloading is amazing! Coming from another Rust web framework waiting for UI updates to show up has always been a huge painpoint, so thanks for this!
Suggestion: the post title contrast with the page background could be improved.
Question: where does Qt stands these days, and how does this toolkit compare to it regarding accessibility and handling HiDPI screens? Are there any quality bindings for languages that aren't C++ and Python? It feels like they solved a lot of problems long ago, and the toolkit could be way more popular with better bindings and tooling.
Question: where does Qt stands these days, and how does this toolkit compare to it regarding accessibility and handling HiDPI screens? Are there any quality bindings for languages that aren't C++ and Python? It feels like they solved a lot of problems long ago, and the toolkit could be way more popular with better bindings and tooling.
Qt is a great choice these days. I developed my block editor (like Notion) using Qt with C++ and QML. I wrote about it here: https://rubymamistvalove.com/block-editor
There are many bindings to other languages[1].
[1] https://wiki.qt.io/Language_Bindings
There are many bindings to other languages[1].
[1] https://wiki.qt.io/Language_Bindings
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?
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.
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'
[deleted]
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.
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.
The linked article literally states: Our goal is to build a "Flutter but better."
I never know how to position Dioxus, so would be happy to have some 3rd party insight.
When I say we use a webview, people immediately jump to Tauri. But we're very architecturally different than Tauri. No WASM on native, just a regular old executable.
When I compare us to Flutter, people immediately think of Flutter's negatives (poor web support). We have excellent web support (DOM is 1st class).
When I compare us to React Native, people immediately think the web is 2nd-class and then wonder why we don't implement NSScrollView and all that.
We are shooting for something like Flutter (web, desktop, mobile, embedded) but where the web is the defining feature.
As someone outside Dioxus, how do you think I should describe it?
When I say we use a webview, people immediately jump to Tauri. But we're very architecturally different than Tauri. No WASM on native, just a regular old executable.
When I compare us to Flutter, people immediately think of Flutter's negatives (poor web support). We have excellent web support (DOM is 1st class).
When I compare us to React Native, people immediately think the web is 2nd-class and then wonder why we don't implement NSScrollView and all that.
We are shooting for something like Flutter (web, desktop, mobile, embedded) but where the web is the defining feature.
As someone outside Dioxus, how do you think I should describe it?
> We have excellent web support (DOM is 1st class)
ah I missed that... I read something about Flutter and WASM and kind of assumed it was rendering to canvas
that's very nice
ah I missed that... I read something about Flutter and WASM and kind of assumed it was rendering to canvas
that's very nice
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.
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
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?
> 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.
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.
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.
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)
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.
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.
I want a Rust GUI framework or even entire app framework that can target desktop, mobile, and web, but I DON’T want to use web technologies other than when I am actually running within a browser. Is that Dioxus? I can’t tell the answer from what’s written here and in the comments.
If you don't want to use web technologies but still benefit from the non-web parts of the ecosystem (SDK, hooks, build tools) there's Freya. The creator is a wonderful guy and has put a lot of great work into making a nice Skia-based renderer for Dioxus.
https://freyaui.dev
WRT the other comment - `rsx!{}` is carefully designed to not leak details about the web. RSX is entirely abstract over the element+listener set so you can build whatever you want with it.
https://freyaui.dev
WRT the other comment - `rsx!{}` is carefully designed to not leak details about the web. RSX is entirely abstract over the element+listener set so you can build whatever you want with it.
That seems like more of the same? rsx!{} basically presents a web view API, with CSS-driven layout (or something approximating that).
I'm looking for a native widget library that can compile to web technologies when running in the browser, but otherwise uses native widgets.
I'm looking for a native widget library that can compile to web technologies when running in the browser, but otherwise uses native widgets.
No. But what you want does exist to a certain extent.
DX tries to be "rust only" but basically gives you a macro to write HTML-like components, which are obviously just a shim between layers and the abstraction is leaky. You don't get much from that.
You probably want egui.rs
DX tries to be "rust only" but basically gives you a macro to write HTML-like components, which are obviously just a shim between layers and the abstraction is leaky. You don't get much from that.
You probably want egui.rs
I want native widgets.
I love the simplicity of the flow: Mutation => Server returns full API for FE to rerender the whole page.
Trying to figure out which parts of the page to auto reload is hacky to me.
And it's the best proof of: Preoptimization is the root of all evil squares.
Trying to figure out which parts of the page to auto reload is hacky to me.
And it's the best proof of: Preoptimization is the root of all evil squares.
this looks interesting and could be a cool option. have yet to dive in deep but tbh i'm uncomfortable using a Fancy New Framework that maintainers refuse to bump to >0 major version. i know semver is a bastardized wreck of its intended semantics but still, gotta stabilize at some point. could be misdirected here but i have a reactionary streak about this after seeing one too many 8 year old libraries with 5mil downloads that still won't freaking version a 1.0.0.
This is more of a culture thing with the Rust ecosystem more than anything else.
If the culture of the Rust ecosystem was to publish a 1.0, we would do it. And frankly, I'd really like to have an extra "version" to play with - 0.x.y is quite limiting.
There's a few core things I want to clean up and split out in 2025. If all goes well, we might see a 1.0 next year.
If the culture of the Rust ecosystem was to publish a 1.0, we would do it. And frankly, I'd really like to have an extra "version" to play with - 0.x.y is quite limiting.
There's a few core things I want to clean up and split out in 2025. If all goes well, we might see a 1.0 next year.
It works amazingly well. Great crate!!
It's cool but I could never live with that syntax. Impossible to read, it feels like.
It's very much inspired by Jetpack Compose and SwiftUI.
At the end of the day we just use the Rust Struct parser!
It's very similar to JSON or RON if you're familiar.
https://github.com/ron-rs/ron
At the end of the day we just use the Rust Struct parser!
It's very similar to JSON or RON if you're familiar.
https://github.com/ron-rs/ron
I'm not, I find the entire Rust language to be very unreadable.
I have seen a lot of templating languages like the one in Dioxus but I don't think you will "win" the hearts of people with a templating like this:
``` rsx! { footer { class: "footer", span { class: "todo-count", strong { "{active_todo_count} " } span { match active_todo_count() { 1 => "item", _ => "items", } " left" } } ```
Even if I can read it, it's much more of a hassle since I have to translate this into actual html in my brain. Why would I pick this over regular jsx with React? Sure crossplatform is cool, but I already do crossplatform since I only do web dev like most people nowadays.
Maybe I'm not the target customer here, but I have a hard time finding a reason why I should pick something that is much more complex. Speed sure but the gains are not good enough to warrant learning this and if I was a betting man I would bet against it in it's current form due to the learning curve. Also I worry about the financing sine I've read that you guys are taking in VC. Obviously there is some kind of plan in order to make money in the future and I wonder what rug-pull will happen.
The thing is, I have been looking on Rust due to the performance and the potential in wasm (I do very client heavy apps that would benefit from it). But I really don't like the language or the community so I'm basically waiting for other languages to keep up.
When I go in on a technology, I want to master it. So it will require a lot of learning and time investment for me which is my most precious resource and not something I will throw away lightly.
I have seen a lot of templating languages like the one in Dioxus but I don't think you will "win" the hearts of people with a templating like this:
``` rsx! { footer { class: "footer", span { class: "todo-count", strong { "{active_todo_count} " } span { match active_todo_count() { 1 => "item", _ => "items", } " left" } } ```
Even if I can read it, it's much more of a hassle since I have to translate this into actual html in my brain. Why would I pick this over regular jsx with React? Sure crossplatform is cool, but I already do crossplatform since I only do web dev like most people nowadays.
Maybe I'm not the target customer here, but I have a hard time finding a reason why I should pick something that is much more complex. Speed sure but the gains are not good enough to warrant learning this and if I was a betting man I would bet against it in it's current form due to the learning curve. Also I worry about the financing sine I've read that you guys are taking in VC. Obviously there is some kind of plan in order to make money in the future and I wonder what rug-pull will happen.
The thing is, I have been looking on Rust due to the performance and the potential in wasm (I do very client heavy apps that would benefit from it). But I really don't like the language or the community so I'm basically waiting for other languages to keep up.
When I go in on a technology, I want to master it. So it will require a lot of learning and time investment for me which is my most precious resource and not something I will throw away lightly.
Would be cool to see a front end for this in Mojo when the language matures a bit
Have you considered contributing to Tauri?
Tauri offers Dioxus as front-end framework when you create a new project.
The username of one of the devs :) https://github.com/DogeDark
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