Astro-Entwickler in Dresden

#Ein UI-Framework ist eine Entscheidung pro Seite, nicht pro Projekt

Die meisten Astro-Seiten brauchen kein Framework. Eine Produktübersicht, ein Forschungsprojekt mit Publikationsliste oder eine Firmenseite bestehen fast nur aus Text, Bildern und Verlinkung. Interaktiv sind ein Filter, ein Formular, ein Konfigurator. Die Frage lautet deshalb nicht “React oder Vue?”, sondern: Welche drei, vier Stellen auf Ihrer Website müssen im Browser reagieren, und was ist das kleinste Werkzeug dafür?

Dieser Beitrag zeigt, was die offiziellen Astro-Integrationen leisten, wie Sie Frameworks mischen und Zustand zwischen Inseln teilen und wann eine .astro-Datei mit etwas Script reicht. Wie Inseln und Direktiven wie client:visible grundsätzlich funktionieren, steht in Astro-Inseln und Hydrierung. Das wiederhole ich hier nicht.

#Was die offiziellen Integrationen abdecken

Die Astro-Dokumentation führt sechs offizielle Frontend-Integrationen: Alpine.js, Preact, React, SolidJS, Svelte und Vue. Hinzufügen lassen sie sich mit npx astro add react (oder dem jeweiligen Namen). Der Befehl trägt die Integration in astro.config.mjs ein. Fehlt danach ein Peer-Paket, installieren Sie es von Hand nach. Zum Stand 11. November 2026 liefert die npm-Registry diese Versionen:

Astro selbst steht laut npm bei 7.4.11. Die Versionsnummern gelten für den genannten Tag; vor einem Projekt prüfe ich sie neu.

Zwei Sätze aus der Dokumentation bestimmen die Planung. Erstens: Framework-Komponenten werden standardmäßig nur auf dem Server als statisches HTML gerendert. Ohne client:-Direktive kommt kein JavaScript der Komponente im Browser an. Zweitens: Eine Komponente mit Direktive bekommt nur serialisierbare Props. Funktionen als Props an hydrierte Komponenten werden nicht unterstützt.

Außerdem gilt: Sie können keine .astro-Komponente in eine Framework-Komponente importieren. Astro-Inhalt reicht man über <slot /> hinein, und React, Preact und Solid erhalten ihn als children-Prop, Svelte und Vue als Slot.

#Wie ich zwischen den Frameworks entscheide

Technisch unterscheiden sich die Frameworks für die typische Insel weniger als in der Debatte. Ausschlaggebend ist, wer die Insel in zwei Jahren anfasst.

• React oder Preact: Ihr Team kennt React, oder Sie brauchen eine bestehende React-Bibliothek. Preact mit compat: true ist die schlankere Variante, wenn die Bibliothek als ESM vorliegt. Das prüfe ich vor der Zusage an der konkreten Bibliothek.
• Vue: Ihre Entwickler arbeiten bereits mit Vue, etwa in einem Shop oder Portal. Eigene Plugins lassen sich über appEntrypoint einhängen.
• Svelte: Sie starten neu, eine Insel hat wenig Logik und wenig Abhängigkeiten, und das Team lernt gern etwas Neues. Svelte-Stores arbeiten direkt mit Nano Stores zusammen.
• Solid: Sie haben konkrete Gründe für feingranulare Reaktivität und jemanden, der Solid beherrscht. Ohne diese Person fehlt später das Wissen.
• Kein Framework: Die Interaktion besteht aus Aufklappen, Umschalten, Filtern einer vorhandenen Liste. Dann ist jede Framework-Laufzeit Mehrgewicht.

Eine Empfehlung ohne Kenntnis Ihres Teams gebe ich nicht. Hat niemand bei Ihnen Erfahrung, entscheide ich nach dem geringsten Pflegeaufwand und schreibe die Begründung ins Repository.

#Frameworks mischen: erlaubt, selten klug

Astro erlaubt es, in einer .astro-Datei Komponenten mehrerer Frameworks nebeneinander zu verwenden. Nur .astro-Dateien dürfen das, eine einzelne Framework-Komponente kann nicht zugleich React und Vue enthalten. Teilen sich Frameworks die Dateiendung, etwa React, Preact und Solid (alle JSX), braucht jede Integration eine include-Angabe, damit Astro weiß, welche Datei wem gehört:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import preact from '@astrojs/preact';
import react from '@astrojs/react';

