astro & away we go!

Astro is a frontend framework that’s geared towards “content-driven sites,” which is a broad niche currently dominated by tools like WordPress. Astro is gaining traction among major companies like Ikea and Porsche, but one use case where Astro already seems dominant is as a platform for building developer blogs. Astro’s builders know this: the “getting started” tutorial in the Astro docs walks you through building a blog from scratch.

So what makes Astro so perfect for technical blogging? Why am I using Astro, and why do I feel the need to write about that choice? Because Astro is easily the best fit for this niche. Trying to build a blog on a different, “full-stack” framework like Next.js or SvelteKit requires enough struggling against your tooling that you risk losing momentum, while using a pure CMS like WordPress denies you the ability to customize the frontend and include your own interactive features.

background: why write a “dev blog”?

We all know that developer blogs mostly exist to train the next generation of large language models, regardless of our intentions as human authors. Cynicism aside, writing is a muscle, and since writing on technical subjects comes easily to me I’ve found that it’s a good place to start. I habitually take extensive notes while researching subjects; writing for “an audience” is a good way to force myself to distill the most important ideas and present them in a way that’s accessible to others.

In general, developer blogging is a popular medium because it allows you to hone and flex both your technical and communication skills. Being able to get a site up and running on your own domain is a litmus test of basic web development skills. Blog templates often become popular open source projects in their own right, and personalizing your template is a great way to show off the shiny JS and CSS snippets you’ve discovered.

template vs. content focused blogs

Developer blogs exist on a spectrum from “template-focused” to “content-focused.” A “template-focused” blog is primarily focused on showing off frontend skills and will include features like an interactive console-simulating navigation system, “edgy” minimalist design, or extensive animations. The content is just there to be decorated.

With this site, I’m trying to create something that’s more “content-focused.” I do care about presenting my work elegantly, but I’m not trying to show off my frontend skills because they’re not my primary skill-set¹. Yes, I can build a website on top of a modern frontend framework, and I recognize the importance of understanding how frontend frameworks work, but once I have the infrastructure in place I want to focus on the content. I like Astro because it gets out of the way.

Astro has the best Svelte + Markdown support

I love Svelte.js. I like the way that the component syntax closely resembles the way you’d author HTML, JS, and CSS without a framework. Integrating vanilla JS libraries is fairly straightforward, and the rendering performance for custom components and data visualizations is unmatched. The relative lack of off-the-shelf packages can be frustrating, but AI code generation does a good job of filling in the gaps.

SvelteKit, Svelte’s default meta-framework, is a piss-poor blogging platform. It’s great for building interactive applications and rendering dynamic content, which is the way I’ve used it on projects like the baby name site I’ve been working on. Building a blog with SvelteKit is possible, and I’ve added a blog to an existing SvelteKit project. But I wouldn’t start using SvelteKit just to build a blog— if you want to gain experience with SvelteKit, build some type of application instead. Custom interactive data visualizations are particularly well-suited.

Astro has first-class support for Svelte components, which you can use either as non-interactive formatting widgets or as “hydrated” components with client-side interactivity. Even more relevant for a blogging platform, Astro supports MDX out of the box, and lets you use components from any supported framework integration inside MDX files.

why is Astro better than MdSvex?

MDsveX is a Markdown pre-processor for Svelte that attempts to bring an MDX-like authoring experience to the Svelte ecosystem. As a preprocessor, MDsveX compiles your markdown documents into Svelte components by hooking into the Svelte compiler and transforming markdown into HTML elements. The main reason to use MDSveX is that it allows you to use Svelte components in your markdown files, but as a preprocessor it’s also a good fit if you want to author chunks of text for pages like an “About” or “Terms of Use” in markdown.

As we’ll cover in the next section, Astro’s main strength is its “islands architecture”. That matters here because you can use JavaScript libraries to create content on an Astro page without having to ship that JavaScript to the client’s browser. This is really convenient for static content like code blocks, which you can render inside a component in Astro without having to bloat the client-side page with the code to parse and highlight the code block.

Keeping bundle size to a minimum is trickier with MDsveX— every Svelte component gets shipped to the browser in its entirety, so only transformations that can be handled by a preprocessor avoid shipping code to the client. There are preprocessors for common code formatting extensions like Shiki, but building anything more requires a deep dive into preprocessor internals.

MDsveX is a valiant effort, but it’s extremely frustrating to use at times. For starters, the project predates SvelteKit, so the documentation doesn’t include any examples of integrating MDsveX with a contemporary project— the best example out there is Josh Collinsworth’s blog starter project. Since MDsveX aims to be compatible with Svelte independent of SvelteKit, it can be confusing to integrate it with other Svelte preprocessors and vite plugins. And since the project relies on an outdated version of the core syntax parsing library unified, plugin compatibility is a poorly-documented crapshoot.

SPA vs SSG vs Islands

Back to the main thrust of this article: building a blog with Astro feels much more natural than using a full-stack web application framework like Next.js, or even my beloved SvelteKit. Why? Hydration.

As single-page application frameworks¹, both Next.js and SvelteKit depart from the assumption that it needs to be possible to render a site entirely in the client’s browser. Server-Side Rendering (SSR), which generates the HTML for the first page a user loads on the server, is optional for SPA frameworks; SSR theoretically reduces load times and improves SEO.

Every subsequent request, however, is rendered in the user’s browser by JavaScript code, so all of the JavaScript code that creates a page must be shipped to the client’s browser. Although React has introduced “server components” which relax this constraint, it’s still common to ship all of the JavaScript code that creates a page to the client’s browser when using an SPA framework.

This “ship it all” approach makes sense when you’re rendering an interactive application, because you might end up re-drawing parts of a page that change in response to incoming data or user interactions. But for a site where the content doesn’t change, like a blog, it can be very inefficient. Take, for example, a syntax-highlighted code block. If I were to use an SPA framework to build this blog, I would need to send all of the JavaScript necessary to parse the code block into syntactical elements to the client’s browser even though the code block doesn’t change.

It makes much more sense to generate static content once, on the server, and send the resulting HTML to the client’s browser, which is exactly what traditional static site generators (SSG) like Hugo or Jekyll do. SSG tools transform your source content into plain HTML, CSS, and JS script assets at build time². The main drawback of a static site generator is that you typically have to implement client-side interactivity using vanilla JavaScript, which can be tedious compared to a component-based framework like React, Svelte, or Vue.

Which brings us to Astro’s main advantage: its Islands Architecture.

islands of adventure

Astro’s main value proposition is its Islands Architecture, which in a nutshell just means that you can opt-in to “hydrating” certain parts of your page. Since Astro lets you use any mainstream frontend framework to create components, you can, for instance, build an interactive data visualization in Svelte and ship only the JavaScript code needed for that visualization component (like tooltips, zooming, and animations) to the client’s browser³.

Astro does a better and more comprehensive job of explaining the concept of the Islands Architecture than I’m trying to do here— so here’s a link to the official Astro docs introducing the concept. The upshot is that Astro’s Islands Architecture allows you to choose which parts of a page become interactive, which is more efficient than the way that Single Page Applications approach the problem.

conclusions

When I started diving into web development, I found the alphabet soup of rendering modes overwhelming. I defaulted to React with Next.js because they’re popular, struggling to wrap my head around the then-new React Server Components. I ultimately found that Svelte was a better overall platform for interactive data visualizations for performance reasons. Yet SvelteKit is really designed more for applications than for blogs. Hence turning to Astro— the best of both worlds. Now all I need to do is write more often.