From the moment I first encountered Astro, its proposal caught my attention. Its name and logo were memorable, but I knew that was not enough to judge a technology. What mattered was seeing how it performed in a real project.
Why Astro
Astro came to fill a gap in the vast world of JavaScript frameworks. When considering which technology to use for creating a static application with a modern development experience, the first options that come to mind are Next.js, Nuxt.js, SvelteKit, or Gatsby. However, all of these options rely on sending JavaScript to the client, even when dealing with a static website. This is because they work as metaframeworks built on top of other technologies:
- Next.js and Gatsby → Depend on React.js.
- Nuxt.js → Depends on Vue.js.
- SvelteKit → Depends on Svelte.
What sets Astro apart
This is where Astro stands out: its rendering is based on HTML, CSS, and pure JavaScript, without the need for an additional framework. Additionally, its Islands Architecture allows for the intelligent integration of other frameworks like React, Vue, Svelte, Preact, SolidJS, or Alpine.js, making it easy to add interactivity without compromising performance.
My first experiments with Astro
Since its release, I wanted to try it, but time was not on my side. My first attempt was to migrate my girlfriend's blog from Next.js to Astro. In that first test, I kept the same UI with TailwindCSS and DatoCMS, without yet exploring many of Astro’s features. The result is available at nuestrashojasamarillas.com.
It wasn’t until I had more free time (due to an unexpected twist in my work life) that I decided to fully dive into Astro and develop my own website from scratch. As a developer, I couldn’t resist the temptation to rebuild my portfolio with the latest technology that excited me. This time, I wanted to take advantage of all of Astro's capabilities.
Challenges and learnings
One of the most interesting challenges was developing everything with HTML, CSS, and pure JavaScript, without UI libraries or predefined components. I used TailwindCSS for layout and Zod for form validation, but nothing else. It felt like the old days, when building from scratch was the norm, and every line of code had a clear purpose.
Key features I explored
- Internationalization (i18n) routing to offer my site in two languages: es and en.
- Content Collections to manage blog content efficiently.
Capabilities I value most
- File-based routing, which reduces configuration and makes route structure predictable.
- Native integration with Markdown and MDX.
.astrocomponents, which are easy to understand and stay close to HTML, CSS, and JavaScript.- Template directives for adding behavior without leaving the component model.
- Support for multiple UI frameworks, including React.js, Vue.js, Svelte, Preact, SolidJS, and Alpine.js.
- Deployment adapters for Cloudflare, Netlify, Node.js, and Vercel.
- Internationalization (i18n) support without external packages.
- Content Collections for structured content.
- Local and global styles with
<style>inside components. - View Transitions API integration.
- Component scripts that run on the server and allow backend logic without additional configuration.
- API routes to extend an application without necessarily depending on an external backend.
Final assessment
Astro has been one of the most impressive technologies I have used in recent years. It offers strong performance and a flexible development experience. For content sites and experiences with localized interactivity, I believe it is worth evaluating.
It is not a universal answer for every product, but it is a solid option when the goal is to deliver HTML quickly and reserve JavaScript for the parts that genuinely need it.
What I would learn next
Reading this article again, my enthusiasm remains, but I would now frame the recommendation more precisely. Astro is not fast because its logo represents “zero JavaScript.” It is fast when the team keeps HTML as the default, optimizes images, and adds hydration intentionally. It can still become heavy when every section turns into an island loaded immediately.
Content Collections became one of the features I value most. Validating titles, dates, languages, and images during the build prevents real editorial errors. On this blog, that validation enforces Spanish-English parity and predictable static routes.
I also learned that a strong technical experience depends on less exciting details: correct canonicals, hreflang, visible dates, authorship, internal links, and an updated sitemap. The framework makes HTML generation straightforward, but it does not decide that metadata for you.
My updated criteria are simple:
- For content with localized interaction, Astro remains my first evaluation.
- For an application dominated by shared state, I compare application-centered frameworks first.
- For a hybrid site, I build one representative page and measure JavaScript and operational cost.
That position is less absolute than my initial impression, but more useful. It preserves what Astro does particularly well without treating it as an answer for every product.
Limits I would not ignore
The freedom to mix frameworks can increase dependencies and review criteria when it is used without a migration or integration reason. I would also watch platform adapters, differences between static and server rendering, and any experimental feature that starts supporting a critical journey.
Astro reduces client complexity, but the project still needs a strategy for caching, data, deployment, and observability. Choosing it solves an important part of web architecture; it does not replace the remaining decisions.
This experience was the starting point. If you are evaluating Astro for a new project, build one representative page, measure how much JavaScript reaches the browser, and identify which areas genuinely need interaction.
The decision also depends on the product. In perfect code vs correct decisions, I explain why context matters more than choosing the most technically attractive tool.
