[HN Gopher] Dioxus 0.6 - Crossplatform apps with Rust
___________________________________________________________________
Dioxus 0.6 - Crossplatform apps with Rust
Author : jkelleyrtp
Score : 280 points
Date : 2024-12-11 15:24 UTC (1 days 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.
| anentropic wrote:
| The linked article literally states: Our goal is to build
| a "Flutter but better."
| jkelleyrtp wrote:
| 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?
| 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)
| palmfacehn wrote:
| 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.
| 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).
| byw wrote:
| > 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?
| nicoburns wrote:
| > 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)
| voat wrote:
| Bundle size and memory usage are still worse than leading
| js alternatives
| peutetre wrote:
| > _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?
| jkelleyrtp wrote:
| 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.
| 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?
| cardanome wrote:
| 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.
| klabb3 wrote:
| > 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.
| jkelleyrtp wrote:
| 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.
| klabb3 wrote:
| > 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?
| jkelleyrtp wrote:
| > 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
| 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
| davidatbu wrote:
| I've tried following that same guide, and I believe I've
| tried every thing on that blog post except the mold linker,
| because I'm on MacOS, and the MacOS version of the mold
| repo says "use the default linker if you have XCode 15 or
| higher."
|
| And I do think I have a pretty granular crate system (would
| be _very_ happy to hear otherwise, because that would mean
| there's low hanging compile time fruit!):
| https://github.com/dnaaun/heimisch
|
| My current _incremental_ compilation time swings anywhere
| between 15 seconds and 3 minutes (no, I'm not kidding). And
| I work on an M3 max macbook pro.
|
| ---
|
| Things that I suspect are making my compile times worse:
| 1. The fact that I am doing SSR, which means my frontend
| code is included in the backend code as well. 2. I
| _think_ Rust is unnecessarily recompiling dependencies on
| incremental builds? (I don't understand how incremental
| compilation times can be so bad otherwise). But I'm
| clueless about how to go about debugging that.
| IshKebab wrote:
| I also had an issue where Rust was recompiling
| dependencies unnecessarily. It turned out to be because
| rust-analyzer has one more level of `Bash` than VSCode's
| integrated terminal. My `.bashrc` was loading something
| unconditionally which meant if you nested bash sessions
| the PKG_CONFIG_PATH changed (duplicate entries).
|
| I had OpenSSL as a dependency, and if `PKG_CONFIG_PATH`
| changes it rebuilds it (this is correct), which means if
| you make an edit to a file and save it, rust-analyzer
| would blow away the cache, then you build it on the
| command line and it blows it away again.
|
| To test:
|
| 1. If you quit VSCode and do an incremental build is it
| still slow? 2. Try
| `CARGO_LOG=cargo::core::compiler::fingerprint=info cargo
| build` (took me a while to find that; there is a bug open
| to make it less stupidly hard to find).
|
| That will print a load of info about why Cargo is
| rebuilding stuff. Note that it isn't really in a sensible
| order - the first message isn't necessarily the cause.
| The message about the environment variable changing was
| somewhere in the middle for me, so read the whole log.
| davidatbu wrote:
| Thanks for that very helpful tip! According to the output
| of that, no unnecessary recompilation is taking place.
|
| I actually figured out the issue! It turns out, I had
| unquestioningly transplanted the following from the blog
| post in discussion, and that is the cause of all my
| issues: [profile.dev] opt-level
| = 1 [profile.dev.package."*"] opt-
| level = 3
|
| Removing that seems to give me an order (or two) of
| magnitude reduction in compile times.
|
| (Worth noting: it was passing RUSTFLAGS=-Ztime-passes
| that made me look here because, apparently, `llvm_passes`
| was taking the majority of the time).
| marcyb5st wrote:
| 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.
| davidatbu wrote:
| 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!
| marcyb5st wrote:
| Np! And glad you managed to also solve the issue! Sadly
| with niche things (leptos still is IMHO) hiccups are
| expected:)
| obsoleszenz wrote:
| > 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.
| davidatbu wrote:
| It turns out this wasn't my issue (more on this on other
| threads here), but I genuinely appreciate your time and
| help.
| bobajeff wrote:
| Yeah compile times were an issue back when i was trying
| Dioxus out too. Their `hot reload` was noticably not terribly
| hot for me. Stark contrast to what I'm used to in the node.js
| world.
| jkelleyrtp wrote:
| This version fixes a lot of inconsistencies in our hot-
| reload. We can't reload all Rust code, but we can reload
| some simple Rust expressions and way more RSX.
| weinzierl 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.
| davidatbu wrote:
| 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).
| 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 :)
| IshKebab wrote:
| European programming salaries aren't _that_ low. It 's
| probably more like 6 for a year (remember companies pay
| tax and pension too).
| rapsey wrote:
| It varies a lot. Are they in Bosnia or are they in
| Germany.
| zipy124 wrote:
| Only in the US. You could get 10 good Devs in London for
| this money, or even more juniors/internship.
| 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.
| gbjma wrote:
| 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!
| 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.
| huevosabio wrote:
| My understanding of Leptos is that it is based in WASM, right?
| So this is in case you want to use Rust and deploy in Web, but
| it isn't a native solution. I guess you can use Tauri and then
| its Rust all over.
|
| My feeling is that if you are going to use a webview, you might
| as well use Typescript and a battle tested framework.
| solarkraft wrote:
| 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
| 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?
| oDot wrote:
| I wouldn't say it's outright wrong, I just much prefer the
| ergonomics of an orderly, TEA-like state management. Many of
| the projects I make lend themselves well to that approach.
| tharmas wrote:
| Tyrian is the Scala.js framework that follows TEA.
| https://tyrian.indigoengine.io/
| cardanome wrote:
| 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.
| hobofan wrote:
| 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.
| oDot wrote:
| 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.
| _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.
| smilekzs wrote:
| +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.
| jjallen wrote:
| 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.
| jkelleyrtp wrote:
| 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.
| jjallen wrote:
| 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!
| 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?
| cies wrote:
| Good questions. We need to be careful in deed when picking a
| fundament.
| 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!!
| solarkraft wrote:
| 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.
| ryukoposting wrote:
| 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.
| revskill wrote:
| 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.
| ianpurton wrote:
| 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.
| tdomhan wrote:
| 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!
| ecmascript wrote:
| It's cool but I could never live with that syntax. Impossible to
| read, it feels like.
| jkelleyrtp wrote:
| 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
| solidninja wrote:
| 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)
| trentontri wrote:
| Have you considered contributing to Tauri?
| sionisrecur wrote:
| Tauri offers Dioxus as front-end framework when you create a
| new project.
| gr4vityWall wrote:
| 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.
| rubymamis wrote:
| 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
| adastra22 wrote:
| 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.
| jvanderbot wrote:
| 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
| jkelleyrtp wrote:
| 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.
| _bin_ wrote:
| 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.
| jkelleyrtp wrote:
| 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.
| _bin_ wrote:
| yep i've certainly seen it all over with rust. shame. glad
| things are moving along well and thanks for the work on this,
| i very much hope it becomes a standard in the future.
___________________________________________________________________
(page generated 2024-12-12 23:02 UTC)