• xmunk
    link
    fedilink
    arrow-up
    45
    arrow-down
    3
    ·
    10 months ago

    As an elder developer… yea, we could use react to render complex web pages that erode expected functionality.

    Or, like, I’m happy to just go back to server-side rendering… it’s surprisingly cheap to build and dead fucking simple.

    • tsonfeir@lemm.ee
      link
      fedilink
      arrow-up
      29
      ·
      10 months ago

      Elder developer here too, correctly making my SPAs has made my work significantly more efficient and maintainable now that my back end is basically a rest api and my front end requires very little network interaction after the initial load, which has been made pretty minimal.

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

        I too have been doing this for years and I whole hearty agree with this comment.

        For large complex sites, I ain’t never going back.

        Actually even for simple sites I’m not sure I’ll go back.

    • fidodo@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      10 months ago

      Elder developer too, you can easily render react server side and statically. Once you remove state, react simply becomes pure functions that output jsx nodes, it’s also dead fucking simple, but gives the the possibility to add hydration and state later if you need it.

      • xmunk
        link
        fedilink
        arrow-up
        3
        ·
        10 months ago

        This is actually excellent advice for performance - you can bake the initial page data in!

    • pixxelkick@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      10 months ago

      I prefer just writing my html, js, css, as is, and then transpiling to pack it down, treeshake, hash, cache bust, CSP, etc etc.

      The amount if headache, overhead, inversion of control, mess, and bloat involved in frameworks tends to make me spend way too much time on writing boilerplate.

      template and slot exist now, and modern js can do most of the shit fancy libs used to.

      There’s very little need for frameworks unless you meed a SUPER dynamic website that has tonnes of mutability.

      The amount if times i see people load in like 3 frameworks and 10mb of bullshit and ten js files to make a fucking static form that doesn’t even do anything fancy is insane.

      Just fucking write the like… 8 lines of normal code to populate the form, wtf? Why are we using routers at all, HTTP already exists and does that, why did we re-invent http?

      Front-end devs need to spend less time installing npm packages to try and magically solve their issues and just learn how to actually write code, SMH.

    • ris@feddit.de
      link
      fedilink
      arrow-up
      3
      arrow-down
      4
      ·
      10 months ago

      More Server side logic means more vulnerabilities on your end.

      • xmunk
        link
        fedilink
        arrow-up
        6
        arrow-down
        1
        ·
        10 months ago

        I’ve seen front ends that build queries that are blindly executed by the backend - I’ve seen GraphQL that allows the client to read arbitrary users’ passwords from the database - I’ve seen attack ships on fire off the shoulder of ori- whoops, wrong memory.

        Anyways, you can create vulnerabilities anywhere using anything - imo more server side logic might mean more vulnerabilities on the server but it means less vulnerabilities overall.