i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird
-
@tedmielczarek @b0rk And somehow the industry has also decided to call this
progress 
@mahryekuh @tedmielczarek @b0rk
I honestly miss the times of geocities et al. Hell, I'll even welcome MS Frontpage back.
-
i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird
- I have maybe 20 websites (mostly static but not all)
- I want to spend basically 0 time maintaining them, maybe 5 minutes every 2 months at most
- I need to be able to ignore a project for 3 years and then come back and be able to develop it easilyi feel like all of this stuff makes my choice of tech stack different than if I worked on one site full-time
@b0rk the constant churn of the JavaScript ecosystem doesn't lend itself well to that. Static site generators _can_ help, but generally less code is more, so I'd look at the actual output and see what kind of dependencies it has. Writing a small amount of JavaScript yourself for areas where you need dynamism may also be a reasonable idea -- I'd consider the amount of code in your source repo across both build and run time. (This pattern can also apply to many other areas of effort once you decide that maintenance cost and non-technical outcomes are more important than demonstrating your technical sophistication.)
Of course, I say this and then have spent the last 3 months building a dynamic site to represent results of an API. But I didn't see a better way to do it, and I'm happy to resent my choices later.
-
@tedmielczarek @b0rk And somehow the industry has also decided to call this
progress 
@mahryekuh @b0rk I'm willing to believe that using things like React does make it easier to develop and maintain Facebook, as long as you have a dedicated React team. I feel the same way about tools like kubernetes. Probably fine for Google-scale companies who have huge infra teams!
-
@b0rk the constant churn of the JavaScript ecosystem doesn't lend itself well to that. Static site generators _can_ help, but generally less code is more, so I'd look at the actual output and see what kind of dependencies it has. Writing a small amount of JavaScript yourself for areas where you need dynamism may also be a reasonable idea -- I'd consider the amount of code in your source repo across both build and run time. (This pattern can also apply to many other areas of effort once you decide that maintenance cost and non-technical outcomes are more important than demonstrating your technical sophistication.)
Of course, I say this and then have spent the last 3 months building a dynamic site to represent results of an API. But I didn't see a better way to do it, and I'm happy to resent my choices later.
@evana yeah I've had to spend so much time learning how to work with the JS ecosystem in a way that works for me, I wrote this about it https://jvns.ca/blog/2024/11/18/how-to-import-a-javascript-library/ and this https://jvns.ca/blog/2023/02/16/writing-javascript-without-a-build-system/
-
@b0rk the tech industry has aligned itself around the needs of huge corporations who have teams dedicated to maintaining their sites as well as teams dedicated to maintaining the frameworks they use to develop those sites. It's kind of ridiculous that anyone uses these technologies for personal sites!
@tedmielczarek what kinds of frameworks do you mean? i feel like I use a lot of "technologies" to build my sites, for example on my latest project I'm using S3, a Dockerfile, a managed deployment service, GitHub Actions, and probably more things.
definitely gauging what is worth it and what isn't can get complicated and sometimes I try a new thing and decide it isn't worth the complexity
-
@frankdelporte @b0rk +1 for hugo, but I run it in a container with a fixed (and now ancient) version because they aren't as backwards-compatible as I'd sometimes like...
-
i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird
- I have maybe 20 websites (mostly static but not all)
- I want to spend basically 0 time maintaining them, maybe 5 minutes every 2 months at most
- I need to be able to ignore a project for 3 years and then come back and be able to develop it easilyi feel like all of this stuff makes my choice of tech stack different than if I worked on one site full-time
@b0rk I feel the same way. I also want it to cost as little as possible and be easy for me to create content. Like content from my phone would be a win.
Currently I have an unmaintained netlify project running gatsby because at one point in time it was easy to add markdown files to a repo and have dependabot keep it updated.
-
@tedmielczarek what kinds of frameworks do you mean? i feel like I use a lot of "technologies" to build my sites, for example on my latest project I'm using S3, a Dockerfile, a managed deployment service, GitHub Actions, and probably more things.
definitely gauging what is worth it and what isn't can get complicated and sometimes I try a new thing and decide it isn't worth the complexity
@b0rk I'm primarily thinking about frameworks like React here, which seem to only work well for companies who can dedicate staff to wrangle the complexity.
-
i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird
- I have maybe 20 websites (mostly static but not all)
- I want to spend basically 0 time maintaining them, maybe 5 minutes every 2 months at most
- I need to be able to ignore a project for 3 years and then come back and be able to develop it easilyi feel like all of this stuff makes my choice of tech stack different than if I worked on one site full-time
@b0rk fwiw this is exactly why I made https://github.com/kokkonisd/mrbones
I wanna make the site not fight the site generator
-
i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird
- I have maybe 20 websites (mostly static but not all)
- I want to spend basically 0 time maintaining them, maybe 5 minutes every 2 months at most
- I need to be able to ignore a project for 3 years and then come back and be able to develop it easilyi feel like all of this stuff makes my choice of tech stack different than if I worked on one site full-time
@b0rk@social.jvns.ca my answer would be vanilla js (or maybe jquery at most), I’m curious what is yours
-
i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird
- I have maybe 20 websites (mostly static but not all)
- I want to spend basically 0 time maintaining them, maybe 5 minutes every 2 months at most
- I need to be able to ignore a project for 3 years and then come back and be able to develop it easilyi feel like all of this stuff makes my choice of tech stack different than if I worked on one site full-time
You may want to chat with @coopcloud @autonomic and @kawaiipunk about the techstack you are using.

-
This me also.
Alternatively, we could sponsor you to write your version of these manuals:
-
@b0rk fwiw this is exactly why I made https://github.com/kokkonisd/mrbones
I wanna make the site not fight the site generator
-
i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird
- I have maybe 20 websites (mostly static but not all)
- I want to spend basically 0 time maintaining them, maybe 5 minutes every 2 months at most
- I need to be able to ignore a project for 3 years and then come back and be able to develop it easilyi feel like all of this stuff makes my choice of tech stack different than if I worked on one site full-time
@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
-
i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird
- I have maybe 20 websites (mostly static but not all)
- I want to spend basically 0 time maintaining them, maybe 5 minutes every 2 months at most
- I need to be able to ignore a project for 3 years and then come back and be able to develop it easilyi feel like all of this stuff makes my choice of tech stack different than if I worked on one site full-time
@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/ -
i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird
- I have maybe 20 websites (mostly static but not all)
- I want to spend basically 0 time maintaining them, maybe 5 minutes every 2 months at most
- I need to be able to ignore a project for 3 years and then come back and be able to develop it easilyi feel like all of this stuff makes my choice of tech stack different than if I worked on one site full-time
@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...

-
i like to make websites and I've been slowly realizing that my requirements for making websites might be a little weird
- I have maybe 20 websites (mostly static but not all)
- I want to spend basically 0 time maintaining them, maybe 5 minutes every 2 months at most
- I need to be able to ignore a project for 3 years and then come back and be able to develop it easilyi feel like all of this stuff makes my choice of tech stack different than if I worked on one site full-time
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.
-
-
-
@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.
