good morning.

Time for a new website. Actual life things came up, and I was in sore need of some solid ‘productive’ procrastination, so I came to the age-old conclusion that my website needs a revamp.

Fairly straightforward project, with some key tidbits I really felt were necessary:

1. Svelte(Kit)
2. Fancy graphics
3. Blog (this very blog, retrospective blogception)
4. An ‘archive’

Svelte just feels comfortable. Used it again recently for my dissertation so was all warmed up, and it’s just so convenient to work around. Using bun too: I’m attached if only because they named the company behind it Oven.

It has to look good, of course, but I have unreasonably high standards for my own presentation so it has to have something standout. The wow, if you will. I’ll try graphics programming eventually but not now, so this will be a mix of ‘open-source components’ (e.g., reactbits) adapted to Svelte and my taste.

A blog! Exactly where I’m sure you’re so gladly reading this very paragraph, reveling in the sheer wisdom these very opinionated decisions surely hold. I’d stubbed out the page on at least one of the previous versions of this website, but never quite got around to it.

Very vague, but I wanted ‘somewhere to collect and share things that are cool and interesting’. And ‘archive’ sounds fancy enough to justify it.

I came to want more later, with a growing interest in putting together some data visualisations, but mostly limited the scope to these points for now. More later, after the actual productive things and that whole graduation shtick.

Regardless of the motivation, let’s get into it.

Keeping things simple, it comes down to four routes:

• Landing (or Home/Hero/Root)
• Projects
• Blog
• ‘Archive’

Which, I can appreciate may seem convoluted to non-Svelters (i’m coining that term), is the following with SvelteKit (a filesystem-based router):

src/
├── ...
└── routes/
	├── +layout.svelte
	├── +page.svelte
	├── archive/
	│   └── +page.svelte
	├── blog/
	│   ├── [slug]/
	│   │   ├── +page.svelte
	│   │   └── +page.ts
	│   ├── +page.svelte
	│   └── +page.ts
	└── projects/
        └── +page.svelte

Each +page.svelte defines the page content ‘component’ rendered at the route, as specified by the path. [square-bracket-enclosed] paths denote dynamic routing: slugs. +layout.svelte is practically a template, applying to every child/sibling +page.svelte, for bits like common UI/nav.

This isn’t a Svelte tutorial by any means, but just to satisfy those who might not have heard of it before.

I’m quite the fan, but most general web developers I interact with aren’t familiar with Svelte/SvelteKit, even though it’s been receiving more attention in recent years with usage at Apple, Spotify, ByteDance, etc.

I considered managing a database plus account/authentication for easy and remote upload and edit of archive items, but it’s unnecessary. I’m not sure how often I’ll be updating it, and it’s drastically easier to just ‘hardcode’ them for the exact same practical result. The same applies for using a CMS.

Overcomplicating my site with REST APIs, lambda functions, a database, and managing hosting was a task for previous me from a year or two ago, as (will be, not yet) detailed in another blog post: “Two frontend frameworks, three API layers, and a database walk into a bar”.

For the general aesthetic and nav I wanted something technical and quiet but ‘showy’, something interesting. I find little chunks of info like time, commit hash, route, etc., quite charming, so had to include some of those. Commit hash does mean injecting it during build, but that’s straightforward and becomes trivial with Vercel/Netlify.

This is meant to be a somewhat more-permanent piece, so I tried to do accessibility properly: responsive layouts, keyboard navigability, high-contrast mode, and a check-over with WAVE, among other bits. If you’re curious or have any suggestions to improve accessibility, do reach out.

🛠 ! this post is still under construction ! 🛠