Reworking the Main Site

Last Update On: Sun, 1st March 00:00 (2026)

Date: March 1st, 2026 23:00

I literally already did this a while back. Last year at least. But it was surface-level.

Like here’s my problem - it’s starting to become a pain to improve or fix my site. It’s a clusterfucked mix of ideas and implementations that I had over the past many years, and with every year I learn more and more. Which has me looking back at some of my decisions and wondering why in the hell I decided to do them that way.

Firstly, I should probably start by listing all of the big blocks to consider and/or worry about.

Date: March 2nd, 2026

• Framework
  • For this part, I’d likely go with Astro. Kinda fell in love with it while working on this project, and it felt really nice to work with.
  • Not to mention that it allows me to experiment with other UI Frameworks like React or Solid on my site, which is fun.
• Websockets
  • Currently I use Socket.IO, and honestly I’d like to pivot to a more custom solution. The only problem is that I don’t even know where to start, and it sounds like a pain.
  • I mostly want to move away from it to have more control, and remove a dependency. It works basically flawlessly. So I might not even end up moving away.
  • My biggest question is if it works with Astro. Presumably it has to, since it’s just client-side JS, but I’m not sure how many pain points there are, since I also need to maintain state.
    • It seems, from the Astro documentation, that they support stores, so this could resolve the issue. Especially if I represent the WS dependent parts with external frameworks
• Database
  • I’ll probably stick to what I’m currently using. Pocketbase is pretty good. I could look into a different system, but I’m not sure how much I’d benefit since the main reason to do so would be more power alongside a better UI.
  • Pocketbase delivers really strongly on the UX though, especially with how easy/trivial it can be to interface with it in JS. Plus, I don’t want to add even more overhead to this.
  • I might work on my structure more, like for the schema - but that would require migrations which… yeah, nevermind.
• System Architecture
  • Probably won’t move away from Node for the main backend. What I might do is mess around with the dependencies and how the logic is segmented.

As for the website itself, it shouldn’t be too big of an issue. Like, most of the content is there, I’d just need to restructure how it is displayed or implemented. The most complicated parts of the process are listed above - though theming might be cut since I feel like it causes too much complexity in order to have it work in a way I’m satisfied with.

I could use a sort of nested layout approach — with a parent layer that chooses the right sub-layer passed on properties that are passed in. Something like this:

---
import L1 from "...";
import L2 from "...";
import L3 from "...";

const { sublayout } = Astro.props;

let Inner;

switch (sublayout) {
    case "main": Inner = L1;
    case "alt1": Inner = L2;
    case "alt2": Inner = L3;
    default: Inner = L1;
}
---


<Inner>
    <slot></slot>
</Inner>

Question being if this would even work. I mean… it should, I think? It feels correct at least.

Honestly, the best approach might just be to rework the frontend only and leave the backend as is, at least for now. I mean, it works. I’m not very happy with its structure, but that’s moreso the inner formatting than the actual API, so theoretically I can go in and improve it whenever.