home.social

#leptos — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #leptos, aggregated by home.social.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. Overkill as a service: лендинг на Rust вместо конструктора

    Tilda раздражала, JS пугал, а Rust манил… В итоге я переписал лендинг на Rust + Leptos - просто потому что «а почему бы и нет?». Под катом: немного боли, пара побед, сравнение с конструктором и вывод о том, что заниматься фигнёй иногда очень полезно.

    habr.com/ru/articles/968782/

    #rust #leptos #tilda

  7. Spent the day trying to wrap my head around #Leptos. My main struggle (after configuring NixOS) is actually that it just doesn't "feel right". The differences with using signals in component props vs. directly vs. to derive values are something pleasantly absent in #Vue. Also, #Nuxt's useFetch helper makes more sense to me than server functions, which also seem to step on #Actix a bit. But maybe I'll grok it all eventually... #RubberDuck