I’m an experienced backend developer. To me, the backend world seems super simple compared to the frontend world.

It seems like there are a million options and I don’t have the experience to say what’s good and what’s not. I’m hit with major choice paralysis, basically.

I don’t have any special requirements - I “just” want to build a pretty standard, responsive, modern-looking UI. Ideally without too much boilerplate, in a framework that “feels good”, in a way that might at some point attract other contributors as well, if I get to the point of open sourcing.

Of course I could just reach for the most popular thing i.e. React, but that doesn’t seem to be the “hip” thing to use nowadays (or maybe I’m wrong? What do I know, I’m a backend dev).

But even if I choose a framework, there’s a million other libraries out there to choose as well. For instance, which UI library to choose? What about observability and state management and authentication and so on?

Sorry if this is a bit ranty. I am honestly just looking for an experienced frontend developer to point me in some direction (i.e. some set of frameworks/libraries; a “stack” if you will), so I can get out of this choice paralysis.

What would be your go-to stack for a new frontend project today?

  • Ephera@lemmy.mlEnglish
    2·
    3 days ago

    We use Leptos at work, which is similar to Dioxus and Yew.

    Main downsides:

    • You can’t really pull in component libraries, where someone has implemented more complex UI elements before. You will need to code more of these yourself.
    • Because it’s mostly delivered as a big WebAssembly blob, it’s only really suitable for Single-Page-Application-style webpages (SPAs).

    Main upsides:

    • You get to use similar syntax and libraries as you do in the backend. Frontend code still has a very different paradigm, so it’s not completely free to jump between the two, but the hurdle is definitely lower.
    • You can share code between frontend and backend. In particular, this means it is enforced at compile-time that frontend and backend share the same API.
    • Some of the common code patterns benefit quite a bit from Rust’s design.
      For example, for conditionally displaying different UI elements, rather than JavaScript’s multi-line ternaries, you can use Rust’s normal if-else expressions as well as match-blocks.
      And when you make a request to the backend, you get back a Result. You can pass that up into the display code. If it contains an Ok value, you display the rendered component with the data inside. If it contains an Err, you render the error where the component would normally be.
    • SorteKanin@feddit.dkOP
      1·
      3 days ago

      We use Leptos at work

      Wow that’s bold! Sounds like a cool place to work. Is your workplace by any chance looking for new Rust developers? 😆

      How did you come to that decision? From a sort of business standpoint, it seems very risky to adopt technology such as Leptos in a production setting. Or perhaps you only use it for smaller things internally or something?

      • Ephera@lemmy.mlEnglish
        2·
        3 days ago

        Well, it’s only my current project that uses Leptos. I didn’t mean for it to sound like the whole shop does.

        But yeah, to be allowed to do that in our project, us coders put in the legwork and assumed responsibility for that decision. Like, we started into this project with three seniors, all of us with a backend focus, but two of us had built a Leptos UI in our freetime, while none of us felt confident in being able to put out a JS frontend.

        To some degree, yeah, it is cool that management does allow us to take responsibility for technical decisions. But well, it’s not like they had frontend devs layin’ about that they could’ve swapped into the project, so when we told them we can make it work with Leptos, they were like, sure, make it work.

        I also have to say that the project is not yet technically in production. It should be by the end of the year. But yeah, the UI was pretty much done two years ago.
        We only had one really gnarly Leptos upgrade at the start of this year, where they made lots of breaking changes and it took three consecutive days to get our UI to compile again.
        But hopefully Leptos won’t need larger breaking changes for a while and, aside from two logic bugs we introduced during the upgrade, it did work flawlessly once it compiled, so in some ways that did increase my confidence in it. Like, if it was JS or TS, we would’ve just not done a similarly large upgrade.