---
title: "designing this website"
date: "18/06/2024"
---

# HTML, JavaScript, and CSS

That's all there is to it.

I thought about using the following frameworks:

1. [React.js](https://react.dev/)
2. [Next.js](https://nextjs.org/)
3. [Hugo](https://gohugo.io/)
4. [Astro](https://astro.build/)

But I did not actually _need_ any of them to make this site look decent.

## what i've learned

Of course, most people build simple websites like these to learn a new technology or framework, not to use an optimal tool. That's actually why I [hosted this website on AWS](/software/from-github-pages-to-aws.html).

Building this website with truly bare-bones technologies has made me appreciate _why_ these web frameworks have emerged.

- Writing JavaScript to manipulate the DOM works just fine but lacks the readability and composability that many JavaScript frameworks bring to the table.
- Re-using code is odd. For example, I created a "common.js" with general utilities—there is zero indication (both to me and my language servers) that these functions are exposed to other scripts included by the same HTML file.
- JSX is great. Dynamically inserting HTML as raw strings or writing them line by line with the DOM is a pain, and a verbose one at that.
- Similarly, CSS styling (inline/stylesheet) works at the small scale. However, with styles being completely divorced from the HTML itself, much is left to be desired.
- Reusing HTML, styles, and JavaScript feels extremely fragile. Innovative type-safe, optimized, and composable solutions definitely have their place in the web.
- **You can be efficient with HTML, JS, and CSS.** My iteration speed on on this site versus other React.js/MDX blogs I have worked on is the same if not faster. While this may be a testament to my lack of JavaScript experience, I think people conclude too early that their task is beyond the technologies that form the foundation of the web today.

## the setup <span class="date">15/06/2024</span>

This website is pure HTML, CSS, and JavaScript.

AWS-wise, I use:

- S3, to host the content (static for now)
- CloudFront, to serve and cache said content
- Route53, to manage routing
- GoDaddy, to reserve [barrettruth.com](https://barrettruth.com)

A user request can be modelled as follows:

1.  A user accesses the website by typing barrettruth.com in their browser.
2.  GoDaddy's DNS servers are queried, which translating the domain name to my Route53's IP address.
3.  Route53 then routes to the request to my CloudFront distribution associated with my S3 bucket.
4.  CloudFront checks its edge caches for the requested content. If the content is stale or not cached, CloudFront fetches the content from S3. Otherwise, it uses the cached content from an edge server.
5.  CloudFront returns the content to the user's browser.

![system design of my portfolio website](/designing-this-website/website-design.webp)

## difficulties

The hardest part of hosting this website was interfacing with GoDaddy.

For example, configuring SSL certificates with GoDaddy is needlessly challenging. Follow [AWS's guide](https://docs.aws.amazon.com/amplify/latest/userguide/to-add-a-custom-domain-managed-by-godaddy.html) if you really want to. Otherwise, [configure your GoDaddy nameservers](https://www.godaddy.com/help/edit-my-domain-nameservers-664) and point them to your own DNS service (like Route53) instead.

# upd: port to astro <span class="date">22/05/2025</span>

I'm expanding my website to include more detailed algorithms, implementations, write-ups, and low-level optimization case studies.

I thought about writing these posts in the raw HTML as I've been doing and physically cringed.

Then I recalled the below post I made around one year ago and realized the following:

- Sure, you can be efficient with raw HTML/CSS/JS. However, _no matter what you do_ snippets, hotkeys, etc, nothing is faster than writing markdown.
- Overhead (i.e. the massive overhead of copying over content, writing the html) matters
- I'll be needing more advanced features that, while possible to do in vanilla web, would just be painful to maintain.
- Sure, frameworks come with bloat. At this point, I'd added web components and script finagling&mdash;I was on the path to reinventing React myself.

Enter [astro](https://astro.build/).

- Lower overhead
- Small bundle size
- SSR opt in/out
- Minimal boilerplate

Everything is now in MDX. I had to say goodbye to my d3 latex labels (I could only do this with MathJax, which I recently found out was overkill for my needs) and a bit of custom styling.

On the upside, I have around the same LOC, a dead-simple blog post setup ([here](https://github.com/barrett-ruth/barrettruth.com/commit/8666e5a16983b177118f6e8a3246feb0d6907fff) was my biggest commit), and the entire Astro community at my back.

The choice of Astro was of no significance. It did the job and that's all that matters. I'm not quite a fan of the funky `---` syntax to separate HTML and JS, though. I find it counterintuitive to separate the UI and the frontend logic, which ought to be tightly coupled. I don't want to imagine working on larger files in Astro.
