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

Dimitri Kokkonis

@b0rk fwiw this is exactly why I made https://github.com/kokkonisd/mrbones

I wanna make the site not fight the site generator

A

@b0rk@social.jvns.ca my answer would be vanilla js (or maybe jquery at most), I’m curious what is yours

Billy Smith

@b0rk

You may want to chat with @coopcloud @autonomic and @kawaiipunk about the techstack you are using.

Billy Smith

@amcasari @adriano @b0rk

This me also.

Alternatively, we could sponsor you to write your version of these manuals:

https://flossmanuals.net/

dasgrueneblatt

@plumtrie @b0rk that looks nice

Heath Borders

@b0rk have you outlined what technical choices you've made as a result of these constraints? It feels almost like hand-writing simple HTML/CSS/JS would make sense here

Deven Phillips

@b0rk
@frankdelporte offers a good option. I also like #VitePress for customization of the CSS/HTML/JS and use it to run several similar sites myself. https://vitepress.dev/

Adam Williamson :fedora:

@b0rk same!

I actually had to write myself a README file in the directory where my blog lives so I remember how to write a new post, when I come to do it once a year or so...

Karl Dyson

@b0rk

I don't know that is necessarily dictates a different tech choice, but I think it dictates making sure it's documented / annotated sufficiently, including any and all stuff you use to automate the test/version control/build/deploy/patch/etc bits that sit around the sides of "it"...

Incomplete documentation and/or annotation is the #1 thing that bites me in the arse when I come back to something, personally speaking.

Bredroll

@b0rk sqlite is brilliant! I didn't understand why more people don't use it until I realized that with #flask, using the builtin sqlite in #python that it doesn't support threading and concurrency properly!

Greg Bell

@eta @b0rk the laws of thermodynamics tell us the new hotness will become the old tepidity

Sheogorath

@b0rk 2 more thoughts that haven't been touched on, but maybe make sense to mention:

- Make sure your theme brings all its JS, CSS and fonts with itself. (Independence from CDN disappearance)
- Use native HTML focused CSS frameworks like simplecss, because it makes porting content much easier.

Gina W

@b0rk I feel the same way about websites generally. Also about languages lately. Like, I feel like go has so much good about it but also I feel like it is a language I would have to be using full time to really write good go so I avoid using it.

Farce Majeure

@adamw @b0rk I wrote a Makefile for that.

Neil Kandalgaonkar

@b0rk After I had a personal site sink into unmaintainability, I created a framework that I hope can work for more than a decade without any changes or updates

The key was making every build step skippable. It’s all enhancement from basic HTML. If my syntax-colorer breaks in 2029 the site still builds

Adam Williamson :fedora:

@vathpela @b0rk ...but then I'd need a README to remind me of the make arguments...

Joost van Baal-Ilić

@b0rk imnsho your requirements are absolutely sane and not weird at all

mx alex tax1a - 2020 (6)

@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

Neil Kandalgaonkar

@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.

Artemis

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