export default defineConfig({
  integrations: [
    preact({ include: ['**/preact/*'] }),
    react({ include: ['**/react/*'] }),
  ],
});

Die Dokumentation nennt Ordner pro Framework als gängige Lösung. Wenn mehrere Komponenten desselben Frameworks auf einer Seite stehen, wird dieses Framework nur einmal ausgeliefert.

Wann ich Mischbetrieb zulasse: bei einer Übergangsphase, in der eine alte Vue-Komponente neben neuem Code weiterlaufen muss, oder wenn eine einzelne Bibliothek nur für ein Framework existiert. Als Dauerzustand baue ich es nicht, weil jedes zusätzliche Framework eine zusätzliche Laufzeit, einen zusätzlichen Build-Pfad und eine weitere Fertigkeit im Team bedeutet.

#Zustand zwischen Inseln teilen mit Nano Stores

Zwei Inseln sind zwei getrennt hydrierte Komponentenbäume. Der Kontext-Provider eines Frameworks reicht nicht über beide hinweg. Die Astro-Dokumentation empfiehlt deshalb Nano Stores, eine kleine Bibliothek ohne Abhängigkeiten. Installiert werden nanostores und das Hilfspaket des Frameworks: @nanostores/preact, @nanostores/react, @nanostores/solid oder @nanostores/vue. Svelte braucht nur nanostores.

Ein Store ist ein gewöhnliches Modul. Jede Insel, die es importiert, teilt denselben Zustand, auch über Frameworks hinweg. Das Beispiel der Dokumentation ist ein Warenkorb-Flyout: Ein Atom hält, ob das Flyout offen ist, ein Knopf schreibt mit .set(), das Flyout liest per useStore.

// src/stores/ui.ts
import { atom } from 'nanostores';

export const isPanelOpen = atom(false);

// Preact-Insel: schreibt
import { useStore } from '@nanostores/preact';
import { isPanelOpen } from '../stores/ui';

export default function PanelToggle() {
  const open = useStore(isPanelOpen);
  return <button onClick={() => isPanelOpen.set(!open)}>Filter</button>;
}

<!-- Svelte-Insel: liest denselben Store -->
<script>
  import { isPanelOpen } from '../stores/ui';
</script>

