this post was submitted on 11 Jun 2023
175 points (98.9% liked)
Technology
1928 readers
7 users here now
Rumors, happenings, and innovations in the technology sphere. If it's technological news, it probably belongs here.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I can't speak for everyone, but I personally do not want to work with PHP ever again. I'm sure it's gotten better, but when I last used it (>15 years ago), the standard library was super inconsistent and performance was pretty terrible. It left a bad taste in my mouth, and I now prefer client-side rendering.
But aside from my personal dislike for PHP, here is why I prefer client-side rendering:
That said, for a federated system, it doesn't really matter that much since people can just increase the number of instances to help share the load. I just personally am not interested in helping with kbin, but I would be totally on board with helping with Lemmy.
Yeah, it shows you haven't used php in a while. Most of the gripes people have with it have been fixed over the years, and every framework encourages you to build an API-first app these days.
Sure, but the whole point of PHP is the templating. If we're going to avoid that (and kbin uses it), why use PHP?
The backend is going to be request heavy, so something with good async support is going to be a good bet and scale well. I don't know much about how modern PHP handles async, but it just seems like an odd choice for something with a high volume of small changes. Anything can work if you try hard enough, but at least for me, I'm more likely to get involved with Lemmy than kbin.