Let’s say we don’t care about the backend<>frontend interconnection we see in most JS frameworks. We just want to program the backend. What would be the language of your choice?

  • Ephera@lemmy.ml
    link
    fedilink
    arrow-up
    29
    ·
    7 months ago

    I feel like you could’ve asked “what’s your favorite language?” and gotten the same responses. Like, it’s Rust for me. I could argue that because Lemmy is written in Rust, there’s already some mature libraries to work off of, but someone else could argue that for e.g. Ruby, too.

  • nous@programming.dev
    link
    fedilink
    English
    arrow-up
    10
    ·
    7 months ago

    Whatever language you chose you might want to also look at the htmx JS library. It lets you write in your html snippets better interactivity without actually needing to write JS. It basically lets you do things like when you click on an element, it can make a request to your server and replace some other element with the contents your server responds with - all with attributes on HTML tags instead of writing JS. This lets you keep all the state on the backend and lets you write more backend logic without only relying on full page refreshes to update small sections of the page.

    For a backend language I would use rust as that is what I am most familiar with now and enjoy using the most. Most languages are adequate at serving backend code though so it is hard to go wrong with anything that you enjoy using. Though with rust I tend to find I have fewer issues when I deploy something as appose to other languages which can cause all sorts of runtime errors as they let you ignore the error paths by default.

  • Paradoxvoid@aussie.zone
    link
    fedilink
    English
    arrow-up
    7
    arrow-down
    1
    ·
    7 months ago

    If I really hate front end, but still want a lot of the responsiveness of a SPA, I’d have to give ASP.NET Blazor a serious thought.

    It’s largely all back end driven, with the dynamic elements driven via webassembly that pretty much works like black magic.

  • Dojan@lemmy.world
    link
    fedilink
    arrow-up
    7
    arrow-down
    1
    ·
    7 months ago

    C#. Since I’m a .NET developer it’s the stack I’m most familiar with.

    Honestly I kind of like the idea of a front end with as little JS as possible.

  • Kissaki@programming.dev
    link
    fedilink
    English
    arrow-up
    5
    ·
    7 months ago

    You’re asking about the backend only, separated from the fronted? The fronted will be HTML only, but independent of the backend anyway?

    Doesn’t that mean you’re introducing another interface and a need for another backend for the HTML frontend generating?

    If it’s independent, why does the frontend intention matter?


    My first choice/exploration would be C#/.NET.

    • smileyhead@discuss.tchncs.deOP
      link
      fedilink
      arrow-up
      1
      ·
      7 months ago

      I just ment that there will be nothing special being done there. Server would just send the result in plan HTML, that would be used and styled as a widget in something else later.

  • eric@lemmy.ca
    link
    fedilink
    English
    arrow-up
    5
    ·
    7 months ago

    Most of my experience is in .NET at work. My professional recommendation is C#, but my personal recommendation is Go. I find Go to be just nicer to code with.

  • Mr. Satan@monyet.cc
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    7 months ago

    Maybe Go, haven’t messed with it at all and it looks interesting enough to try. Other than that I could do C#, since that’s where I have most experience. Maybe node.js if I would want to suffer a bit.

  • farcaller@fstab.sh
    link
    fedilink
    arrow-up
    3
    ·
    7 months ago

    Any language you’re comfortable with is good for that. Ruby, JS, and Go come to mind the first because they all have solid ActivityPub libraries which are going to save you some time on interconnection. Any programming language can do static html.

  • RobotToaster@mander.xyz
    link
    fedilink
    arrow-up
    3
    ·
    7 months ago

    I’ve considered doing something similar myself, honestly it would come down to which one has the best libraries/frameworks for it.

  • mojo_raisin@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    7 months ago

    Crystal + Kemal (Like Ruby + Sinatra but way faster, compiled) for the backend and templating with ECR (like ERB) and HTMX for the front-end (though HTMX is JS it feels like HTML with added features.

  • MNByChoice@midwest.social
    link
    fedilink
    arrow-up
    3
    arrow-down
    3
    ·
    7 months ago

    I would want something simple, extensible, and easily readable. I would write in the clearest way possible in Bash with small, single purpose programs handling anything performance critical.

    • mox@lemmy.sdf.org
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      7 months ago

      easily readable

      Bash

      This makes me wonder if you might benefit from exploring more programming languages.

      I’ve never found shell scripts (beyond the most trivial tasks) to be especially readable. Bourne-style shells in particular (e.g. bash) have a lot of easy-to-miss nuances that will lead to bugs if not carefully managed.

      Hats off to you if you can do a good job of it, but it sounds to me like a recipe for pain when it comes to long-term maintenance.