Building This Site with Astro: A Smooth Start

Welcome to the very first post on my new site! If you’re reading this, you’re either curious about Astro, interested in my web development journey, or just stumbled upon this corner of the internet. Either way, I’m glad you’re here.

I’ve spent ~~months~~ years putting off a portfolio rebuild because the modern frontend ecosystem often feels like overkill for a content-driven site. I wanted a platform that’s fast, flexible, and fun to maintain—without sinking hours into configuring build tools or fighting complex hydration steps. After researching current frameworks, I landed on Astro, and the setup was smoother than I could have anticipated.

Here is a quick look at how the quick-start experience went, why Astro’s model fits a modern developer workflow, and what to expect from this devlog moving forward.

Getting Started Was Surprisingly Easy

Setting up a new project usually comes with a fair amount of setup fatigue: configuring linters, setting up CSS post-processors, and adjusting build targets. Astro bypasses almost all of that.

To kick things off with a clean setup and modern utility classes, I initialized the project using the official Tailwind CSS template:

npm create astro@latest -- --template with-tailwindcss

The interactive CLI wizard guides you through basic preferences (like enabling TypeScript and choosing strictness levels). Once the installation completes, starting the local development server takes a single command:

cd my-project
npm run dev

You’re immediately up and running locally at localhost:4321. The Hot Module Replacement (HMR) is instantaneous, making layout tweaks in Tailwind feel like real-time design work rather than a compile-and-wait routine.

Why Astro? (The Short Version)

When selecting a framework for a portfolio, performance and developer experience (DX) are usually at tension. Astro bridges that gap through its islands architecture.

Zero-JavaScript by Default: Astro renders your entire layout to HTML at build time. Unless you explicitly define an interactive component, zero JavaScript ships to the user’s browser.
Framework Agnostic: You aren’t locked into a single ecosystem. If I need a simple React stateful component for a search filter, I can drop it right next to a Svelte or Vue island without needing to wrap the whole app in that framework’s runtime.
Built-in Content Collections: Managing Markdown and MDX files is a native feature. Astro validates frontmatter schemas using Zod out-of-the-box, catching broken links or missing tags during the build step rather than in production.

“Speed is a feature, and Astro delivers it by default by shipping plain HTML until interactivity is explicitly requested.”

What’s Next for This Blog

This site will serve as a living devlog—a space to document what I’m building, the technical challenges I encounter, and practical guides on web development.

Upcoming Topics:

Setting up automated deployments using GitHub Actions and Cloudflare Pages.
Writing strict Zod schemas for Astro Content Collections.
Creating dynamic theme toggles using lightweight vanilla JavaScript islands.

If you have questions or suggestions, feel free to reach out via GitHub or social links in the footer. This initial post is just the baseline—expect deeper code breakdowns, design iterations, and architecture logs very soon.

Thanks for reading! Stay tuned for the next update where I dive into content collection schemas and MDX integration.