Every few months a new JavaScript framework appears and promises to solve all our problems. We have been through enough hype cycles to be skeptical. When we evaluated Astro for the first time in late 2022, we approached it with the same critical eye we give everything.
Then we built three projects with it. We are not going back.
The problem we were solving
Most of the sites we build at Kotito are content-driven: studio portfolios, marketing sites, editorial platforms, documentation hubs. These sites share a common characteristic. They are mostly static, with small pockets of interactivity like a form, a carousel, or a theme toggle.
React-based frameworks ship a full JavaScript runtime to the browser even when the page is 95 percent static HTML. For our use case, that is overhead we cannot justify.
What made Astro different
Astro ships zero JavaScript by default. Every component renders to HTML at build time, and only the components you explicitly mark as interactive get hydrated on the client. This is not a limitation. It is a design philosophy that matches how the web actually works.
The component model is familiar. If you know JSX or any template syntax, you can write Astro components immediately. But unlike React, there is no virtual DOM, no reconciliation, and no hydration cost for static content.
Framework-agnostic islands
The islands architecture lets us use React, Svelte, Vue, or vanilla JavaScript for interactive components while keeping the rest of the page static. On one project, we used a React component for a complex form wizard and Svelte for an animation-heavy feature in the same Astro project, with no conflicts.
This flexibility means we can choose the best tool for each problem instead of committing to a single framework for everything.
Content collections
Astro content collections give us type-safe Markdown and MDX handling with validation at build time. If a blog post is missing a required field, we know before deployment, not after a user reports a broken page.
The schema validation acts as a contract between content authors and developers. We define the shape of the data once, and the system enforces it everywhere.
What we would improve
Astro is not perfect. The ecosystem is smaller than Next.js, so finding third-party integrations can require more research. The dev server can be slow with very large sites. And the documentation, while good, sometimes assumes familiarity with concepts that newcomers might not have.
None of these are dealbreakers. They are the normal trade-offs of choosing a tool that optimizes for a specific use case rather than trying to be everything to everyone.
The verdict
For content-driven sites that need to load fast and rank well, Astro is the best tool we have used. It aligns incentives correctly: the default path produces a fast, accessible site. You have to opt in to complexity rather than fighting to opt out of it.
