Hi, i believe this is where https://groups.google.com/g/django-developers/c/C_Phs05kL1Q
misterbngo
joined 3 months ago
They've explained why
Man this company has had some really interesting ideas and then the execution always falters.
I was still subscribed when the first eve-fps crossover they attempted. it seemed great and then for whatever reason a console exclusive with a subscription fee ontop. They didnt get the numbers they were planning for and the whole thing just died on the vine.
They've had some neat tech here and there and the whole experience is great for building out your psychopathy but i lost interest after the Greed Is Good phase of CCCP games started.
I signed up to this instance because I feel this in my bones.
I cut my teeth on PHP CGI in the late 00's before shifting to python CGI because my university had banned PHP on the webservers.
Frontend wasn't exactly a term back then. I'd picked up a bit of jquery into my server generated Django templates, I was playing with template fragments in 2011 and life was good.
I mostly avoided the SPA fad, but a (short) stint at Wayfair had me end up writing react and dear God the amount of indirection and tomfoolery involved with effectively writing the app a second time left a sour taste in my mouth.
These days I mostly write embedded daemons in rust for Linux devices. I wrote a munin replacement in rust because packaging perl for Yocto is a struggle. I needed to serve a website, so I found a jinja style library, setup my templates and fragments and dropped htmx into the frontend.
Life is good again.
I have friends/coworkers who argue with me that I should write SPAs but they don't get that I mostly want to avoid fighting frontend tooling and get shit done. A backend serving templates is miles more ergo than react and I don't have to deal with the NPM upgrade treadmill. I don't get daily dependabot alerts.
Don't get me started on golang, meteorjs, and lambdas
Ah good to know, shame it's been left by the wayside a bit. Was super useful in the early days
I think the gap you have is in understanding that Podman Compose was meant to line up with the limitations of docker's compose, but technically is more capable.
Quadlet files let you do more complex workflows like deploying multiple copies of a service in your deployment that regular compose doesn't, while not running full kube.
The use I have is that I have something deployed in compose right now that I'd like to scale up on the box since i have the capacity for it, but dont want to deal with a full kube setup or the politic
Personally I've converted most of my single node k3s to using quadlet files instead as its less fragile. I absolutely deploy single containers in the quadlet. They show up in journalctl and the ergonomics are great.