• lorty@lemmygrad.ml
    link
    fedilink
    arrow-up
    2
    ·
    6 months ago

    Backend developer: “The new functionality is done!” PO: Looks at tests “Seems good, ship it!”

    Frontend developer: “The new functionality is done!” PO: Looks at his screen “This spacing could be a little to the right, also I think I didn’t really like this text, also it should probably auto-scroll to the top and this button should change colors when I click it and also don’t forget to change the error messages I was happy with before and also I think it should…”

    • xmunk@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      6 months ago

      I remember the day of php files outputting html to the browser… it was 95% as functional as the stuff written in react and node today and incredibly simple.

      Heck, at my company, I still sneak in old-school HTML files when I can.

  • Hugh_Jeggs@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    6 months ago

    I didn’t read the community name and wondered who tf thought the back end of a goose requires more attention than the front end

  • flashgnash@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    6 months ago

    Made the mistake of using react for a mobile app and my god why is it this convoluted, why are the error messages always along the lines of “something went wrong with networking 🤷”

    Unfortunately I’m stuck with it now

      • xthexder@l.sw0.com
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        Am I the only one left writing pure JS webpages? I swear for the stuff I’ve done recently, adding React or even jQuery makes things 10x more complicated and bloated. The base JS support browsers have now is actually great. It’s not like the old days trying to support every browser back to IE6

        • bitfucker@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          6 months ago

          When you are writing some complex web app, you will wish you used a framework. Some web apps can have more than 50 pages with multiple states that depend on remote data to be locally cached and synced depending if you are online/offline. Framework can handle a lot of the heavy state management for you and even provide a nice UI component library. But I do agree that React is too much, but jQuery is being replaced by vanilla JS. That is why I usually use Vue. But for simple stuff, yes, Vanilla JS is pretty much good enough

          • uis@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            6 months ago

            No framework will make FSM for you. Managing state of web ui is not as hard as managing state of game.

            Using TCP for networking? Loss, retransmit, lag, you’re dead. Using UDP for networking? Loss, desync, you’re dead. Sending full game state? Congestion, loss, lag, dead. Doing sync right, but still pushing too much data? Congestion, loss, lag, dead. Also keeping on server you need not only track game state, but what game state client confirmed to receive.

        • flashgnash@lemm.ee
          link
          fedilink
          arrow-up
          1
          ·
          6 months ago

          I like base JS and I like jQuery. Only reason I’m using React is for native cross platform mobile/web but I’m beginning to regret choosing it for that

          • body_by_make@lemmy.dbzer0.com
            link
            fedilink
            arrow-up
            1
            ·
            6 months ago

            I assume you mean react native, not react, unless you’re using something like capacitor. React native is a far shot from react and is much more annoying to deal with.

    • uis@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      6 months ago

      Linux has better error messages. “Dazed and confused, but trying to continue”.

      • flashgnash@lemm.ee
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        I am spoiled by dotnet and rust error messages. They tell you exactly what the problem is, where it is, and in rust’s case sometimes even how to fix it

        Then there’s C with “segmentation fault”

  • toastal@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    You can write a stateless server. You can’t do stateless front-end since you have to deal with user interaction.

    • areyouevenreal@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      I would not be so sure. Maybe for a static web page this is possible. Outside of that I think people are kidding themselves. Writing code that might be stateless in isolation but relies on a database isn’t a stateless server imo, it’s just outsourcing state to another service.

      • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
        link
        fedilink
        arrow-up
        0
        ·
        6 months ago

        With the SPA approach, you can have remarkably little state on the server because all the state associated with the user session lives on the frontend. The value of doing this obviously depends on the type application you’re making, but it can be a sensible approach in some cases.

        • areyouevenreal@lemm.ee
          link
          fedilink
          arrow-up
          0
          ·
          6 months ago

          Doesn’t SPA require polling the web server for more information? I feel like any website which retains information outside of the client device (like anything with a login page) would require state to be stored somewhere on the backend.

          • bitfucker@programming.dev
            link
            fedilink
            arrow-up
            1
            ·
            6 months ago

            What kind of polling are we talking about? If you are talking about realtime data, SSE doesn’t solve that either. You need SSE or WebSocket for that (maybe even WebRTC). If what you mean is that every time the page is refreshed then the data is reloaded, it is no different than polling.

          • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
            link
            fedilink
            arrow-up
            0
            ·
            6 months ago

            Typically, you just have a session cookie, and that doesn’t even need to be part of the app as auth can be handled by a separate proxy. The server just provides dumb data pull operations to the client in this setup, with all the session state living clientside.

            • areyouevenreal@lemm.ee
              link
              fedilink
              arrow-up
              0
              ·
              6 months ago

              That data has to be stored somewhere though. So you would still need some kind of database server to store it all or some other solution. That’s what I mean by outsourcing state. Data is still stored in the backend, just in a database rather than a web server.

              • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
                link
                fedilink
                arrow-up
                0
                ·
                6 months ago

                There is data that gets persisted and needs to be stored somewhere, and then there’s the UI state that’s ephemeral. The amount of data that gets persisted tends to be small, and the logic around it is often trivial.