[HN Gopher] Dioxus 0.5: Web, Desktop, Mobile Apps in Rust
___________________________________________________________________
Dioxus 0.5: Web, Desktop, Mobile Apps in Rust
Author : jkelleyrtp
Score : 259 points
Date : 2024-03-28 14:41 UTC (8 hours ago)
(HTM) web link (dioxuslabs.com)
(TXT) w3m dump (dioxuslabs.com)
| terhechte wrote:
| I build a Mastodon client with Dioxus last year [1] and it was in
| general a good experience, but it was also clear that lots of
| things were still missing (I mean, it was also at version 0.2
| when I started working on it).
|
| With these 0.5 changes the Dioxus authors remove almost all the
| complexities that I ran into when working on Ebou. I haven't
| played around with it yet, but the removal of lifetimes and
| constant cloning will make it a much more pleasant experience.
| I'm looking forward to trying it out, congratulations to the team
| for such an awesome release!
|
| [1]: https://github.com/terhechte/Ebou
| echelon wrote:
| How did you choose Dioxus?
|
| There are about a dozen Rust frameworks [1] that are trying to
| do the "native, reactive UI" you can deploy on desktop,
| web/wasm, mobile, etc. I'm worried about betting on the wrong
| horse and being stuck maintaining abandonware or being faced
| with a painful and pointless migration.
|
| In a similar evolutionary race, there were dozens of Rust HTTP
| server frameworks. Now Axum, Actix, and Rocket appear to have
| the lead. I'm worried I made the wrong choice as the community
| momentum appears to be shifting to Axum.
|
| Is there any indication Dioxus will win? It looks to have a
| large community, venture backing [2] (a good sign!), and more
| momentum than some of the others. I'd like to use one of these
| frameworks now, but I worry it's too early to place a bet. Are
| there any good indicators that now is a good time to start
| using it?
|
| Are Leptos and Yew the other top contenders? These are the two
| names I hear the most, apart from Dioxus. What would make them
| a better (or worse) choice?
|
| My company is heavily invested in Rust, Actix, and Bevy. We're
| looking at pairing Bevy with Dioxus or a similar framework to
| deliver native desktop and mobile clients in the future. I just
| want to make the right choice.
|
| Also, stupid question: is Dioxus named after the Pokemon [3]?
| The logo makes me think there's something to that, but there
| are no Pokemon references in the codebase.
|
| [1] https://github.com/flosse/rust-web-framework-comparison
|
| [2] https://www.ycombinator.com/companies/dioxus-labs
|
| [3]
| https://m.bulbapedia.bulbagarden.net/wiki/Deoxys_(Pok%C3%A9m...
| cchance wrote:
| I'd say leptos and dioxus are the bigger ones now i feel like
| many people moved from ywe to those 2
| jkelleyrtp wrote:
| Creator here, so I'm biased...
|
| Yew has had about 10 commits in the past 6 months and the
| original creator has since moved on.
|
| Leptos is a good solution for web-app type stuff, but IMO
| there's a big usability gap. I'll let the community be the
| judge there, but I wrote up some differences here:
| https://github.com/dioxusLabs/dioxus/?tab=readme-ov-
| file#dio... Leptos was fortunate enough to receive a lot of
| attention from youtubers on its launch.
|
| The most important thing here: we raised venture money for
| Dioxus. We have many years of runway, are pretty lean, and
| exclusively focused on pouring resources into making the best
| GUI library for Rust (and potentially branching out to
| Python/JS). Getting into YC isn't easy, raising money isn't
| easy, and there's currently no other Rust projects with
| similar goals, talent, and financial backing. Biased of
| course.
|
| Oh, and we're committed to the bevy integration. bevy_dioxus
| is already updated for 0.5 and we share corporate sponsors
| with the bevy folks.
|
| Final point, _legally_ , no we're not inspired by any pokemon
| with a similar sounding name. Even though that pokemon is
| awesome.
| dorian-graph wrote:
| > The most important thing here: we raised venture money
| for Dioxus.
|
| Important, but in a _bad_ way? What will the VC expect out
| of Dioxus? How will you make money?
| jkelleyrtp wrote:
| Venture doesn't necessarily mean bad. Long term the goal
| the goal is to dissolve the gates to Apple and Google's
| walled gardens, which I personally believe is a net good.
|
| As much is the idealist in me wants to do that with no
| venture backing, the realist in me knows we need Dioxus
| to be self sustaining and providing legitimate value for
| people to switch. Google spends 76 million dollars a year
| on catering alone - there's no way you can compete with
| Android and Flutter without huge resources.
|
| Apple and Google capture the value for their platforms
| via fees and lock-in. Our goal is to capture value by
| providing really good utilities for building and
| deploying apps. You can't move heaven and earth without a
| really big lever, and venture gives us more leverage.
| steveklabnik wrote:
| If you don't mind me asking, what's the actual business
| model here? Are you going to charge for those utilities?
| jkelleyrtp wrote:
| Yes, we're looking at something like a Vercel/Expo model,
| probably built on Fly, Cloudflare, or AWS, but designed
| to be self hosted.
|
| We've got a decent amount of enterprise adoption and I
| think there's money to be made by selling something like
| a self-hosted Vercel. TBD on licensing - I'd want it to
| be open source but we wouldn't want people reselling our
| deploy platform.
|
| We raised a seed to prove that people want to build with
| dioxus. If that hypotheses is validated, then we invest
| in the deploy model. If not, we have OSS grants and
| corporate sponsors that will keep the project alive for
| years even if the VC money runs out.
|
| I'm not super interested in making money at the hobbyist
| tier - those developers are our evangelists. Enterprise
| self hosting is likely harder but I think we can provide
| a _lot_ of value to teams building apps in large
| companies.
| steveklabnik wrote:
| Neat, thank you!
| SkyMarshal wrote:
| Speaking of Flutter, that and Electron seem to be the
| only really mature multi-platform build systems.
|
| What is Dioxus's competitive proposition vs those two?
| The performance and memory efficiency+safety of Rust is
| one, any others?
| jkelleyrtp wrote:
| I'd add React-Native / expo to your list.
|
| Flutter is written in Dart but renders to a canvas on the
| web making it a very, very poor choice for web apps.
| Especially backend/fullstack apps. Plus you can't use
| tailwind or whatever flavor of css library there is
| today. Flutter just nailed the "get up and running" part
| which we've got as well: `cargo binstall dioxus-cli`, `dx
| new`, `dx bundle` is literally less than 30 seconds.
| Hopefully `dx deploy` coming soon.
|
| Electron is... it's electron. A whole chromium instance,
| an IPC bridge between your frontend and the system,
| NodeJS, etc. If you compile for size, our desktop apps
| are 3mb. You can easily deploy them on an embedded/low
| end device. We're hoping to eat some market share in the
| embedded-ish land (not true embedded, but like industrial
| or POS).
|
| Dioxus also has mobile and desktop compatible server
| functions which basically no other projects have. Expo
| has been kinda exploring this space. One of our examples
| is deploying your own LLM on your own infrastructure with
| a dioxus mobile app UI and it fits in a single file and
| builds in under a minute.
| SkyMarshal wrote:
| Thanks, wasn't aware of Expo, though it seems to only do
| mobile+web apps but not desktop apps?
|
| _> If you compile for size, our desktop apps are 3mb._
|
| I'm aware of this from familiarity with Tauri, but
| hearing it again still amazes me. Very cool.
|
| I have an app in mind I want to build, and really would
| like to have standalone versions on
| Android+iOS+Linux+Mac+Windows, plus a web app. But
| there's no way I can manage all that as a single
| developer. And the fact no development tool has really
| nailed this yet is telling how hard it is. Whoever really
| gets this right will save a ton of developer hours across
| the industry, and that's valuable. Good luck, hope you
| guys pull it off!
|
| PS - one feature request: a local/offline-first mode that
| eases development of apps that work even with poor or no
| internet connection. Basically I want to build something
| like Obsidian that is multi-platform, and does all
| processing and data storage locally first, in an
| accessible format like SQLLite or flat files, then syncs
| with the cloud when available, all with as few developer
| resources as possible. A tool that enables that would be
| amazing.
| azemetre wrote:
| Yeah, it's becoming more common in my group of SWEs to
| specifically opt to NOT use VC backed software. Everyone
| has stories about companies closing shop and projects
| failing to continue onward.
|
| Why would Dioxus be any different? If VC's cared about
| tearing down walled gardens of Google and Apple, why not
| explicitly donate the money instead? Why have strings
| attached at all?
| riku_iki wrote:
| > it's becoming more common in my group of SWEs to
| specifically opt to NOT use VC backed software
|
| so, what they use instead? Bugged, dead OSS dropped by
| creators?..
| wpietri wrote:
| "There are more things in heaven and Earth, Horatio, /
| Than are dreamt of in your philosophy."
| azemetre wrote:
| No, normal OSS whose existence isn't tied to VC mostly.
| It's not like a hard/fast rule, just a heuristic.
| riku_iki wrote:
| There are very few good quality, stable, active OSS
| projects which is not fed by VC/corps money. In this case
| (UI for rust) there is no much choice.
| fabrice_d wrote:
| Funding by VC and funding by corps sponsors are 2 very
| different things. Check how linux desktop projects such
| as Gnome & KDE kept the lights on for >20 years without
| VC funding.
| riku_iki wrote:
| > Funding by VC and funding by corps sponsors are 2 very
| different things
|
| Ok, if you find corp which will give you funding for your
| project without any expectations, then it is a win. But I
| am not sure how often this happens.
| jkelleyrtp wrote:
| We have grants and corporate sponsors to keep the project
| alive even if the VC money runs out. This was all a side
| project for me at first, so I went down the "donation"
| route in the beginning.
|
| Donations are great but they're not how the system works,
| unfortunately. Dioxus could never compete with the two
| most valuable companies on earth if it wasn't a self-
| sustaining business. VC just lets me scale the team from
| 2 people to 10(?) and have some cash to iterate. We were
| "profitable" even before taking venture money.
|
| Now we're able to take on more moonshot-type projects
| like the blitz renderer, a deploy platform, UI fuzz
| tooling, and more. We're using our seed round exclusively
| to make dioxus as awesome as possible, so even if it
| doesn't work out at a venture level, there's still a
| really cool, polished, end-to-end app framework that you
| can build and ship with in Rust.
| azemetre wrote:
| That's fair and you're welcome to chart your own path,
| but I like what Tauri does with their governance model:
|
| https://dracc.commonsconservancy.org/0035/
|
| https://tauri.app/about/governance
|
| Just for me personally, I don't see the financialization
| of open source software as an intrinsic good thing and I
| reflect my technology choices to support this when
| applicable.
| jkelleyrtp wrote:
| We'll probably explore that in the future but right now
| our team is literally just 2.5 fulltime engineers.
|
| Tauri is seeking monetization via CrabNebula, but I can
| see how the governance structure would secure more
| confidence in the OSS side.
|
| http://crabnebula.dev
| nemothekid wrote:
| For a GUI based project, I'd actually prefer they were VC
| and/or corporate backed with clear governance.
|
| OSS backend libraries are easily forked, and someone is
| usually willing to hack on a database library, but GUIs
| tend to be boring to work on, and designers don't tend to
| have to the same gumption to work for free that
| developers do.
| riku_iki wrote:
| > What will the VC expect out of Dioxus?
|
| there are several ways to monetize:
|
| - consultancy
|
| - "Pro" extensions on top of OSS core
| yencabulator wrote:
| Consultancy is unlikely to give VC a 100x return.
|
| Enterprise extensions means the cursed land of open core
| and refusing to have features in the open source version,
| or a heavy SaaS push combined with a possible license
| change along the road, and these are the primary reasons
| to avoid VC-backed "open source for now".
| riku_iki wrote:
| > Enterprise extensions means the cursed land of open
| core and refusing to have features in the open source
| version
|
| yes, there are risks in exchange of VC money. You can
| branch your "Libre" project any time, and continue
| building on top of infra developed using VC funds and
| which you get for free.
|
| But what are other choices?
| unshavedyak wrote:
| > Oh, and we're committed to the bevy integration.
| bevy_dioxus is already updated for 0.5 and we share
| corporate sponsors with the bevy folks.
|
| I checked out the crate and am still a bit confused. If i
| may, is it a goal of bevy_dioxus to allow standard bevy
| gamedev but with the UI portion handled by dioxus?
| jkelleyrtp wrote:
| Yes, a big feature bevy is lacking is a decent editor.
| There's been an ongoing push to get dioxus into bevy to
| accelerate the editor development. Bevy's ECS model is
| good for games but hasn't been cleanly mapped into the
| traditional GUI space yet. Dioxus is composable so you
| can integrate it at multiple levels. The bevy folks are
| using our virtualdom plus state management with their own
| renderer.
| earthling8118 wrote:
| Axum is certainly where it is at and where it has been for a
| while in terms of HTTP server frameworks. I'd say actix is in
| second place for sure, but it is wholly viable regardless.
| Rocket is no longer in the running as far as I'm concerned,
| and it hasn't been for quite some time.
|
| Dioxus is certainly taking the head spot in front end. I
| still have more concern about the venture backing than I have
| confidence about it, but for better or for worse, it is
| certainly the best attempt at this so far. I enjoyed yew as a
| react-style framework, but its development is slow. Dioxus
| has made a lot of progress, and in my experience, it is
| currently the best experience that can be had.
|
| It's hard to say if now is the correct time, but I'd be
| watching it closely if I were you. There's been major work to
| improve the framework with many of the interfaces changing.
| Now might be a good time because of the progress made here,
| but I wouldn't be surprised if there were more changes in
| store. Although I imagine that you're used to that from bevy
| anyway.
| ryukoposting wrote:
| > in general a good experience, but it was also clear that lots
| of things were still missing
|
| I'll second that. I was working on a GUI frontend for sshfs in
| Dioxus about 9 months ago. My impression was that it's a
| really, _really_ good GUI framework... until you run into a
| wall because the developers aren 't finished with some feature
| yet.
|
| Sharing state across different contexts can also be a pain
| sometimes, but that's true of every GUI framework I've ever
| used, regardless of language or underlying technologies. Dioxus
| 0.5 looks like a big leap forward in this regard.
|
| My blog uses Dioxus to render a sizable portion of its HTML. In
| that use case, its limits aren't pushed, and it does a
| wonderful job.
| rtp4me wrote:
| Congrats to the team! I know it has been a long process, but
| kudos for sticking with it!
| jkelleyrtp wrote:
| It was 3 months of work and you probably saw our alphas kicking
| around for a while.
|
| We had been thinking about this rewrite for like 6 months, but
| put it off for a while. Glad we dove into it since the finished
| product is so much better.
| yunohn wrote:
| How does this compare to Tauri?
| jkelleyrtp wrote:
| Wrote about that here in our readme:
|
| https://github.com/dioxusLabs/dioxus/?tab=readme-ov-file#dio...
|
| Tauri puts your frontend in the webview and you need to
| communicate with native Rust functions through an IPC boundary
| (like electron).
|
| In Dioxus your Rust code lives on the native side, so you don't
| need IPC to do things like read from the file system,
| websockets, etc. Tauri also forces your frontend to compile to
| WASM, and a lot of interesting rust crates don't compile to
| wasm.
|
| It's a little hard to express how much simpler it is to build
| when you don't have an IPC boundary. Dioxus' tooling is also
| dedicated to just Rust, so you can go from zero to bundled
| `.app` in less than a minute (12 seconds fresh build, 20
| seconds fresh bundle).
|
| That being said we're huge fans of Tauri and the flexibility it
| gives you (frontend in whatever web-compatible UI you want) and
| you can even use Dioxus in your Tauri apps!
| 01HNNWZ0MV43FF wrote:
| I see what you mean, but to a reader unfamiliar with tauri
| this makes it sound really bad.
|
| Here's how I use tauri:
|
| Almost everything is native rust in the "backend" process,
| which is where main is. I don't need any ffi calls to write
| files, open ports, etc, it's a normal rust program that
| happens to have a web view.
|
| So I've never had a problem with compiling to wasm, the GUI
| is TypeScript and the business logic is aot rust
|
| The ipc boundary is annoying. It'll be faster in tauri 2, but
| in 1 it uses json or something internally, so you couldn't
| e.g. write a video player that uses a custom rust codec.
| Getting uncompressed video frames through ipc would kill perf
|
| I'll take a look how dioxus solves this
| jkelleyrtp wrote:
| One of this release's features is getting byte streams into
| the webview using custom protocols. It's not as ideal as
| say, sharing a GPU texture with the webview, but powerful
| enough to do video streaming and data viz.
| dceddia wrote:
| > Tauri also forces your frontend to compile to WASM
|
| I've been using Tauri (1.x) for a couple years shipping a
| video editor and I don't think this is true? I went searching
| to verify and I couldn't find anything saying it complies to
| WASM (or at least not that it _requires_ compiling to WASM).
| Can you point me to where you saw this?
| 01HNNWZ0MV43FF wrote:
| Whoa. Video editor is exactly what I assumed Tauri couldn't
| reasonably do. (See sibling comment - I also haven't used
| wasm since my UI is all TS)
|
| How'd you get that working?
| dceddia wrote:
| I initially ran into that issue too (sending frames over
| IPC was not gonna work!) so I create a native OS-specific
| overlay and draw on it with wgpu.
|
| The IPC layer has been a bit annoying and I'm looking
| forward to Tauri 2 where that'll get faster. I've worked
| around it for some stuff in the meantime by using a
| custom protocol and serializing stuff to binary.
| jkelleyrtp wrote:
| If you want to use a Rust frontend framework with Tauri you
| need to compile to wasm. You typically use svelte/vue/react
| etc as the frontend, or I guess you could attempt some sort
| of MPA approach with SSR.
|
| Here's a guide for using Yew with Tauri. Notice how you
| need to install wasm-bindgen and wasm-pack.
| https://dev.to/stevepryde/create-a-desktop-app-in-rust-
| using...
| dceddia wrote:
| Ohh sorry, I misunderstood what you were saying there.
| I'm just using Svelte in TypeScript and running it in the
| browser so it doesn't need to do the WASM step.
| dasloop wrote:
| "Here at Dioxus Labs, we have an unofficial rule: only one
| rewrite per year."
|
| If you have to rewrite your code once a year, maybe it helps to
| plan ahead before coding.
|
| But, if you can rewrite your code once a year, you might not have
| too much code to worry about.
| jkelleyrtp wrote:
| Agreed, but we've been doing a lot of R&D discovering new ways
| of doing things. Dioxus was the first Rust framework to do
| template-based hotreloading and we couldn't have predicted that
| was even possible 2 years ago.
|
| The Copy-state stuff also seemed impossible a year ago, so no
| way to plan ahead. Now, I think things have matured enough that
| there's hopefully not a major major rewrite for a long time.
| 63stack wrote:
| Did something happen in rust that made the copy state thing
| work? Or was it just "huh nobody thought of this before"?
| jkelleyrtp wrote:
| Someone else figured it out :-)
|
| I think we had a prototype of it a long time ago but
| couldn't figure out how to implement drop. Leptos came out
| but just leaked the runtime in its initial rev. We figured
| we could safely recycle the runtimes and voila, problem
| solved.
| palmfacehn wrote:
| How does this render native apps? Is it still within a browser
| instance of some kind?
| jkelleyrtp wrote:
| You can choose between using the system's webview as your
| renderer or an experimental WGPU-based engine that pulls in
| stylo (the piece of servo shared with Firefox).
|
| We're hoping to move folks to the WGPU renderer in the long
| term, but it's still pretty raw and many companies using Dioxus
| are pragmatic enough to know that a webview is a good enough
| solution for like 90% of apps.
| littlestymaar wrote:
| I had a mixed feeling about your idea of writing your own
| HTML renderer (because making it so it is actually compatible
| with how browser engine are rendering their stuff is actually
| very hard, and even browser vendors don't actually agree on
| how everything should render) but seeing that you are
| leveraging work from servo, and even hired a former mozillian
| in that effort makes me much more confident in your ability
| to actually deliver.
|
| I wish you good luck!
| ryukoposting wrote:
| Food for thought:
|
| I have started, stopped, rewrote, given up, and restarted
| development of a visual novel engine over and over again. My
| vision is something kind of like Ren'Py[1] but with cross-
| device game saves, cleaner packaging, improved DRM, better
| support for complex nonlinear plot development, and better
| tools for developing game mechanics that go beyond clicking
| through paragraphs of text.
|
| A mobile/desktop/web-friendly GUI library that handles both
| conventional UI elements _and_ 2D graphics elegantly would be
| a total game-changer for that project, which I 'm hoping to
| get back to eventually.
|
| I won't go into deep detail on my last stab at this project,
| but it involved making my own Ruby DSL compiler, making my
| own Ruby-to-Nim FFI library, and SDL2. It was pretty cool,
| and much faster than you'd expect, but also not very
| portable, and also nowhere close to complete.
|
| [1]: https://renpy.org/
| tvshtr wrote:
| The only webview I've seen used under Linux is gtk WebKit,
| which sucks ass. I really really hope that stylo/servo will
| eventually get there.
| m0meni wrote:
| Been following this for a while and super excited to see it out!
| I love how Dioxus captures a lot of what made React successful,
| but also while innovating on top of it and shipping at a super
| fast rate.
|
| Congrats to the team. Excited to try out the signals in this
| release.
| KolmogorovComp wrote:
| I've been following dioxus with interest despite not having a
| chance to use it yet.
|
| However I'm a bit perplexed with the solution to remove lifetimes
| [0]. Isn't it a poor's-man GC? What was the performance impact?
|
| [0]: https://crates.io/crates/generational-box
|
| Side-note: `[generational-
| box](https://crates.io/crates/generational-box)` link is broken
| jkelleyrtp wrote:
| It is poor man's GC, but the memory semantics are exactly the
| same as the previous version. Since `use_hook` owns a value for
| the lifetime of the component, that value is dropped when the
| component drops. All signals still `use_hook` so their
| lifetimes are the same. No performance impact whatsoever since
| we generally discourage calling `GenerationalBox::new()`
| outside of use_hook.
|
| Now if you spammed `GenerationalBox::new()` in a loop or
| something, yeah, your garbage will exist until the component
| drops. But most of the time folks will just push/pop from a Map
| or a Vec and regular memory semantics apply.
| ramesh31 wrote:
| >However I'm a bit perplexed with the solution to remove
| lifetimes [0]. Isn't it a poor's-man GC?
|
| This is essentially just ARC:
| https://en.wikipedia.org/wiki/Automatic_Reference_Counting
| sirwhinesalot wrote:
| Rust's Arc is like ARC, this is more like a generational pool
| of Box<dyn Any>.
| J_Shelby_J wrote:
| I'm really excited about this project because it means you can
| build a single app and deploy it easily anywhere. And in a single
| language.
| orthecreedence wrote:
| And a good language.
|
| Flutter/Dart promises this, but I really, really hate Dart.
| skybrian wrote:
| Switching from Dart to Rust doesn't seem like a usability
| improvement, though?
|
| It's good for other things like performance and safe
| concurrency, but a language that has GC seems easier for web
| development.
| orthecreedence wrote:
| I've tackled UI from both the web end and the rust end, and
| I honestly can't say which I prefer. Javascript is
| definitely _quicker and easier_ , I'll give you that, but I
| hold my nose when writing in it and people have been
| building interfaces in compiled/typed languages for decades
| without issue. I'd say it really depends on developer
| preference. I've grown to appreciate working with typed
| interfaces, and rust's compiler eliminates so many pains of
| working in the low-level space that I think it hits a
| really good mix of usability and performance. Do UIs really
| need the performance that the nerds on here gripe about
| every time something like Electron comes up? Probably not,
| so maybe HTML+Javascript (or WASM) is the winning combo. I
| don't really care either way, as long as I don't have to
| learn 5 different languages, platforms, UI frameworks, etc
| to release an app for desktop and phones as a single
| developer. And I already know Rust, so another option in
| that regard is welcome.
| mattdmrs wrote:
| Honestly curious: what makes you hate it so much?
| orthecreedence wrote:
| I found it hit a strange position between trying to be
| friendly and trying to be powerful. Things felt very
| inconsistent. After learning a few patterns in the
| language, other things I would expect to follow the same
| patterns went off in their own direction. I wish I could
| conjure up more specific examples but that's about all I
| remember from it.
|
| It felt like a language that was built for the singular
| purpose of supporting Flutter (which I actually did enjoy
| learning) instead of something that needed to exist in its
| own right. I wish they'd just picked something already
| baked.
| fngjdflmdflg wrote:
| Well, it was created before Flutter, so it wasn't built
| for that purpose. They did however steer Dart's direction
| in a way that would be more suitable for Flutter than as
| a JS replacement which is what it was created for. I
| don't think it's fair to criticize Dart in the way you
| have without giving any examples. I haven't found it to
| be trying to be powerful at all. For example it uses
| async-await, defaults to dynamic arrays and doesn't focus
| on classes as much as eg. Java. So I find it to be simple
| on all accounts. And the developers have specifically
| stated that their intention with the language is to be as
| intuitive as possible with the smallest amount of
| surprises. And I've found that to be the case. I almost
| never need to actually look at the documentation.
| Meanwhile I always find myself in MDN looking at some
| strange JS API (`Date`, for example) despite using it for
| much longer. And don't even get me started on Java.
| zengid wrote:
| Huge release, congrats! I'm most interested in Dioxus-Blitz.
| Congrats to Nico for joining the team (I think?).
| jkelleyrtp wrote:
| Yeah Nico is awesome. Between Evan and Nico, I'm sure I'm the
| worst programmer on the team!
| zengid wrote:
| You're winning because the goal is always to be in a room
| where you aren't the smartest!
| skybrian wrote:
| I'm not a Rust programmer, but I'm curious, and I'm wondering if
| someone could explain how their generational-box crate works? [1]
|
| I understand that it's some kind of arena allocation, but I don't
| understand how they support copying without copying, or how this
| is safe:
|
| > Internally, generational-box creates an arena of generational
| RefCell's that are recycled when the owner is dropped. You can
| think of the cells as something like &'static RefCell<Box<dyn
| Any>> with a generational check to make recycling a cell easier
| to debug. Then GenerationalBox's are Copy because the &'static
| pointer is Copy
|
| Like okay, you can create a pointer to static data, but what if
| it's something that doesn't have a static lifetime?
|
| [1] https://crates.io/crates/generational-box
| steveklabnik wrote:
| I am not familiar with this crate, but I am with Rust, here's
| my take:
|
| Copy is a specific thing in Rust, it means that if a type
| implements the Copy trait, it can be copied via a memcpy, that
| is, it's like a "shallow" copy as opposed to a "deep" copy.
|
| So they're not "copying without copying", they're letting you
| treat a non-Copy type as a Copy type, in my understanding.
|
| > what if it's something that doesn't have a static lifetime?
|
| The read me says it requires static content so the answer is
| "you can't do that."
| skybrian wrote:
| Could you use position-independent internal references
| (relative pointers) to make data copyable? Does Rust have
| good support for that?
| steveklabnik wrote:
| Rust does not have native support for relative pointers, so
| you'd have to hack that together with unsafe. It's not
| generally done.
| Evan-Almloff wrote:
| We are copying the reference to the data, not the data itself.
| The reference to the data lasts for the lifetime of the
| program. Generational box lets you insert data that last for
| shorter than the lifetime of the program (as long as that data
| contains no references). Once you drop the data you inserted,
| we reuse the box for other allocations.
|
| It uses a very similar approach to a generational arena but
| with boxes instead of a centralized arena (to avoid locking
| issues). If you try to access the Copy reference to the data
| after it has been dropped, it will fail with a nice error
| message
| skybrian wrote:
| Thanks. I'm wondering if this allows for non-static data at
| all? Maybe it has to be either static or copyable?
| Evan-Almloff wrote:
| All data you insert into a generational box needs to be
| allowed to last for the 'static lifetime (have no internal
| temporary pointers). You cannot insert something like &'a
| str into a generational box
| swsieber wrote:
| > There's still a tiny bit of unsafe floating around various
| dependencies that we plan to remove throughout the 0.5 release
| cycle
|
| I'd love to see what these usages are, and what motivates this. I
| understand that sometimes people reach for unsafe too eagerly.
| But the std is full of unsafe and drawing the line there
| sometimes seems like a line in the sand.
| jkelleyrtp wrote:
| It's mostly just needed to interact with FFI and declare some
| types as Send/Sync.
|
| We use it in 3 places:
|
| - fixing some FFI on iOS
|
| - enabling function-call syntax for signals (took this
| implementation from dtolnay)
|
| - implementing Send/Sync for an ID that uses a pointer as a
| hash (which honestly could be removed in lieu of a usize, now
| that I'm looking at it)
| swsieber wrote:
| Oh, OK. That sounds more like stuff you're directly
| responsible for, and it looks sensible.
| n42 wrote:
| I agree, people can be a little too afraid of unsafe. but I
| don't think it's necessarily ill-advised for a crate author to
| make a goal of removing unsafe from their crate.
|
| crate authors that try to remove all unsafe often do it to
| relieve the burden of trust from the user.
|
| _this_, in my opinion, is the power of the `unsafe` keyword
| (which probably should have been split into `trust_me` blocks
| and `check_yourself` functions). it constrains the
| conversations about memory safety into very tightly defined and
| auditable locations in the code, AND it creates new, manageable
| conversations about trust.
| hotfixguru wrote:
| Yesterday there was another really interesting rust library,
| egui, on the front page of HN. I can tell that this is more like
| react, but how do they compare in other regards?
| jkelleyrtp wrote:
| Wrote about that here:
| https://github.com/DioxusLabs/dioxus?tab=readme-ov-file#diox...
|
| You're probably not going to be building an email client or the
| next instagram in egui, but it is good for stuff where you're
| fine with re-rendering every entire frame (data viz, graphics
| stuff).
| politician wrote:
| Dioxus is framework that compiles Rust to WebAssembly in order to
| build a webapp that uses the native OS webbrowser for rendering
| and interaction.
| Evan-Almloff wrote:
| Dioxus web compiles to WASM, but we compile to native code for
| desktop rendering to make it easier to interact with native
| APIs like the filesystem. We just use the web browser for
| rendering
| sanity wrote:
| I just picked Dioxus to build a decentralized homepage for
| Freenet[1], it will be the first decentralized website people see
| when they get Freenet set up. It reminds me a bit of my Kotlin
| web framework called Kweb[2] that I've been working on on-and-off
| for a few years now, particularly the way it handles state and
| the DSL that maps from code to HTML. So far I like what I see.
|
| [1] https://freenet.org/
|
| [2] https://kweb.io/
| jkelleyrtp wrote:
| That's awesome!! I must've ran into kweb when designing the DSL
| at first - they're so similar. I'm secretly a huge kotlin fan
| and love the kotlin DSLs and concurrency models.
| ashia wrote:
| Congrats on the launch! Really excited to see the move to signals
| + curious to see how Blitz 2.0 goes.
| osener wrote:
| How does Dioxus fare as a native GUI lib? Last time I checked the
| focus was on web targets and both the built in wgpu renderer and
| skia backend were not supported as much.
| airstrike wrote:
| Yeah, that was my impression too which is why I passed on it
| and went with Tauri instead. Which is not to say that Tauri
| perfectly map to the boxes I wanted checked, but beggars can't
| be choosers
| airstrike wrote:
| I kinda wish instead of RSX we got something closer to SwiftUI
| than to React/JSX
|
| I feel like despite the name and all the good it did for JS and
| the web, React is not exactly how I would envision "reactive UI"
| code to look like in 2024 if we have the choice of designing a
| language (or DSL) from a blank state
|
| Which is not to say SwiftUI is perfect, but whatever code I write
| with it feels much more neatly organized / compartmentalized than
| similar code using React
|
| IMHO the only real advantage of using JSX for cross-platform GUIs
| is... to reuse existing libraries that were built for the web,
| which means something like RSX has very little "transferable
| value" other than letting the developer transfer their conceptual
| knowledge of JSX to RSX. I'd argue that's a worse tradeoff than
| having the developer learn some new paradigm that is (again IMHO)
| objectively superior to the React/JSX one
|
| TL;DR "SwiftUI but cross-platform" is the project I wish existed
| but doesn't. I'm aware of @Tokamak/TokamakUI but that's still
| very much incomplete and activity seems to have waned
| prabir wrote:
| There is https://ribir.org/. Currently it only supports native
| desktop apps on Linux/mac/windows but they have plans for
| WASM/web/mobile.
| airstrike wrote:
| Thanks for sharing that. It looks very interesting and I had
| not come across it even after lots of googling. It's still in
| 0.2 but I will definitely keep track of its development, so
| thank you
| nirvdrum wrote:
| Does anyone know how well this integrates with web components? I
| struggled getting Shoelace components to run well with Yew. It
| was doable, but by the time I had it working I decided I was
| using the wrong tool for the job. I'd like to revisit that
| project with another Rust framework though when I can find the
| time.
| Evan-Almloff wrote:
| We have a web components example here:
| https://github.com/DioxusLabs/dioxus/blob/fd21c971038840130f...
|
| Everything should work like normal except: attributes are not
| typed, custom event listeners must be implemented with web-sys
| nirvdrum wrote:
| Oh, that's great. I suppose it'd be nice if I could supply my
| own types, but strings aren't the end of the world. Thank you
| for pointing me at that example.
|
| Also, thank you for linking to a particular commit. I wish
| GitHub would do that by default. The web is littered with
| GitHub links that either no longer work or highlight
| incorrect lines.
___________________________________________________________________
(page generated 2024-03-28 23:01 UTC)