• 0 Posts
  • 3 Comments
Joined 1 year ago
cake
Cake day: June 24th, 2023

help-circle
  • I’m not understanding the CoPilot hate. It’s an amazing tool if you are competent. Even when it gets it wrong it still saves me 90%+ of the typing then I just correct what it did differently than how I want it.

    Boilerplate becomes a breeze and I work way better when I have something to iterate on rather than coming up with it from scratch. It lets me play with and test ideas way faster and sometimes even does it differently than I’d do it which leads to learning new things and/or looking at the problem in a different way. I don’t blindly follow its output, sometimes I reject it wholesale, sometimes I edit it, sometimes it’s literally exactly what I would have typed myself.


  • mr_tyler_durden@lemmy.worldtoProgrammer Humor@lemmy.mlHTMX
    link
    fedilink
    arrow-up
    19
    arrow-down
    1
    ·
    1 year ago

    I’ve got nothing against SSR, never have, but CSR or even better SSR+CSR side steps a metric shit ton of issues. I’ve written untold lines of code to render something out in PHP then needed to add jQuery logic to the frontend for UX/UI reasons and then I’ve had to duplicate UI generation in JS/jQuery to match what PHP spits back (think: add a new row to an interface after an Ajax call finishes). It’s hell, you have to keep the two in sync and it’s a bug minefield.

    Compare that to CSR where all the DOM is generated though a single codepath. Now take CSR to the next level with SSR+CSR and you’ve got a winning combo. Fast initial render and SEO gains (if you even need that) and only 1 DOM generation pathway.

    People want to sound all smug “Oh, back to SSR are we?”, “Uh yeah, we had to CSR first to get to SSR+CSR which is VASTLY superior to SSR alone”.

    Tech is circular in that way. See also mainframes, to personal computers, to cloud or any other similar cycle.


  • I much prefer having an in-memory database than mock what a database does.

    Which sounds great in theory but then you get to find where your prod DB and testing DB differ and you have to keep chasing that. Unless you are using something like SQLite which has both (disk and in-memory) as an option.

    I worked at a place that used a different in-memory DB (H2, IIRC) in place of our MySQL DB for testing. It ended up being hell to maintain and had to have hacks for how H2 and MySQL differ (tests would work in H2 but fail if run against MySQL or vice versa).