RSC für Astro-Entwickler

 (overreacted.io)
2 Punkte von GN⁺ 2025-05-10 | 3 Kommentare | Auf WhatsApp teilen
  • Astro und React Server Components (RSC) setzen die Trennung von Server- und Client-Code auf ähnliche Weise um
  • In Astro übernehmen Astro Components und Client Islands jeweils unterschiedliche funktionale Rollen
  • RSC teilt dasselbe Konzept in Server Components und Client Components auf und legt die Grenze mit der Direktive 'use client' fest
  • Im Vergleich zu Astro bietet RSC mehr Flexibilität beim Aufbau interaktiver UIs und beim Teilen von Code
  • Beide Modelle haben eine Struktur, in der Daten nur in eine Richtung vom Server zum Client fließen

Einführung und Grundkonzepte

  • Astro bietet zwei zentrale Komponententypen: Astro Components und Client Islands
  • Astro Components haben die Erweiterung .astro, werden nur auf dem Server oder zur Build-Zeit ausgeführt und können Aufgaben erledigen, die im Client nicht möglich sind, etwa Dateisystemzugriff, DB-Abfragen oder Aufrufe interner Services
  • Client Islands sind Komponenten für React, Vue usw., laufen im Browser und übernehmen die Teile mit Benutzerinteraktion
  • Innerhalb eines Astro Components kann ein Client Island gerendert werden, aber ein Client Island kann keinen Astro Component aufrufen
  • Diese Struktur garantiert die Unidirektionalität, bei der Daten immer nur vom Server zum Client fließen

Codebeispiel und Rollentrennung

  • Im Beispielcode liest PostPreview.astro auf dem Server eine Datei ein, holt den Titel und übergibt diese Daten an ein Client Island
  • LikeButton ist in React geschrieben und übernimmt nach dem Laden im Browser Statusänderungen sowie Klick-Events der Nutzer
  • Astro Components und Client Islands laufen in verschiedenen Welten, und auch die Datenübergabe erfolgt nur vom Astro Component nach unten

Vergleich mit React Server Components (RSC)

  • Auch in RSC wird ähnlich wie in Astro zwischen Server Components und Client Components unterschieden
  • In React Server Components werden Server Components als JavaScript-Funktionen definiert, und mit der Direktive 'use client' wird klar festgelegt, wo Client-Code beginnt
  • In RSC kann dieselbe Komponenten-Datei sowohl Server- als auch Client-Rollen übernehmen; anders als bei Astro lassen sich Grenzen je nach Bedarf allein durch die Deklaration von 'use client' verschieben, ohne Dateierweiterungen oder separate Trennung
  • Wenn eine Komponente clientseitige Funktionen (z. B. useState) oder serverseitige Funktionen (z. B. DB-Zugriff) verwendet, führt ein Einsatz in der falschen Umgebung zu einem Build-Fehler, was klares Feedback liefert

Visuelle und strukturelle Unterschiede zwischen Astro und RSC

  • Astro hat durch die Trennung von .astro-Dateien und JS/TS-Dateien klare Grenzen
  • Da in RSC grundsätzlich alles React ist, sind Code-Sharing und Flexibilität deutlich besser
  • Zum Beispiel können neutrale Komponenten, die weder State noch Server-Funktionen verwenden (etwa ein Markdown-Parser), auf beiden Seiten eingesetzt werden
  • In RSC wird anhand des Import-Pfads automatisch entschieden, in welcher Welt die jeweilige Komponente läuft

Vorteile und Grenzen des RSC-Modells

  • Der Vorteil von RSC liegt in Code-Wiederverwendung und flexibler Rollenverschiebung
    • Jede Komponente kann je nach Bedarf allein durch die Deklaration von 'use client' die Grenze leicht verschieben
    • In Astro kann die Umwandlung von Code umständlich sein, wenn sich der statische oder dynamische Charakter einer UI ändert; RSC löst das deutlich einfacher
  • Ein Nachteil von RSC ist die höhere Lernkurve
    • Entwickler müssen ständig im Blick behalten, „in welcher Welt“ sie sich gerade befinden, bekommen bei Fehlern aber durch Build-Fehler schnelles Feedback
  • In Astro wird die Struktur komplexer, je mehr dynamische Teile eine UI hat; in RSC ist dagegen der gesamte React-Baum integriert, sodass State- und Context-Weitergabe natürlicher funktioniert

Astro mit HTML-Fokus und RSC mit React-Tree-Fokus

  • Das Ergebnis von Astro ist HTML; bei jedem Seitenwechsel wird alles neu geladen, und es bietet keine vollständig SPA-artige Erfahrung
  • Das Ergebnis von RSC ist ein React Tree (anfangs HTML, bei Navigationen Übertragung als JSON usw.)
    • Dadurch lassen sich die Vorteile von SPA und MPA kombinieren
  • Es ist möglich, teilweise Aktualisierungen direkt vom Server einzuspielen, sodass sich dynamische Daten leicht übernehmen und Client-State erhalten lassen

