• Knusper@feddit.de
    link
    fedilink
    arrow-up
    17
    arrow-down
    2
    ·
    1 year ago

    Rust in the backend and frontend, via WebAssembly. I’m using the Leptos framework for the frontend.

      • Knusper@feddit.de
        link
        fedilink
        arrow-up
        12
        ·
        1 year ago

        I enjoy it a lot. It’s the first time that I find frontend actually fun.

        A lot of the memory management aspects of Rust are bypassed by Leptos, so that doesn’t come up as much as one might think.

        And I do find Rust’s type system really helpful for actually portraying the UI state. For example, if you execute a function that can fail, you don’t have to catch some exception and then pass the error message separately into the UI or whatever.
        Instead, you get a Result-type from that function, which contains either the data you want to render in the UI or the error information you want to render instead.

        So, you can just pass that right through to your rendering code. And then there’s pseudo-HTML inline in the code, where you can do full-blown Rust-pattern-matching to properly handle such a Result-type and simply render the appropriate UI element.
        No horrid multi-line ternaries, no uninitialized variables, no separate boolean checks before accessing a variable. You simply know at all times what information is actually available.

        What’s also really nice with backend and frontend in the same language, is that you get compile-time-guaranteed compatibility between them, because you can simply use the exact same model types and API route constants.

        It is still a relatively young ecosystem, so there are still breaking changes every so often. And well, obviously you won’t find anywhere close to the number of UI component libraries as you can find for JS. So, for an experienced JS dev, it is likely a step back in productivity.

        But if you’ve got Rust expertise instead or only backend folks on your team, then I heartily recommend it.

    • Flyberius [comrade/them]@hexbear.net
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      I’ve used Nuxt a few times, but I end up in absolute hell sometimes tracing down bugs and incompatabilities. More so with Nuxt 3. Probably not an issue for more experienced Devs.

      I find myself coming back to the simplicity of running a separate backend, even though that reintroduces a lot of the problems that Nuxt alleviates.

  • OffByOneError@programming.dev
    link
    fedilink
    arrow-up
    11
    ·
    edit-2
    1 year ago

    svelte front end, golang backend, postgres for database. But it depends on the needs of the project. Choose technology because it’s the right fit for the job, not because it’s your favorite.

      • themusicman@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        10 months ago

        I think this is strictly less than 100% true. There is significant value in using tools you know and like

      • didibear@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        Well it’s difficult when the main difference between technologies is mostly preference. Real pros and cons require tons of analysis.

  • marwwin@suppo.fi
    link
    fedilink
    arrow-up
    13
    arrow-down
    2
    ·
    1 year ago

    HTMX, Python, JavaScript.

    Though I would like to try Go for the backend if I would just find some time for it.

    Also Svelte and Sveltekit is very nice

  • Thinker@lemmy.world
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    1
    ·
    1 year ago

    TypeScript React (although I like Svelte better, it’s hard to pitch for business projects), C# ASP.NET Core API, Postgresql.

  • jonwah@discuss.tchncs.de
    link
    fedilink
    arrow-up
    9
    ·
    1 year ago

    React / TypeScript / Vite (sometimes Redux) for the front end, C# .net / SQL for the backend…

    Fast-ish to get up and running, scales to a medium-large project with minimal headaches

    • douglasg14b@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Yessss.

      C#/.Net backends are the best. The long term stability, DevX, and the “it just works” nature of all the tooling makes it a great choice. It’s also fast, which makes scaling for most applications a non-issue.

      I’ve switched to postgres for DB from SQL server, have never looked back, would recommend.

      • coltorl@programming.dev
        link
        fedilink
        arrow-up
        4
        ·
        edit-2
        1 year ago

        It’s honestly not that hard, the language was made to be simple. The complexity associated with the language largely has to do with the legacy applications the language supports. If you look at a greenfield project (eg CHADstack (it’s a joke project, but pretty fun to get exposure to some esoteric stuff for a couple hours)) you’ll actually pick the language features up pretty quickly.

  • douglasg14b@programming.dev
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    1 year ago

    .Net + EF Core + Vue/TS + Postgres. Redis as needed, Kafka as needed.

    I can get applications built extremely quickly, and their maintenance costs are incredibly low. The backends are stable, and can hang around for 5, 10+ years without issue or problems with ecosystem churn.

    You can build a library of patterns and reusable code that you can bring to new projects to get them off the ground even faster.

    Would recommend.

    • 32b99410_da5b@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      But .NET has a 3 year LTS schedule unless you’re on the invincible .NET Framework 4.

      You’ll have to update your server OS at some point and then your .NET version will be too old to be installed and then you’ll have fun bugs to squash from all the new versions of things interacting…

  • Flyberius [comrade/them]@hexbear.net
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    Vue + Express + Typescript + Postgres

    Though I am playing around with Firebase and Firestore at the moment so that simpler projects have less backend overhead