Astro

Was ist Astro?

Astro ist ein content-first Web-Framework, das auf einer einfachen Annahme basiert: Die meisten Seiten benötigen nicht viel JavaScript. Standardmäßig rendert es Seiten als HTML, liefert kein clientseitiges JavaScript aus, sofern dies nicht explizit gewünscht wird, und ermöglicht es, interaktive Komponenten nur dort hinzuzufügen, wo sie wirklich nötig sind.

Dieses Design macht Astro außergewöhnlich gut für die Art von Websites, die einen Großteil des Webs ausmachen: Blogs, Dokumentationen, Marketing-Seiten, Portfolios und inhaltsreiche Produkte. Astro ist nicht gegen JavaScript – es setzt auf Zurückhaltung. Sie erhalten genau die Interaktivität, die Sie benötigen, und nichts darüber hinaus.

.astro Komponenten

Eine Astro-Komponente ist eine Datei mit einem frontmatter-Skript, einem Template und optionalen scoped Styles.

---
// src/components/Card.astro
interface Props {
  title: string;
  href: string;
}

const { title, href } = Astro.props;
---

<a class="card" href={href}>
  <h3>{title}</h3>
  <slot />
</a>

<style>
  .card {
    display: block;
    border-radius: 1rem;
    padding: 1.5rem;
  }
</style>

Das frontmatter wird zur Build-Zeit oder pro Request auf dem Server ausgeführt. Das Template ist HTML mit JSX-ähnlichen Ausdrücken, und <slot /> ermöglicht es einer Parent-Komponente, Children zu übergeben. Styles sind standardmäßig auf die Komponente beschränkt (scoped). Da die Komponente auf dem Server läuft, können Sie Datenbanken abfragen, Dateien lesen und APIs direkt im frontmatter aufrufen.

Dateibasiertes Routing

Dateien in src/pages werden zu Routen, und dynamische Segmente werden durch Klammern gekennzeichnet.

src/pages/
├── index.astro            # /
├── about.astro            # /about
├── blog/
│   ├── index.astro        # /blog
│   └── [slug].astro       # /blog/:slug
└── rss.xml.js             # /rss.xml

Für dynamische Routen exportierst du getStaticPaths, um festzulegen, welche Seiten erstellt werden sollen, oder du nutzt SSR, um diese bei Bedarf zu rendern.

Content Collections

Content Collections sind die Antwort von Astro auf strukturierten Content. Du definierst ein Schema, und jeder Markdown- oder JSON-Eintrag wird zur Build-Zeit validiert.

// src/content.config.ts
import { defineCollection, z } from "astro:content";

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    publishedAt: z.coerce.date(),
    tags: z.array(z.string()).default([]),
  }),
});

export const collections = { blog };

---
// src/pages/blog/index.astro
import { getCollection } from "astro:content";

const posts = (await getCollection("blog"))
  .sort((a, b) => b.data.publishedAt.valueOf() - a.data.publishedAt.valueOf());
---

<ul>
  {posts.map((post) => (
    <li>
      <a href={`/blog/${post.id}`}>{post.data.title}</a>
    </li>
  ))}
</ul>

Dadurch erhältst du Typsicherheit, Validierung und eine saubere Möglichkeit, Inhalte ohne Datenbank abzufragen. Für eine Website mit hunderten von Posts oder Dokumentationsseiten ist dies eine erhebliche Verbesserung der Developer Experience.

Die Islands-Architektur

Dies ist das definierende Feature von Astro. Eine Seite besteht aus statischem HTML, und alle interaktiven Komponenten sind Islands, die unabhängig voneinander hydriert werden. Über eine Client-Direktive steuern Sie, wann jede Island geladen wird.

---
import Counter from "../components/Counter.jsx";
import Comments from "../components/Comments.jsx";
---

<Counter client:load />
<Comments client:visible />

Die Direktiven sind:

• client:load hydriert sofort — für kritische Interaktivität im sichtbaren Bereich (above-the-fold).
• client:idle hydriert, sobald der Browser frei ist.
• client:visible hydriert, wenn die Komponente in den Sichtbereich gescrollt wird.
• client:only überspringt das Server-Rendering und rendert nur im Browser.
• client:media hydriert, wenn eine Media-Query zutrifft.

Die Wahl der am wenigsten „eifrigen“ Direktive, die dennoch funktioniert, hält die Seite schnell. Die meisten Content-Seiten benötigen gar keine Direktiven.

Nutze deine eigene UI-Library

Astro kann Komponenten von React, Vue, Svelte, Solid und Preact rendern — und das im selben Projekt.

---
import ReactChart from "../components/Chart.jsx";
import VueForm from "../components/Form.vue";
---

<ReactChart client:load data={data} />
<VueForm client:visible />

Jedes Framework ist eine optionale Integration. Du kannst React für eine Island und Svelte für eine andere verwenden oder Frameworks komplett weglassen. Diese Flexibilität bedeutet, dass du niemals an eine Technologie gebunden bist und eine Library nur dort einsetzt, wo sie wirklich einen Mehrwert bietet.

SSR und Adapter

Astro ist standardmäßig statisch, kann aber auch On-Demand rendern. Füge einen Adapter für deine Plattform hinzu und aktiviere das Server-Rendering für deine Routen.

// astro.config.mjs
import { defineConfig } from "astro/config";
import node from "@astrojs/node";

export default defineConfig({
  output: "server",
  adapter: node({ mode: "standalone" }),
});

API-Endpunkte befinden sich in src/pages/api und exportieren HTTP-Methoden, während Server Islands es ermöglichen, dynamische Fragmente innerhalb ansonsten statischer Seiten zu rendern. Das macht Astro ideal für hybride Seiten: ein statischer Blog mit einem dynamischen Dashboard oder eine Marketing-Seite mit personalisierten Bereichen.

Best Practices

• Setze standardmäßig auf .astro Komponenten; füge Framework-Komponenten nur für Interaktivität hinzu.
• Verwende die am wenigsten aggressive Client-Directive, die funktioniert.
• Speichere Inhalte in Collections mit einem Schema anstatt in Free-Form-Markdown.
• Scope Styles mit Komponenten-<style>-Blöcken oder einem gewählten CSS-Tool.
• Rendere statische Seiten zur Build-Zeit und reserviere SSR für dynamische Routen.
• Nutze Layouts für gemeinsame Shells und Metadaten.
• Optimiere Bilder mit den integrierten Image-Komponenten.

Häufige Fehler

• client:load überall einzusetzen und damit den Vorteil von “Zero-JavaScript” zu verlieren.
• Zu einem UI-Framework zu greifen, wenn eine .astro-Komponente ausreichen würde.
• Zu vergessen, ein Schema zu definieren, wodurch die Typsicherheit in Collections verloren geht.
• Davon auszugehen, dass Astro keine dynamischen Apps erstellen kann, und SSR zu übersehen.
• Zu viele UI-Frameworks zu mischen und das Projekt ohne Grund aufzublähen.
• Client-seitiges Fetching für Inhalte zu verwenden, die bereits zur Build-Zeit gerendert werden könnten.

Wie geht es weiter?

Astro ist die pragmatische Wahl für inhaltsreiche Websites, die dennoch punktuelle Interaktivität benötigen. Vertiefen Sie Ihre Kenntnisse in HTML und CSS und vergleichen Sie anschließend das Modell mit Next.js, Nuxt und SvelteKit. Bauen Sie danach einen kleinen Blog mit einer Content Collection und einer interaktiven Island, um die Vor- und Nachteile selbst zu erleben.