Why I Chose Astro for Modern Websites

Building websites became more complicated than building websites.

Somewhere along the way, we started treating every website like it needed to be a web application. More JavaScript, more tooling, more dependencies, and more moving parts became the default. I found myself spending more time managing complexity than building websites.

Start with the problem, not the framework.

Most of the projects I build have surprisingly similar goals. They need to communicate clearly, load quickly, rank well in search engines, and be easy to update years after they're launched. Those requirements don't point me toward the most feature-rich framework—they point me toward the simplest architecture that gets the job done. A website should earn its complexity. It shouldn't inherit it.

Astro matched the way I was already thinking.

Astro starts with HTML and only introduces JavaScript when a page actually benefits from it. That isn't just a rendering strategy; it's a philosophy that aligns with how I approach engineering. Build the simplest solution first, then add complexity only when it creates real value.

Every tool has a responsibility.

I don't expect one framework to solve every problem. I prefer a stack where each tool has a clear job instead of overlapping with everything else.

- Astro → Website architecture and rendering

- React → Interactive experiences

- Sanity → Content management

- TypeScript → Safer, maintainable code

- Cloudflare → Deployment and edge infrastructure

When every tool has a defined responsibility, the system becomes easier to understand, maintain, and extend.

The framework isn't the decision.

If Astro disappeared tomorrow, I'd still build websites the same way because the principles came first. Fast by default, simple by design, and only as complex as the project needs to be. Astro just happens to be the framework that best supports those ideas today.