The Website & Architecture

Why build it this way?

Unlike the Haskell algorithm visualizer I made, the explicit goal of building this website is to serve as a learning experience for leveraging tools and libraries instead of reinventing them.

I argue that learning to use the existing tools regularly employed in an industry is as important if not more than creating them. As a software engineer it is necessary to understand how to learn new tools as well, as they appear.

Additionally, this site serves as a portfolio to showcase my projects, attempts, lessons learned, and outward thinking in the form of project cards and logs (blog posts).

App Routing

Next.js is my router of choice. It is an app router, contrasting the traditionally used page router. App routers are arguably the future of website building, with a focus on server priority over client-side routing. This means performance and compatability are generally improved over page-routing, where there may be some added complexity, though this comes with added flexibility, too. App routing allows for pages to be routed by the file directory, as follows:

app/
├── layout.tsx
├── page.tsx
├── about/
│   └── page.tsx
├── projects/
│   └── page.tsx
├── logs/
│   ├── page.tsx
│   ├── mdx-components.tsx
│   └── [slug]/
│       └── page.tsx
└── ui/
    ├── dimension-divider.tsx
    ├── drawing-panel.tsx
    └── project-entry.tsx
    ...

Styling

Styling is done with Tailwind v4. If I had used regular CSS, I would be writing seperate CSS files and hand-naming classes such as .card, .hero-section, etc. With Tailwind, pre-made utility classes allow me to apply a specific style to a specific HTML element, all without making a file and naming the specific style.

I can create my own utility classes automatically. Using @theme inline in globals.css, utility classes are made for me using my custom CSS properties. For example:

@theme inline {
    --font-sans: var(--font-inter);
    --font-heading: var(--font-inter);
 
    /* utility classes: bg-blueprint, text-blueprint-line
    border-blueprint-accent */
    --color-blueprint: #16324F;
    --color-blueprint-line: #F1EEE5;
    --color-blueprint-muted: #9FB4C8;
    --color-blueprint-accent: #F5C242;
    --color-blueprint-accent-dark: #D9A62E;
    --color-blueprint-accent-red: #DF534A;
}

Here, I am automatically creating utility classes for fonts and the blueprint themed colours site-wide. Now instead of referring to a specific file and a specific variable that I'd have to name myself, I can simply do the following. This is a snippet of the ProjectEntry component, seen in the projects page.

<div className="border border-blueprint-muted p-4 transition-colors hover:border-blueprint-accent">
  <div className="flex items-center gap-4">
    <span className="text-xs tracking-widest text-blueprint-muted">
      0{index + 1}
    </span>
    <h3 className="font-heading font-bold tracking-wide">
      {project.title.toUpperCase()}
    </h3>
    <span className="ml-auto text-xs tracking-widest text-blueprint-accent">
      {project.tags[0]}
    </span>
  </div>
 
  <a href={project.href} 

Both border-blueprint-muted and text-blueprint-muted come from the same --color-blueprint-muted variable, meaning a single property derived two different utility prefixes for the colour blueprint-muted.

MDX

For information on MDX, the markdown format with support for inline React component rendering, read this blog!

Supabase

This part of the stack is in-progress and not yet build. This blog will be updated to reflect architecture changes.

Vercel

Vercel is the deploy pipeline, which maintains CI/CD. Vercel allows for fast deployment from a GitHub repository and automatically detects new stable builds without setup or complex configuration. It generates a unique URL for working builds to be previewed live for each pull request so that contributors can test changes as they are integrated. Additionally, Vercel are the developers and maintainers of Next.js, and therefore offer optimizations for React and especially Next.js apps such as this very website. Vercel is free for personal projects / non-commercial solutions.

Design and Decisions

First, the site utilises components that can be reused as much as possible. This has multiple benefits, including but not limited to:

1. Website design language remains consistent and repeated with reuse
2. Components are modular, so changing one component affects all related ones positively
3. Props allow for a predictable data flow, in a single direction from child to parent

Next, the use of use client at the head of some files is necessary where placed. By default, Next.js components are server components. This gives all the benefits previously mentioned above. However, in some cases, this is not possible. Namely, when a component requires the use of React hooks and event listeners such as useState or onClick (i.e. input or info from the user), components must be client-side. To manually employ the use client directive, it is written at the top of these respective component files.

Lastly, what is next for the website? Blogs will be uploaded as content/logs/... for the time being in MDX files, but this is soon to change. With a migration to Supabase, files will be accessed from an SQL database (PostgreSQL), moving projects off of a hard-coded array.

If you are interested in my other projects, check them out.