---
layout: '../layouts/StandaloneMDXLayout.astro'
title: Journal
slug: journal
date: 1970-01-01
summary: "My journal for smaller posts & updates."
draft: true
---
import MDXCallout from '../components/mdx/MDXCallout.astro';
import MDXAccordion from '../components/mdx/MDXAccordion.astro';
import Icon from "../components/Icon.astro";
## now
it's 4am. i need to sleep. but i will not. because i do not control the eep
---
- [ ] Make an editing pass on the last blog post (FINALLY) so I can stop worrying about it.
- [ ] Just. Write. Goddammit.
- [ ] Figure out how to make the API route serving the Atom feed ([feed.xml](../feeds/feed.xml)) actually send an xml file that can be recognized by the browser (i.e. allowing for a `.xsl` to work with it and/or opening it automatically in your RSS reader of choice).
---
# 2025-01-22
Oh my god!!! It's another year!!!!
In fact, it has officially been six-ish months since this version of my website has been around
(yes, it's only been two since I switched to Astro, but since that was more of a technical migration rather
than a whole website redesign, I'm not counting that lol).
On one hand, it is really cool that I've settled on something that I can feel proud of every time I look at it.
On the other hand, **my god do I need to put more stuff on here.**
So, here's the current plan:
- Make an editing pass on the last blog post (FINALLY) so I can stop worrying about it.
- Just. Write. Goddammit.
- Theeeeeen maybe we can worry about that fancy comments system I keep fantasizing about.
Heck, if you want to leave me a note on one of my blog posts, there's a great way to do so: email me! Or fedi me!! Or bsky me (ok maybe dont do that because i rarely use bsky)!!!
The main reason I want to implement a comments system is to build a community... but I can't really do that if
there are no people to fill it. So if you want to be a part of that, let me know.
......Completely unrelated question, does anyone want to see an eleboog.com IRC chatroom?
oh and [obligatory song link](https://www.youtube.com/watch?v=kI811LrVAu8)
# 2024-11-14
As I said in my now entry, my hyperfixation has returned to this website. I do not control the hyperfixation, and I wish it would hyperfixate on class instead, but since this is still somewhat productive, I'm okay with it being here for now.
The main thing that I did was add my first "interactive" element: the accordion.
When you click or tap on the box, it unfurls into a section that can contain literally anything I want... like an image of *another* accordion!

However, there's a problem with this: it requires Javascript to function. I want my site to be completely functional *without* Javascript. So,
there is a fallback for if JS is disabled.

Now that I know how to make stuff like this and give them noscript fallbacks, I feel much more confident about "Phase 2" of my site (implementing a comments section and account system).
The prototype version of my site with an accounts system should be coming out by mid-December. It will likely be hosted on a completely separate server (not on Hetzner lmao) and require manual approval to sign up. I'll make sure to give you a little badge next to your name in the comments if you help me out with beta testing, though :3
Currently, my ideas for Phase 2 consist of the following:
- Accounts will **not** use passwords. There will be two authentication methods available: passkeys and single sign-on. SSO is the easier of the two, as it just refers to using another site to log onto this one (right now, Google, Microsoft, and Discord are the sites I'm thinking of using for SSO). Passkeys are more secure but not fully ready for prime-time and obscure in documentation. I'm implementing them partly as a challenge to myself and partly as a way to yell at everyone else "HEY!!! THESE ARE COOL!!! WE SHOULD USE THESE MORE!!!!" I'll be sure to make a guide on how to sign up with passkeys and/or add passkeys to an existing account for those who are not in the know yet. Eventually, I will want to fully move my account system to only use passkeys, but I recognize that I can't do that *now* with the current state passkeys are in.
- Even after the beta, I'll likely have account signups operate under a manual approval / application system. Basically, you'll have to prove to me that you aren't a bot or a Nazi, and if I believe you, I'll let you in. This is my way of preventing spam and exploitation of my site.
- I want the accounts system to be flexible enough to where they can be used for things *other* than just my comments section. If I ever make a forum on my site again, the forum will use these accounts. I also want accounts to have *their own profile pages* so if you see someone in the comments you think is cool, you can check out their profile and follow them on other places. I want the comments section to be its own sort of community, and stuff like profile pages helps reinforce that aspect of community imo.
Is this way too much effort for an obscure blog's comments section? Yes. Is this just a way for me get more portfolio work done and justify it with a lofty humanitarian goal? Yes. But I think it will be worth it. It will be another thing to set my blog apart and hopefully encourage more people to check it out... and [possibly give me money](https://ko-fi.com/kebokyo).
Anyways HA IM NOT GOING TO GIVE YOU MUSIC TODAY, [THE NUKETOWN EASTER EGG DROPPED AND IT'S GREAT](https://www.youtube.com/watch?v=BMnjU3UsIS0) ok cya
# 2024-11-12
I did it. This entire site is now running on the [Astro web framework](https://astro.build) instead of Next.js.
There were two main reasons why I chose Next.js for this site originally:
1. I already had *some* experience with it in an older iteration of my website refresh (which you can see in [this blog post](/posts/2024-06-16-hello-again)), and
2. It is by far [the most popular metaframework on the web](https://share.stateofjs.com/share/prerendered?localeId=en-US&surveyId=state_of_js&editionId=js2023&blockId=meta_frameworks_ratios¶ms=§ionId=libraries&subSectionId=meta_frameworks) right now.
Both of these made it easier to get started with Next.js, and #2 made it more appealing as a learning / portfolio-enrichment experience.
However, along with these two upsides, two big problems conversely arose with Next.js:
1. Building a Next.js website (which I didn't think I had to do when I chose Next.js!!!) takes a lot more resources than I thought it would. In order to rebuild my site and make my changes live, I *need* to take the website down first on my basic bitch $7 VPS from Hetzner (put a pin on this, I'm going to talk about it later).
2. Because Next.js is designed primarly for single-page applications (SPA's), when you click on a link to another page on the site... **nothing happens**. No loading bar shows up in the browser. The site itself doesn't even show its spinner for a bit. This garbage time can be a fraction of a second or *multiple seconds* depending on how shitty your internet is. And I hate it with a passion. [**And there's no way to fix it without hacky workarounds.**](https://github.com/vercel/next.js/issues/43548) Pain.
The second problem can absolutely be fixed with Astro since it primarily relies on either static page generation (SSG) or server-side rendering (SSR), both of which make the browser show a loading bar immediately upon requesting a new page *like it should*. The first problem is still TBD because I haven't pushed this site to prod yet, but I have a feeling since Astro's whole entire shtick is SSG, it should have better optimization on that front.
Since I deliberately made this site text-focused and light on visual complexity, making everything work on Astro was surprisingly easy. There was of course a learning curve with all the ways Astro does things differently, but most problems I ran into were able to be resolved in the same sitting I found them in. I was even able to reuse some of the libraries I was already using to make the porting process easier. All in all, this site should work pretty much the same as it did under Next.js... [but better](https://youtu.be/aaZHCB5d6JI?si=1THiwFWcDyyBHZ7R&t=3). (I know, fuck this character and fuck this show but i think this meme fits here ironically lol)
The true test for Astro will come when I deploy it, though. I have never actually deployed Astro before, but since it uses (p)npm for running deployment commands, it should be easy to automate with [PM2](https://pm2.keymetrics.io) like I already do with Next.js. I *hope* it uses less resources than Next.js so I can actually leave my site running while it's updating, but time will tell.
The simplest way to fix that problem, of course, is to throw more money at the problem by upgrading to a better VPS. However, due to [issues with censorship of "pornographic content"](https://tenforward.blog/hetzner-considered-hostile-a-psa/) (parts of this article are a little sus but the big idea of "if you host a fediverse instance that doesn't completely ban nsfw content, you could get rocked by Hetzner" is scary to me), I don't really feel comfortable staying with Hetzner. I've used Vultr before but they're pretty expensive, so I might just say fuck it and move back to Linode lmao.
Hopefully, all of this change will be for the better and not for the worse. I'm rapidly running out of energy and I'm suddenly feeling very weird for no reason so I think I need to stop writing lol. also SOMEONE'S USING BONE CONDUCTION HEADPHONES RIGHT NEXT OT ME AND THEY'RE ORANGE AND THEY'RE USING EAR PLUGS WHAT IS THIS ABSOLUTELY INSANE STRAT I NEED TO INVESTIGATE THIS (one day)
right music link uuhhhhh [here's something that was in my watch later feed for a billion years](https://www.youtube.com/watch?v=EEHZqNkfcoc) ktnxbye
# 2024-10-02
[ this is not finished. it will never be finished. fuck you ]
(note to self: if this becomes 100+ lines, just make it a fucking blog post jesus christ)
Yeah, it's been a while since I made an update to this site. But hey! I got an actual post this time!!!!
Since I'm writing this while I am still working on editing the post, I'm going to leave a checklist here of things I want
to work on surrounding the site before I publish a new article.
## Syntax Highlighting
This post uses a *lot* of code blocks and `code strips` (what I'm calling "monospace" formatting). I'm really proud of where my
syntax highlighting and code block functionality is right now. However, I want to make a couple of tweaks and updates to make
my implementation first-class.
First, I need to do a quick check on whether syntax highlighting in code blocks works without JavaScript. In my eyes, it *should*, since
all of the processing happens on the server-side and all the client gets is a bunch of ``'s with different colors attached to them.
If it doesn't, I need to figure out why and fix that before publishing.
Ideally, my site should require as little client-side scripting as
possible, if any. The main reason I moved away from Zonelets (a popular blog template for Neocities) is because of how it required client-side
scripting to even function properly and let you see what posts are on the site. Especially after I moved away from Neocities, a platform
that is built around banning server-side scripting, that reliance on client-side scripting to make up for that slack seemed kinda silly
now that I *can* use server-side scripting.
I know it's kinda silly to want as little JS as possible on a site powered *by* JS/TS in the backend and on a platform designed around
single page applications & routing... but hey, a girl can have her cake and eat it too sometimes.
The other main thing regarding syntax highlighting I wanted to check is how to get it to work with Tailwind's automatic theming.
Currently, the site switches from light to dark mode with the browser / OS — there is no way for the user to set it differently.
That's something I want to change in the future, but for now it makes things Just Work™ a little better because I can use Tailwind's
automatic light/dark theming system to change colors based on theme.
Before, I just had the `MDXCodeBlock` component change its entire theme depending on whether the browser is in light or dark mode.
This had two problems: the theme only updated once, and it updated slightly *after* the rest of the site is themed properly. The theme
is set to light mode by default, so in dark mode, the theme would be too dark for half a second before the theme check actually goes through
and the code block theming fixes itself. That is very bad.
My thinking is that since what gets sent to the browser is a bunch of ``'s with colors slapped on them anyway... what if I make
those individual *colors* themed instead of changing what colors to slap on depending on the theme? The easiest way to do this would be
to make a new theme where instead of defining the color by a `color:` attribute in `style`, the color is defined by classes. That way,
not only can I build a theme with my existing Tailwind colors and themed around my site, but I can also give all tokens *two* colors
— one for light, and one for dark — using the `dark:` prefix I already use in the rest of my site.
# 2024-08-30
I am slowly realizing that I will almost forever be struck with the YGS curse until I stop having things to tweak on my blog.
I'm not sure how I feel about that. On one hand, I want to make this site into another platform of sorts for smallweb tech people.
On the other hand, I want to actually write blog posts once in a while. So... I think I may be putting that former aspect on hold until I get
into a good rhythm with my... ugh... "content". I hate that word so much.
Also I just now realized you can totally get away with just using HTML's bult-in `