Introduction
My older personal blog had been sitting untouched for years — the domain had expired, and the topics I’d written about in college hadn’t felt relevant for a long time. It was time to start fresh.
I hadn’t expected to spend much time choosing a framework for a blog site, but I did. I tried Remix first, which I found genuinely interesting, but it wasn’t the right fit for mostly static content. I took a look at Hugo too — it was what my older site was built with — great for purely static sites, but limiting if I felt like needing to do more later. That’s when I tried Astro, and it ended up being exactly what I was looking for.
This post covers my experience with each of those options and what led me to Astro. This is an account of my own experience, not a guide — but I hope there’s something useful in it for you.
The Remix experiment
Remix had been on my radar for a while. I had also tried it out briefly at work to create some sample applications and had liked it. It positions itself as a framework that goes back to basics — receive a request, process it on the server, return HTML. It leans heavily into web standards, using native browser APIs like fetch and FormData instead of custom abstractions. It’s platform agnostic and relies on using a good old CDN for caching and performance, instead of reinventing the wheel (looking at you, Next.js). I liked the philosophy and decided to give it a shot.
The framework does some genuinely clever things. Nested routes can each define their own data requirements, and Remix fetches all of them in parallel before sending a single response to the client. No loading spinners, no sequential data waterfall — the browser gets the final page in one go. For an app with a lot of dynamic data, that’s a great model.
But a blog site is not an app with a lot of dynamic data. I was going to write a blog post once and then very likely never change it. Running a server to process each request, execute JavaScript, and return the same HTML every single time makes no sense. The content is static — it should be generated once at build time and served from a CDN.
There was another problem. To keep things simple, I decided to write the content in markdown and let the framework parse it into the complete HTML. Writing the code to achieve this in Remix required a fair amount of custom work. Parsing, rendering, metadata (tags, date, etc.) extraction from the frontmatter — none of it is built in, and setting it up properly took more effort than I’d expected for what should’ve been a solved problem. Sure, I could’ve had AI write all of that setup — but that’s still custom code sitting in my project that I’d need to understand and maintain every time something changed. If a framework handles it natively, why take on that overhead?
Both problems — running a server to return the same static page on every request, and having to build out content handling from scratch — pointed to the same thing: I was using the wrong tool.
The JavaScript overhead problem
The Remix experiment made me think more carefully about JavaScript overhead in general. It’s not a problem specific to Remix — most React-based frameworks have the same issue at their core.
NextJS would’ve been my default choice going in. It’s the most widely used React framework, supports static site generation, and I’d used it before. But NextJS has gotten complicated. The framework keeps evolving and with each major version it introduces new ways of doing the same things — pages router, app router, server components, multiple layers of caching, each with its own mental model. For a simple blog site, I decided the overhead of keeping up with all of that isn’t worth it.
There’s a broader issue too. Most of the web today ships far more JavaScript than it needs to. You can call me old-school or a purist, but that’s an honest opinion. If it’s not dynamic, it shouldn’t need JavaScript in the browser. Frameworks that rely on client-side rendering send a JS bundle to the browser, which then executes to produce the HTML the user sees. For a blog post that isn’t going to change on the client side, that’s a lot of unnecessary work — and it shows. Pages feel heavier than they should, and the browser is doing work that could’ve been done once at build time.
I wanted something that would generate HTML at build time, ship it with CSS, and let the browser do what it’s good at.
Hugo
I decided to give Hugo a proper try — it was familiar, fast, and genuinely good at what it does: generate a static site from Markdown files with zero fuss. For a site that would never need anything beyond that, it’s hard to beat.
But I wasn’t sure I wanted to commit to that constraint. If I ever needed to pull content from a headless CMS at build time, or drop in a single interactive component somewhere, Hugo would start to resist. The templating language felt dated too — not wrong, just showing its age. I already knew this from my older site. Trying it again only confirmed it.
Enter Astro
Astro, I found, was designed to do exactly that. It’s built around the idea that most websites should ship as little JavaScript as possible, and defaults to generating static HTML at build time. There’s no client-side JS unless you explicitly add it.
The flexibility is what sets it apart from other frameworks. Despite being a static site generator by default, Astro lets you bring in React, Vue, Svelte, or any other framework if you need interactivity somewhere — but only where you need it. You’re not paying for a full client-side runtime everywhere just to get some dropdown to work on one page.
And unlike Remix, which asks you to use @mdx-js/rollup manually for markdown support, Astro has native support for Markdown and MDX. There’s also Content collections which let you define a schema for your content and query it with TypeScript — no custom parsing setup, no manual routing setup, no installing npm packages manually to get it working. Writing a new post is just creating a Markdown file.
The overall model is the right one for me. Build HTML at compile time, serve it statically, add interactivity only where it’s actually needed.
Wrapping up
Astro sits in a good spot for this kind of project. It handles static content well, gets out of the way when you don’t need dynamic behavior, and extends cleanly when you do. It hits a sweet spot that Hugo and Remix each missed for different reasons — and for building a personal site in 2026, that’s exactly what I needed.