I Finally Understand What Static Sites Are

Building openflomo with Client-Side Rendering

Back when I first started tinkering with AI coding, I wanted to build a public version of my notes from flomo (a note-taking app). With Claude driving the code, here’s how the workflow played out:

1. Downloading the raw notes: flomo exports in HTML

If all I cared about was making my notes public, simply hosting this export as a static page would have been more than enough. But I couldn’t leave well enough alone—I just had to go and rebuild it to match flomo’s actual web app.

2. Fussing over the details

The raw export was missing two key things: first, tags inside note cards couldn’t be highlighted or filtered; second, it lacked the tag list in the left sidebar.

After plenty of tinkering, here’s what it looked like. I was thrilled, and immediately threw it up on GitHub Pages.

3. The problem: painfully slow loading

I have over 2,000 notes. The raw HTML file was around 700 KB, and both the JS and CSS files clocked in at over 600 lines each. Whenever you opened the page, this is what actually happened:

1. The browser loaded index.html, which pulled in the raw data file and the JavaScript, while importing CSS as needed.
2. The JavaScript looped through the entire raw file on the fly—handling tag parsing, text formatting, the list view, URL formatting, and so on.
3. The CSS was applied, and rendering finally finished.

Since I don’t know how to code, I just obsessively took screenshots of the LCP (Largest Contentful Paint) performance scores, tossed them over to Claude, and told it to fix them. We tried plenty of tricks and saw some improvements, but my gut kept telling me something about this whole setup felt off.

Discovering Hacker News and Buzz

I had just started browsing Hacker News at the time, and I couldn’t understand why its interface looked so dated. After digging around a bit, I realized what its users actually care about:

• Only the bare-minimum HTML and CSS, and virtually no JavaScript, so it still works even on terrible connections.
• High information density.
• Zero visual clutter from bloated CSS, making it easy to stay immersed in the content.

Then I came across Owen’s article on rebuilding Buzz (https://www.owenyoung.com/blog/new-buzzing). That was when it clicked: for what I was trying to do with openflomo, I should be server-side rendering and building a static site, then hosting those static files on GitHub Pages.

Client-Side vs. Server-Side Rendering

At its simplest, a web page can just be a single HTML file: CSS provides styling, and JavaScript adds logic. Without any JavaScript, it’s already a complete page on its own.

More often, though, there’s an intermediate step between your raw data and the final page structure. Take a blog: I write posts in Markdown, and a set of scripts has to convert that Markdown into HTML before it can actually become a web page.

That process is the “Build” step.

When hosting a site, there are three common moments when this build can happen:

1. Building locally, then deploying the compiled files.
2. Building on the server when deploying the source files—compiling once on the server, so visitors receive pre-compiled files directly.
3. The client fetches all the raw assets and compiles everything on the fly—which inevitably leads to slow load and render times.

Rebuilding with Astro

With Cursor doing the coding, I rebuilt the project using Astro. The new workflow looks like this:

1. Drop in the updated flomo notes.
2. Commit and push the code. The build script runs on the server—handling tags, lists, and styling to produce the final static assets.
3. When a visitor lands on the page, they pull down the pre-built static site directly.

Looking at these network requests in DevTools, for the first time I felt that same excitement my former engineer colleagues must feel when they write clean, elegant code.