#dioxus — Public Fediverse posts

So I have read some more about the whole #dioxus vs #tauri plus #leptos plus #axum for a #rust #rustlang #desktop app.

From what I read by now, I would say that I will try the tauri route next. I would still prefer if Dioxus would just work, but what makes me wary about whether Dioxus would be a sustainable choice is that there's a lot of issues in the Dioxus repository that do not even have a reply by a maintainer. My own issues (which are relatively young!) have only little interaction. I get that this is an open source project and maintainer overload and so on, sure. But there's also something about Dioxus being funded? So there are full-time devs (plural!) working on it? What can I say? This makes me wary.

Going down that tauri route would mean that I would need to build the whole thing myself. That could work, but is more than I would have liked to do. I want to develop my app functionality, not set up a GUI development environment.

I could also go for a TUI first, but tbh, I would rather like to have a GUI first, with a clean API that I can then reuse to build a TUI on top of it. Not sure why, the other way around would probably work as well 🤔.

Either way, I would then try leptos as framework for the app, because it looks rather good from what I can read from its documentation, and I can use axum in the backend, which I think fits my needs as well. (Btw developing this with ratatui with a axum backend would also be possible, but that's not the "native way" for a ratatui app, but much more for a leptos app as I understand it, so I expect less headaches here).

I hope I can get a MVP fast, so I can get back to developing my core application stuff, because there's sooo much missing still.

So I have read some more about the whole #dioxus vs #tauri plus #leptos plus #axum for a #rust #rustlang #desktop app.

From what I read by now, I would say that I will try the tauri route next. I would still prefer if Dioxus would just work, but what makes me wary about whether Dioxus would be a sustainable choice is that there's a lot of issues in the Dioxus repository that do not even have a reply by a maintainer. My own issues (which are relatively young!) have only little interaction. I get that this is an open source project and maintainer overload and so on, sure. But there's also something about Dioxus being funded? So there are full-time devs (plural!) working on it? What can I say? This makes me wary.

Going down that tauri route would mean that I would need to build the whole thing myself. That could work, but is more than I would have liked to do. I want to develop my app functionality, not set up a GUI development environment.

I could also go for a TUI first, but tbh, I would rather like to have a GUI first, with a clean API that I can then reuse to build a TUI on top of it. Not sure why, the other way around would probably work as well 🤔.

Either way, I would then try leptos as framework for the app, because it looks rather good from what I can read from its documentation, and I can use axum in the backend, which I think fits my needs as well. (Btw developing this with ratatui with a axum backend would also be possible, but that's not the "native way" for a ratatui app, but much more for a leptos app as I understand it, so I expect less headaches here).

I hope I can get a MVP fast, so I can get back to developing my core application stuff, because there's sooo much missing still.

So I have read some more about the whole #dioxus vs #tauri plus #leptos plus #axum for a #rust #rustlang #desktop app.

From what I read by now, I would say that I will try the tauri route next. I would still prefer if Dioxus would just work, but what makes me wary about whether Dioxus would be a sustainable choice is that there's a lot of issues in the Dioxus repository that do not even have a reply by a maintainer. My own issues (which are relatively young!) have only little interaction. I get that this is an open source project and maintainer overload and so on, sure. But there's also something about Dioxus being funded? So there are full-time devs (plural!) working on it? What can I say? This makes me wary.

Going down that tauri route would mean that I would need to build the whole thing myself. That could work, but is more than I would have liked to do. I want to develop my app functionality, not set up a GUI development environment.

I could also go for a TUI first, but tbh, I would rather like to have a GUI first, with a clean API that I can then reuse to build a TUI on top of it. Not sure why, the other way around would probably work as well 🤔.

Either way, I would then try leptos as framework for the app, because it looks rather good from what I can read from its documentation, and I can use axum in the backend, which I think fits my needs as well. (Btw developing this with ratatui with a axum backend would also be possible, but that's not the "native way" for a ratatui app, but much more for a leptos app as I understand it, so I expect less headaches here).

I hope I can get a MVP fast, so I can get back to developing my core application stuff, because there's sooo much missing still.

So I have read some more about the whole #dioxus vs #tauri plus #leptos plus #axum for a #rust #rustlang #desktop app.

From what I read by now, I would say that I will try the tauri route next. I would still prefer if Dioxus would just work, but what makes me wary about whether Dioxus would be a sustainable choice is that there's a lot of issues in the Dioxus repository that do not even have a reply by a maintainer. My own issues (which are relatively young!) have only little interaction. I get that this is an open source project and maintainer overload and so on, sure. But there's also something about Dioxus being funded? So there are full-time devs (plural!) working on it? What can I say? This makes me wary.

Going down that tauri route would mean that I would need to build the whole thing myself. That could work, but is more than I would have liked to do. I want to develop my app functionality, not set up a GUI development environment.

I could also go for a TUI first, but tbh, I would rather like to have a GUI first, with a clean API that I can then reuse to build a TUI on top of it. Not sure why, the other way around would probably work as well 🤔.

Either way, I would then try leptos as framework for the app, because it looks rather good from what I can read from its documentation, and I can use axum in the backend, which I think fits my needs as well. (Btw developing this with ratatui with a axum backend would also be possible, but that's not the "native way" for a ratatui app, but much more for a leptos app as I understand it, so I expect less headaches here).

I hope I can get a MVP fast, so I can get back to developing my core application stuff, because there's sooo much missing still.

So I have read some more about the whole #dioxus vs #tauri plus #leptos plus #axum for a #rust #rustlang #desktop app.

From what I read by now, I would say that I will try the tauri route next. I would still prefer if Dioxus would just work, but what makes me wary about whether Dioxus would be a sustainable choice is that there's a lot of issues in the Dioxus repository that do not even have a reply by a maintainer. My own issues (which are relatively young!) have only little interaction. I get that this is an open source project and maintainer overload and so on, sure. But there's also something about Dioxus being funded? So there are full-time devs (plural!) working on it? What can I say? This makes me wary.

Going down that tauri route would mean that I would need to build the whole thing myself. That could work, but is more than I would have liked to do. I want to develop my app functionality, not set up a GUI development environment.

I could also go for a TUI first, but tbh, I would rather like to have a GUI first, with a clean API that I can then reuse to build a TUI on top of it. Not sure why, the other way around would probably work as well 🤔.

Either way, I would then try leptos as framework for the app, because it looks rather good from what I can read from its documentation, and I can use axum in the backend, which I think fits my needs as well. (Btw developing this with ratatui with a axum backend would also be possible, but that's not the "native way" for a ratatui app, but much more for a leptos app as I understand it, so I expect less headaches here).

I hope I can get a MVP fast, so I can get back to developing my core application stuff, because there's sooo much missing still.

Built a full-stack Rust web app entirely with Claude Code. Claude wrote all the code, I just directed the features, architecture and tech.

Stack:
- Axum with async-graphql API
- Dioxus WASM frontend
- ReDB database

It's an artillery calculator for the game Foxhole — place markers on maps, get firing solutions with wind compensation.

Feel free to check it out: https://arty.dp42.dev
Source code on my github

#Rust #WASM #Dioxus #Axum #AI #ClaudeCode #OpenSource #GameDev

Built a full-stack Rust web app entirely with Claude Code. Claude wrote all the code, I just directed the features, architecture and tech.

Stack:
- Axum with async-graphql API
- Dioxus WASM frontend
- ReDB database

It's an artillery calculator for the game Foxhole — place markers on maps, get firing solutions with wind compensation.

Feel free to check it out: https://arty.dp42.dev
Source code on my github

#Rust #WASM #Dioxus #Axum #AI #ClaudeCode #OpenSource #GameDev

Built a full-stack Rust web app entirely with Claude Code. Claude wrote all the code, I just directed the features, architecture and tech.

Stack:
- Axum with async-graphql API
- Dioxus WASM frontend
- ReDB database

It's an artillery calculator for the game Foxhole — place markers on maps, get firing solutions with wind compensation.

Feel free to check it out: https://arty.dp42.dev
Source code on my github

#Rust #WASM #Dioxus #Axum #AI #ClaudeCode #OpenSource #GameDev

Built a full-stack Rust web app entirely with Claude Code. Claude wrote all the code, I just directed the features, architecture and tech.

Stack:
- Axum with async-graphql API
- Dioxus WASM frontend
- ReDB database

It's an artillery calculator for the game Foxhole — place markers on maps, get firing solutions with wind compensation.

Feel free to check it out: https://arty.dp42.dev
Source code on my github

#Rust #WASM #Dioxus #Axum #AI #ClaudeCode #OpenSource #GameDev

Built a full-stack Rust web app entirely with Claude Code. Claude wrote all the code, I just directed the features, architecture and tech.

Stack:
- Axum with async-graphql API
- Dioxus WASM frontend
- ReDB database

It's an artillery calculator for the game Foxhole — place markers on maps, get firing solutions with wind compensation.

Feel free to check it out: https://arty.dp42.dev
Source code on my github

#Rust #WASM #Dioxus #Axum #AI #ClaudeCode #OpenSource #GameDev

Today I found a TUI for managing translations! 💯

🗂️ **lingora** — A localization management tool for Fluent translation files

🌀 Detect missing/redundant translations + validate dioxus-i18n usage

🦀 Written in Rust & built with @ratatui_rs

⭐ GitHub: https://github.com/nigeleke/lingora

#rustlang #ratatui #tui #i18n #localization #fluent #dioxus #devtools #terminal

For a quick test of #dioxus I implemented a web interface for #faup-rs, you can see the demo website (all running locally in webasm) https://faup.claudex.be/

cc @qjerome

https://codeberg.org/claudex/faup-rs

#rust #faup-web

For a quick test of #dioxus I implemented a web interface for #faup-rs, you can see the demo website (all running locally in webasm) https://faup.claudex.be/

cc @qjerome

https://codeberg.org/claudex/faup-rs

#rust #faup-web

For a quick test of #dioxus I implemented a web interface for #faup-rs, you can see the demo website (all running locally in webasm) https://faup.claudex.be/

cc @qjerome

https://codeberg.org/claudex/faup-rs

#rust #faup-web

For a quick test of #dioxus I implemented a web interface for #faup-rs, you can see the demo website (all running locally in webasm) https://faup.claudex.be/

cc @qjerome

https://codeberg.org/claudex/faup-rs

#rust #faup-web

For a quick test of #dioxus I implemented a web interface for #faup-rs, you can see the demo website (all running locally in webasm) https://faup.claudex.be/

cc @qjerome

https://codeberg.org/claudex/faup-rs

#rust #faup-web

There's #ratatui #dioxus #yew #leptos and so on and so forth...

You know what I wonder? Why are there no libraries for full views for any of those? Like... A complete thing I can import to have a view to analyze the logging of my app (there's only one for Ratatui, but I haven't found something like that for the others).

Or a View for analyzing traces, something like Tracy, that I can import and embed in my app.

Or a view that I can embed to have a full WYSIWYG editor?

For all of these, there are only some component libraries for dropdown elements or whatever, but nothing that gives me a whole view of something.

#rust #rustlang

O__o

The #tauri + #yew example setup just works... now I think I will play a bit with this and see whether it gets me somewhere, if #dioxus does not work out of the box, it might be a viable alternative? 👀 🤔

I’m learning Rust and have been building Ferrocrypt, a small cross‑platform encryption tool (Rust core lib + CLI + Dioxus GUI + Tauri GUI).

It uses XChaCha20‑Poly1305 + Argon2id and a hybrid RSA+XChaCha20 mode with Reed–Solomon parity for header recovery.

I’d really appreciate a code review (lib/CLI/GUI, error handling, idiomatic Rust).

Repo: github.com/alexylon/Ferrocrypt

#rust #rustlang #rustaceans #dioxus #tauri #cryptography #infosec

@tuban_muzuru An alternative to egui would be a frontend framework like Yew or Dioxus, which would let you interact with the DOM.

However, as long as you don't want accessibility support, I think egui is pretty stable and a good option for more app-based websites.

Edit: Yew is dead so try another one here: https://github.com/flosse/rust-web-framework-comparison

#egui #rust #rustlang #yew #dioxus #web #webdev #website #html #wasm #webassembly

The Dioxus Dilemma: When AI Misleads and Trust Erodes

In a shocking twist of discovery, a developer's quest for a type-safe CSS solution in the Dioxus framework leads to the unsettling realization of AI-generated misinformation. This experience raises cr...

https://news.lavx.hu/article/the-dioxus-dilemma-when-ai-misleads-and-trust-erodes

#news #tech #Dioxus #TypeSafeCSS #AIMisinformation