{#if $isPanelOpen}<aside>Filteroptionen</aside>{/if}

Vier Grenzen nennt die Dokumentation, und ich plane sie ein:

1. Nano Stores sind für Reaktivität im Browser gedacht. Im Frontmatter serverseitiger Komponenten sollen sie nicht verwendet werden.
2. Schreibzugriffe aus einer .astro-Datei oder einer nicht hydrierten Komponente erreichen die Werte der Client-Komponenten nicht.
3. Einen Store können Sie nicht als Prop an eine Client-Komponente geben.
4. .astro-Dateien rendern nicht neu und können deshalb keine Store-Änderungen abonnieren.

Bei mehr als zwei, drei Stores frage ich nach, ob die Seite nicht eher eine einzige größere Insel sein sollte. Dann liegt der Zustand im Framework und braucht keinen Store.

#Bundle-Kosten: was ich messe und was ich nicht verspreche

Eine feste Kilobyte-Zahl pro Framework nenne ich nicht. Sie hängt von Version, Bibliotheken und Tree-Shaking ab und gehört in eine Messung am fertigen Build. Belegt sind diese Punkte:

• Ohne Direktive entsteht für die Komponente kein Client-JavaScript.
• Ein Framework wird pro Seite nur einmal ausgeliefert, auch bei mehreren Inseln.
• Nano Stores liegen laut Astro-Dokumentation unter 1 KB.
• Preact mit compat ersetzt Reacts größere Bibliotheken, solange die React-Bibliothek ESM liefert.

Vor Projektstart lege ich fest, was gemessen wird: das JavaScript pro Seitentyp aus dem Build und die Core Web Vitals aus Feld- oder Laborwerten. Als Schwellenwerte gelten die offiziellen von Google: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1 (web.dev). Ob eine Insel diese Werte gefährdet, zeigt erst die Messung an Ihrer Seite.

#Wann .astro mit etwas Script genügt

Ein <script>-Tag in einer .astro-Datei wird laut Dokumentation gebündelt, Importe aus lokalen Dateien und npm-Paketen werden aufgelöst, das Script wird als Modul ausgeliefert, bei mehrfach verwendeter Komponente nur einmal eingebunden, und kleine Scripts fügt Astro direkt ins HTML ein. Skripte mit jedem weiteren Attribut außer src verarbeitet Astro nicht, und is:inline ist nötig, wenn Sie ein Script außerhalb von src/ laden. Daten aus dem Frontmatter erreichen den Browser über data-*-Attribute.

Für mehrere Instanzen derselben Komponente empfiehlt die Dokumentation Custom Elements. this.querySelector() sucht dann nur innerhalb der eigenen Instanz, und connectedCallback() läuft für jedes Element auf der Seite. Ein Aufklapp-Element ohne Framework:

<disclosure-box>
  <button aria-expanded="false">Technische Daten</button>
  <div data-panel hidden><slot /></div>
</disclosure-box>

<script>
  class DisclosureBox extends HTMLElement {
    connectedCallback() {
      const button = this.querySelector('button');
      const panel = this.querySelector('[data-panel]');
      button.addEventListener('click', () => {
        const open = button.getAttribute('aria-expanded') === 'true';
        button.setAttribute('aria-expanded', String(!open));
        panel.hidden = open;
      });
    }
  }
  customElements.define('disclosure-box', DisclosureBox);
</script>

Das ist die richtige Größe für Aufklappen, Tabs, Kopierknöpfe oder einen Filter über eine vorhandene Liste. Bei der Wahl zwischen Direktive und Script gilt: Eine .astro-Komponente lässt sich nicht mit client: hydrieren, der Versuch erzeugt einen Fehler. Interaktion in .astro-Dateien läuft immer über ein <script>.

Formulare gehören in der Regel nicht in eine Insel. Wie Sie sie mit Astro Actions bauen, beschreibt Wuppertal. Seitenübergänge ohne Single-Page-App behandelt Münster.

#Wenn eine Insel Zustand im Browser speichert

Eine Insel, die Auswahl, Sprache oder Vergleichsliste im Browser ablegt (localStorage, sessionStorage), speichert Informationen im Endgerät. Dafür gilt § 25 TDDDG: Die Speicherung oder der Zugriff ist nur nach Einwilligung zulässig. Nach Absatz 2 Nummer 2 braucht es keine Einwilligung, wenn die Speicherung unbedingt erforderlich ist, damit der Anbieter einen vom Nutzer ausdrücklich gewünschten digitalen Dienst bereitstellen kann (§ 25 TDDDG, Gesetzestext bei gesetze-im-internet.de).

Das betrifft nur das Speichern. Ein Nano Store, der nur im Arbeitsspeicher lebt, schreibt nichts ins Endgerät. Ich lege pro Funktion schriftlich fest, ob etwas gespeichert wird und ob die Ausnahme greift. Die Rechtsbewertung bleibt bei Ihrer Datenschutzbeauftragten oder Ihrem Datenschutzbeauftragten. Für Datenschutzfragen in Sachsen ist die Sächsische Datenschutz- und Transparenzbeauftragte die zuständige Anlaufstelle; ihre Seite ist der Ort, an dem Sie aktuelle Hinweise nachlesen.

#Der Dresdner Wissenschaftsstandort und die Frage, was interaktiv sein muss

Nach Angaben der Landeshauptstadt Dresden auf ihrer Seite zu Wissenschaft und Forschung (Seitenstand 26. März 2026) gibt es in der Stadt mehr als 40 Forschungs- und Entwicklungseinrichtungen, über 10.000 Wissenschaftler, 12 Universitäten, Hochschulen und Studienakademien und die größte Anzahl an Fraunhofer-Instituten in Deutschland (dresden.de, Wissenschaft und Forschung).

Für die Framework-Wahl heißt das: Viele Projektseiten, Lehrstuhl- und Institutsauftritte werden von wechselnden Beteiligten gepflegt, Doktoranden kommen und gehen. Je weniger Framework-Wissen eine Seite voraussetzt, desto länger bleibt sie wartbar. Publikationslisten, Teamseiten und Projektbeschreibungen brauchen keine Insel. Eine Datenvisualisierung oder ein Rechner dagegen kann eine rechtfertigen, und dann reicht eine einzige, in dem Framework, das die Beteiligten schon beherrschen.

Foto: Toniklemm, CC BY-SA 4.0, Wikimedia Commons.

#Entscheidungshilfe: Insel, Script oder statisch

#So läuft ein Projekt mit mir ab

Ich bin ein einzelner Entwickler, arbeite aus der Ferne und schriftlich, ohne Termine und Anrufe. Grafikdesign, Mockups und Wireframes bringen Sie mit oder Ihre Agentur, ich setze sie um.

1. Schriftliche Anfrage: Sie schicken mir die URL, Ziel und Termin sowie die Seiten, auf denen etwas interaktiv sein muss.
2. Rückfragen und Einschätzung: Ich frage schriftlich nach und schicke eine Einschätzung zu Umfang und Annahmen.
3. Entscheidung dokumentiert: Framework oder keines, Zustandsteilung, Messpunkte. Die Begründung landet im Repository.
4. Staging und Abnahme: Sie prüfen auf einer passwortgeschützten Vorschau und nehmen schriftlich ab.
5. Wartung als Option: Updates der Integrationen und Frameworks laufen über Staging, mit Backups außerhalb des Hostings und einem schriftlichen Monatsbericht. Ungenutzte Wartungsstunden verfallen am Monatsende.

Von Ihnen brauche ich Zugang zu Repository oder Hosting, das Layout und die Inhalte.

#Häufige Fragen

#Welches UI-Framework ist in Astro die beste Wahl?

Keines ist pauschal die beste Wahl. Ich richte mich nach dem Team: Wenn Ihre Entwickler React kennen, nehme ich React oder Preact, bei Vue-Know-how Vue. Gibt es kein Team, das die Insel später pflegt, wähle ich das kleinste Werkzeug, oft ein Custom Element ohne Framework.

#Kann ich React und Vue auf derselben Seite verwenden?

Ja. Laut Astro-Dokumentation dürfen mehrere Frameworks in einer .astro-Datei stehen, eine einzelne Framework-Komponente darf aber nicht mehrere mischen. Bei mehreren JSX-Frameworks wie React, Preact und Solid braucht jede Integration eine include-Angabe. Ich rate trotzdem zu einem Framework pro Projekt.

#Wie teile ich Zustand zwischen zwei Inseln?

Über ein gemeinsames Store-Modul. Die Astro-Dokumentation empfiehlt Nano Stores, weil Kontext-Provider eines Frameworks nicht über getrennt hydrierte Inseln hinweg funktionieren. Beide Inseln importieren denselben Store und teilen so den Zustand, auch wenn sie in verschiedenen Frameworks geschrieben sind.

#Wann reicht eine .astro-Komponente mit etwas Script?

Wenn die Interaktion aus wenigen DOM-Handgriffen besteht: Aufklappen, Tabs, Filter über vorhandene Listen, ein Kopierknopf. Ein script-Tag oder ein Custom Element liefert das ohne Framework-Laufzeit. Sobald Zustand, Formularlogik und viele Abhängigkeiten zusammenkommen, lohnt sich eine Insel.

#Muss ich auf eine Insel verzichten, wenn ich Zustand im Browser speichern will?

Nein, aber das Speichern von Informationen im Endgerät fällt unter § 25 TDDDG. Eine Einwilligung ist nach Absatz 2 Nummer 2 nicht nötig, wenn die Speicherung unbedingt erforderlich ist, damit ein ausdrücklich gewünschter Dienst funktioniert. Das prüfe ich pro Funktion vorab schriftlich.

#Wie läuft die Zusammenarbeit mit Ihnen ab?

Ich arbeite allein, aus der Ferne und schriftlich. Sie schicken mir Seiten-URL, Ziel und Termin, ich antworte mit Rückfragen und einer schriftlichen Einschätzung zu Umfang und Annahmen. Das Layout kommt von Ihnen oder Ihrer Agentur, ich setze es um. Für die erste schriftliche Einschätzung zu Ihrem Vorhaben berechne ich nichts.

#Schreiben Sie mir zu Ihrer Seite

Schicken Sie mir über das Kontaktformular die URL Ihrer Website, Ihr Ziel, Ihren Termin und den aktuellen Stack, am besten mit den Stellen, an denen etwas interaktiv sein soll. Ich lese alles, frage schriftlich nach und melde mich mit einer ersten Einschätzung. Die kostet nichts. Reicht bei Ihnen reines .astro ohne Framework, schreibe ich das offen.