this post was submitted on 03 Feb 2024
482 points (94.1% liked)

Programmer Humor

32078 readers
302 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] xmunk@sh.itjust.works 43 points 7 months ago (4 children)

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 29 points 7 months ago (1 children)

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 1 points 7 months ago (1 children)

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.

[–] tsonfeir@lemm.ee 1 points 7 months ago

If I ever have to do this again, I’ll scream.

<a href=“”>

[–] fidodo@lemmy.world 6 points 7 months ago (1 children)

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@sh.itjust.works 3 points 7 months ago

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

[–] pixxelkick@lemmy.world 2 points 7 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 -1 points 7 months ago (1 children)

More Server side logic means more vulnerabilities on your end.

[–] xmunk@sh.itjust.works 5 points 7 months ago (1 children)

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.

[–] ris@feddit.de 1 points 7 months ago

Why does it mean less vulnerabilities overall?