i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird

@b0rk @mauve yeah, our experience is that if something claims to be lightweight but won't serve a single request without being able to talk to postgres, it is lying about being lightweigjt

@b0rk

The rule of thumb I am using is that predicted lifetime = how long it has been available. The idea is that you’re probably in the middle of a tool’s lifetime.

Major version changes that force difficult, complex migration reset the clock. (This is why venture funding tends to accelerate an open source project’s demise.)

So, sqlite and bash look safe for as long as I expect to be programming. 11ty… wouldn’t count on it.

@b0rk @Bredroll I remember this helping me quite a bit: https://fractaledmind.com/2023/09/07/enhancing-rails-sqlite-fine-tuning/

@art_codesmith thanks!

@b0rk I find myself on the opposite side of this thinking a lot. Where I’m trying to predict what my forward compatibility and thinking will be three months down the line when I come back to the five minute update project.

@b0rk i very much get the feeling. i have some Old websites i’m scared to look at too closely because those (server-side) web framework versions probably have known vulnerabilities

regarding not using JS build systems, do lock files (specifying precise versions of everything) change the equation for you? as far as i understand npm didn’t always have them

@b0rk You sound like most small businesspeople I know. They visibly cringe when someone tells them they have to keep their site "fresh" to attract visitors.

@simon lock files don’t change anything no

@b0rk Semi-answering your other question about Django, it’s reassuring that the framework has been developed for 20 years means the chances of it still running well in another twenty are not bad. The mature tools are better at surviving, I think.

Recently I upgraded a neglected project running version 1.11 (under Python 2) to the newest 5.2 LTS and the site is running happily with it. Interestingly the only problem-maker was a third party plugin.

@b0rk I love that your response to this is a simple Gist on GitHub. Not only do you prefer to use static sites, but "here is a static file to host my answer about static sites"... Very on brand.

@b0rk Good plan - so many of my write-and-forget tools have a "runme.sh" wrapper to encapsulate the PATH, venv, and whatever other requirements. It's good to have an obvious entry point.

@b0rk tech stack is very similar to mine, which must be why I agree with it.
except "try to avoid buying domains". I keep failing, pls help.

@kalfeher right now gandi.net is trying to charge me $50/year to renew a domain which is a big source of motivation to keep the number down

@b0rk I feel validated that I have landed on similar patterns. I'm a little more tolerant of a VPS but I am growing less patient with them.

@b0rk I’m a huge fan of GitHub’s scripts to tune them all pattern. I try to set them up in every project I join.

(Side Benefit of executable scripts like ./script/server, is that you can quietly upgrade them to a Perl/Ruby/whatever script without changing invocation command)

https://github.com/github/scripts-to-rule-them-all

@b0rk this resonates. Your github preferred tech stacks list makes perfect sense imo.

It’s impossible to productively use all the programming languages, hosting and service providers, and tech stacks so we have to pick based on what works for us in the moment and over time.

I try to be open to the new, but if something is too fiddly to setup or is inelegant then I think that it’s perfectly reasonable to just use what works.

@adamw @vathpela @b0rk
I've built projects where I had a README *and* a Makefile, but I still fumbled searching for the commands in my Bash history.

@badnetmask @adamw @vathpela @b0rk I like ‘just’ for this sort of thing. Just sayin’.

@b0rk
I ordered and paid for such a site recently. We're still out here

@b0rk I feel the same way. I endorse #Hugo for blogs, and for a simple wiki? #mkdocs