Unterstützung für fortgeschrittene React-Funktionen

  • Durch die gemischte Server-Client-Tree-Struktur werden fortgeschrittene React-Funktionen (z. B. <Suspense>, View Transitions usw.) natürlich integriert unterstützt
  • Auch deklarativ auf dem Client behandelte Loading-States sowie Verzögerungen bei Fonts, Bildern, JavaScript und Styles lassen sich verwalten
  • Alle React-Funktionen arbeiten End-to-End über die Server-Client-Grenze hinweg

Einordnung von RSC und Astro

  • Astro ist ein vollständiges Framework, während RSC eher ein Building Block oder ein Standard für Frameworks ist
  • Offizielle RSC-Implementierungen gibt es in Next.js App Router und Parcel RSC

Fazit und Empfehlung

  • Die Developer Experience (DX) von RSC ist noch etwas rau, aber es lohnt sich, sie kennenzulernen
  • Wer Astro noch nicht ausprobiert hat, dem ist es zu empfehlen; für Entwickler, denen RSC schwerfällt, bietet Astro einen sanfteren Einstieg
  • Auch für Entwickler, die bisher nur clientseitiges React verwendet haben, kann Astro unerwartete Erfahrungen bei der Problemlösung liefern

Verwandte Beiträge

3 Kommentare

 
hakoiko 2025-05-13

Ich refaktoriere gerade eine alte React-App zu Astro.
Im Text wird der „integrierte Kontext“ hervorgehoben. Man sollte sich bewusst sein, dass ein „integrierter Kontext“ zwar beim schnellen Aufbau eines Services hilft, aber irgendwann zu technischer Schuld werden kann.
Aus Sicht der langfristigen Wartbarkeit eines Services ist eine „lose Kopplung unabhängiger Module“ besser als eine „integrierte enge Kopplung“.
Und Astro ist dafür das flexibelste Framework.
 
GN⁺ 2025-05-10
Hacker-News-Kommentar
  • Der einzige Grund, warum ich RSC statt Astro verwenden würde, ist, dass man Context zwischen Islands teilen kann; ansonsten sehe ich keinen besonderen Vorteil. Und als kleiner Nebenaspekt hätte ich mir gewünscht, dass der Artikel Astos Konzept der "code fence" klarer erwähnt und erklärt. Diese Idee trennt die Grenze zwischen Server und Client deutlich klarer als Reacts use client.
    • Ich glaube nicht, dass die code fence tatsächlich eine echte Grenze markiert. Der Code unterhalb der fence wird ebenfalls zwingend auf dem Server ausgeführt, denn sonst könnte man dort keine Astro-Komponenten referenzieren. So wie ich es verstehe, steht die fence nur für die Unterscheidung zwischen "Binding vs. Template" und nicht für "Server vs. Client".
    • Context zwischen Islands zu teilen ist in Astro wirklich einfach. Siehe dazu diesen Link: https://docs.astro.build/en/recipes/sharing-state-islands/
  • Astro ist ein Web-Framework für inhaltszentrierte Websites, https://github.com/withastro/astro
    • Wer früher Gatsby benutzt hat, wird den Tag nie vergessen, an dem er endlich von der fragilen, über GraphQL verkabelten Bildverarbeitungs-Pipeline weggekommen ist. (Sie waren damals vor dem Computer.) Ich habe keine Belege, aber dass Astos Net Promoter Score fünf Neunen enthält, ist eine wissenschaftliche Tatsache.
    • Astro ist richtig gut. Seit ein paar Jahren ist es meine Standardwahl für SSG, und inzwischen ziehe ich Astro auch ernsthaft für den Bau von Apps in Betracht. Hat jemand Erfahrung damit, Astro für Apps zu verwenden? Ich würde mit Astro nur island-basiertes HTML rendern und das Backend in non-JS umsetzen.
    • "Ein Web-Framework für inhaltszentrierte Websites" — gibt es dann auch Websites, die nicht von Inhalten, sondern von Zufallszahlengeneratoren angetrieben werden?
  • Ich liebe Astro wirklich sehr und nutze es seit dem ersten Release. Sowohl meine persönliche Website als auch die Landingpage meines ersten Produkts habe ich mit Astro gebaut. Die Build-Geschwindigkeit ist hoch, man kann auch ohne JS deployen, und man kann jede beliebige Frontend-Bibliothek verwenden. Deshalb ist es für mich das beste Framework.