Learning Astro - History, Background & Why Astro

#Introduction

Before understanding how Astro works, you need to know where it came from and what problem it is trying to solve. In episode 0 you already created your first project. Now it is time to step back and look at the big picture: how Astro was born, how it evolved, and why it is needed in a landscape crowded with JavaScript frameworks.

Astro's story starts with an irony. Modern frameworks like React, Vue, and Svelte promise a rich user experience, but the result is often pages that ship hundreds of kilobytes of JavaScript just to display an article. Yet the majority of sites on the web do not need complex interactivity — they need content that reaches the user fast.

This episode 1 dissects Astro's history, its position in the Jamstack ecosystem and the generation of meta-frameworks, and the problems it solves with an approach that differs from Gatsby and Next.js.

#History and Evolution of Astro

#The Birth of Astro

Astro was first announced in 2021 by the team behind Snowpack — a build tool that was popular before Vite took over the market. The name Astro was chosen from the spirit of building something fast and light, just as astronomy chases the earliest light. The vision was simple: a framework for content-focused websites that ships less JavaScript to the browser.

#Evolution from Early Versions to Stable Release

The first Astro version was still experimental, used together with Snowpack as the bundler. After Snowpack was discontinued, Astro moved fully to Vite as its build tooling — a decision that is still kept to this day because of its fast dev server.

From there, evolution moved quickly:

• Astro 2 introduced official content collections and mature Markdown/MDX support.
• Astro 3 brought view transitions support and improved build performance.
• Astro 4 cleaned up the content layer API and introduced the stable astro:assets pattern.
• Astro 5 introduced the Content Layer API, legacy fallbacks for migration convenience, and strengthened server-side rendering support.

Each release reaffirms the same thing: content remains the center of attention, and JavaScript is only shipped when truly needed.

#Comparison with Jamstack, Gatsby, and Next.js

#Astro and the Jamstack Movement

Astro stands on the spirit of Jamstack — JavaScript, API, Markup — which popularized the idea of building sites into static files. The difference is that Astro treats framework components as guests, not hosts. You can write pages in pure .astro and tuck React or Svelte components into only the interactive parts.

#Astro vs Gatsby

Gatsby is the pioneer of React-based static site generation. Its strengths are clear, but almost all content must be rendered through React, so JavaScript bundles tend to be large. Astro solves the same problem without forcing the entire page to use a single framework — and its build output is nearly JavaScript-free for static sites.

#Astro vs Next.js

Next.js is the king of full-stack web apps with server-side rendering and many dynamic capabilities. Astro is not trying to beat it in that arena. Astro excels for content-heavy sites: blogs, documentation, marketing pages. When you need full SSR, Astro has adapters and hybrid rendering — episode 21 will cover that. Key comparison:

React SPA → Next.js → Astro hybrid → Astro static → pure HTML

The further right you go, the less JavaScript is sent to the browser.

There is one more difference worth noting: Next.js and Gatsby are React-based frameworks, so the teams using them are tied to the React ecosystem. Astro has no such ties — you are free to write components with any framework, or with no framework at all.

#Problems Astro Solves

#Zero JavaScript by Default and Partial Hydration

Astro's main approach is zero JavaScript by default. At build time, all components are rendered into static HTML. JavaScript frameworks are not shipped to the browser unless you explicitly request hydration. This is what is called partial hydration — only the interactive "islands" are turned on.

#Content-First Architecture and Build-Time Rendering

Astro's architecture treats content as a first-class citizen. Markdown, MDX, JSON, and even external APIs can be read at build time and assembled into static pages. Because most pages are rendered at build time, browser load times are very fast and server costs are low.

#Performance and Multi-Framework

By reducing JavaScript, Astro achieves high performance by default. Combined with multi-framework flexibility — React, Vue, Svelte, Solid, Preact — teams can use the best framework for different parts without rewriting everything. A short representation in an Astro page:

Combining different frameworks

---
import ArtikelSvelte from "../components/Artikel.svelte";
import KomentarReact from "../components/Komentar.tsx";
---
 
<h1>Judul Artikel</h1>
<ArtikelSvelte />
<KomentarReact client:load />

In the code above, client:load on the React component marks that only that part will be hydrated — the rest remains pure HTML.

#Why You Need Astro

#The Right Time to Choose Astro

You need Astro when the main building block of your site is content: frequently updated writing, product documentation, portfolios, and campaign landing pages. You also need Astro when speed is your number one priority and the team wants to avoid the complexity of a JavaScript runtime.

#When It Is Better to Use Another Framework

Conversely, if your application is a real-time dashboard, a state-heavy SaaS app, or an online editor, then a framework like Next.js, React, or SvelteKit is more appropriate. Astro is great, but it is not the answer to every problem — understanding its limits is part of an engineer's skill.

#Conclusion

Episode 1 places Astro on the map of the web development ecosystem: born from the spirit of content-focused sites, evolving alongside Vite from an experimental version to a stable release, and standing in clear comparison with Jamstack, Gatsby, and Next.js.

The key takeaways:

• Astro was born in 2021 to build fast content-focused websites.
• Astro moved from Snowpack to Vite as its build tooling.
• Unlike Gatsby, Astro does not force a single framework for all content.
• Unlike Next.js, Astro focuses on content sites, not full-stack applications.
• Zero JavaScript by default and partial hydration are the main advantages.
• Choose Astro for content sites; choose another framework for real-time applications.

In the next episode 2, we will cover the core concepts and main architecture of Astro — how the compiler works, the build flow with Vite, island architecture, project structure, file-based routing, and integration with other frameworks. This is the foundation that will be used throughout the whole series.