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 (opens in a new tab), Nuxt.js (opens in a new tab), SvelteKit (opens in a new tab), or Gatsby (opens in a new tab). 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 (opens in a new tab).
- Nuxt.js → Depends on Vue.js (opens in a new tab).
- SvelteKit → Depends on Svelte (opens in a new tab).
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 (opens in a new tab) and DatoCMS, without yet exploring many of Astro’s features. The result is available at nuestrashojasamarillas.com (opens in a new tab).
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 (opens in a new tab) for layout and Zod (opens in a new tab) 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 (opens in a new tab) to offer my site in two languages: es and en.
- Content Collections (opens in a new tab) to manage blog content efficiently.
Capabilities I value most
- File-based routing (opens in a new tab), which reduces configuration and makes route structure predictable.
- Native integration with Markdown and MDX (opens in a new tab).
.astrocomponents, which are easy to understand and stay close to HTML, CSS, and JavaScript.- Template directives (opens in a new tab) for adding behavior without leaving the component model.
- Support for multiple UI frameworks, including React.js (opens in a new tab), Vue.js (opens in a new tab), Svelte (opens in a new tab), Preact (opens in a new tab), SolidJS (opens in a new tab), and Alpine.js (opens in a new tab).
- Deployment adapters for Cloudflare (opens in a new tab), Netlify (opens in a new tab), Node.js (opens in a new tab), and Vercel (opens in a new tab).
- Internationalization (i18n) (opens in a new tab) support without external packages.
- Content Collections (opens in a new tab) for structured content.
- Local and global styles with
<style>inside components. - View Transitions API (opens in a new tab) integration.
- Component scripts (opens in a new tab) that run on the server and allow backend logic without additional configuration.
- API routes (opens in a new tab) 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.
