[HN Gopher] Dioxus 0.6 - Crossplatform apps with Rust
___________________________________________________________________
Dioxus 0.6 - Crossplatform apps with Rust
Author : jkelleyrtp
Score : 174 points
Date : 2024-12-11 15:24 UTC (7 hours ago)
(HTM) web link (dioxuslabs.com)
(TXT) w3m dump (dioxuslabs.com)
| datadeft wrote:
| Is Tauri and Dioxus similar projects, or those are made for
| different purposes?
| huevosabio wrote:
| 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.
| synergy20 wrote:
| a quick read shows it tries to be 'flutter but in rust'
| 0x457 wrote:
| 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.
| jasonjmcghee wrote:
| 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.
| fl0id wrote:
| how pure though if it's using react.
| jasonjmcghee wrote:
| it isn't. it's "like react"
| airstrike wrote:
| "Pure rust" is not quite accurate given the rsx! macro DSL
| stuff
| jasonjmcghee wrote:
| sure it is. the macro is written in rust and used in rust
| and compiled using the rust compiler
| airstrike wrote:
| the tooling might be in Rust, but now I have to write
| some new DSL that isn't Rust
| jkelleyrtp wrote:
| 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.
| resoluteteeth wrote:
| 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.
| jkelleyrtp wrote:
| 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
| ezero wrote:
| 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/
| jkelleyrtp wrote:
| 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.
| resoluteteeth wrote:
| 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?
| jkelleyrtp wrote:
| 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.
| echelon wrote:
| 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.)
| jkelleyrtp wrote:
| 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.
| niteshade wrote:
| > 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)
| diablozzq wrote:
| 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.
| J_Shelby_J wrote:
| Imagine hitting deploy and your app builds for every platform
| that exists.
| highwaylights wrote:
| 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).
| bitbasher wrote:
| ^ Like a website?
|
| https://xkcd.com/1367/
| jcelerier wrote:
| 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...
| highwaylights wrote:
| 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.
| aloisdg wrote:
| > 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.
| diablozzq wrote:
| 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.
| jkelleyrtp wrote:
| 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...
| highwaylights wrote:
| 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.
| Svenskunganka wrote:
| 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.
| nicoburns wrote:
| > 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).
| voat wrote:
| Bundle size and memory usage are still worse than leading
| js alternatives
| risyachka wrote:
| 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.
| airstrike wrote:
| 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.
| bryanhogan wrote:
| Is there really more potential compared to Capacitor or Tauri?
| andridk wrote:
| 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?
| jkelleyrtp wrote:
| In the same way React Native still uses JSX, Dioxus uses RSX
| even if those widgets are rendered natively (say, on the GPU).
| ewuhic wrote:
| 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 wrote:
| 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 wrote:
| 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
| davidatbu wrote:
| 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 wrote:
| 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
| weinzierl wrote:
| 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 wrote:
| Half a million means hiring two or three devs for a year.
| weinzierl wrote:
| The point is that Leptos became awesome even with no money.
| jkelleyrtp wrote:
| 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 wrote:
| 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 wrote:
| 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)
| weinzierl wrote:
| 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.
| sedatk wrote:
| 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.
| jokethrowaway wrote:
| Or 10 european seniors
| sedatk wrote:
| Fair enough :)
| feznyng wrote:
| 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.
| chromatin wrote:
| 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.
| sa-code wrote:
| Would be cool to see a front end for this in Mojo when the
| language matures a bit
| oDot wrote:
| 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
| voat wrote:
| What is wrong with the dioxis approach?
| _blk wrote:
| 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)
| jjallen wrote:
| 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.
| _blk wrote:
| Totally agree. This is where you get to invest: They're still
| looking for monthly sponsors.
| https://github.com/sponsors/DioxusLabs#sponsors
| jjallen wrote:
| 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.
| mirashii wrote:
| 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
| weinzierl wrote:
| Dioxus raised venture capital, so I'd be careful before betting
| my future on them.
|
| Do they require copyright assignment or a CLA? I could not find
| anything on their GitHub.
|
| How many of their contributors are payed?
| satvikpendem wrote:
| 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.
| suby wrote:
| I'd like to report my experience trying out this release.
|
| I did a cargo install. I then used the dx command line app to
| create a new project. After initialization I ran dx serve in the
| directory as instructed, but it gave me a compiler error with
| seemingly no feedback on what specifically went wrong. And again,
| this is for a hello world app that they generated for me. I'm
| unsure how to obtain more information on why it failed.
|
| I feel like I'd have more insight and ability to debug this if I
| were trying to compile using a standard rust workflow rather than
| their CLI tool.
|
| You can press v to enable verbose logging, but this doesn't add
| information which provides clarity to me. Here's the compiler
| output with verbose logging, though heavily edited to be readable
| in this HN comment box
|
| 14:17:49 [dev] Building server...
|
| 14:17:49 [dev] Building app...
|
| 14:17:49 [dev] Executing cargo...
|
| 14:17:49 [dev] cargo args: ["--profile", "server-dev", "--
| verbose", "--features", "dioxus/server", "--bin", "hack"]
|
| 14:17:49 [dev] cargo args: ["--verbose", "--features", "desktop",
| "--bin", "hack"]
|
| 14:17:49 [dev] cargo args: ["--profile", "server-dev", "--
| verbose", "--features", "dioxus/server", "--bin", "hack"]
|
| 14:17:50 [dev] Setting builder to failed state
|
| 14:17:50 [dev] Build failed: Other(Cargo build failed, signaled
| by the compiler)
|
| Status: Failed
| jkelleyrtp wrote:
| There is a weird issue with `cargo`'s output that not all
| errors get emitted as an "error" - I just kicked off a new
| `binstall` build `cargo binstall dioxus-cli@v0.6.0 --force`
| that fixes the filtering issue.
|
| You can also press `t` for `tracing` logs which will emit the
| relevant logs. I'm sure it's something pretty simple / easy to
| figure out like a wrong version.
| danudey wrote:
| `cargo binstall dioxus-cli@0.6.0 --force`
| kussenverboten wrote:
| try updating dx first
| benatkin wrote:
| The username of one of the devs :) https://github.com/DogeDark
| kussenverboten wrote:
| It works amazingly well. Great crate!!
___________________________________________________________________
(page generated 2024-12-11 23:00 UTC)