Was Astro ist, sein technischer Ansatz und wie es funktioniert

Bis vor Kurzem war es bei mir – wie bei fast allen – üblich, für eine Unternehmenswebsite auf WordPress zurückzugreifen. Aus offensichtlichen Gründen: Es ist einfach, fast alles, was du brauchst, ist bereits entwickelt, und nach vielen Jahren ist mein Workflow sehr schnell.

Aber bei meinem letzten Projekt, der Website von Rondabus, habe ich Astro verwendet. 

Der Grund?

Es wurde in einem KI-Newsletter empfohlen, den ich lese, weil es sich angeblich sehr gut mit Agenten integrieren lässt.

Und das tut es wirklich.

Ich habe das Projekt vor allem als Test des aktuellen Stands der Webentwicklung betrachtet. Um zu sehen, wie viel noch von einem Menschen abhängt und wie viel die KI bereits übernehmen kann. Deshalb habe ich das empfohlene Framework verwendet.

Natürlich habe ich mich eingelesen, um zu verstehen, ob es für das geeignet war, was ich vorhatte. Aus dieser Recherche ist dieser Artikel entstanden, in dem ich dir erkläre, was du wissen musst, um dich an Astro heranzuwagen. Und noch etwas mehr.

Aber bevor wir zur Sache kommen, zwei Kleinigkeiten:

Erstens war ich von seinem HTML first-Ansatz begeistert. Genau das predige ich seit Jahren.

Zweitens gilt heute beim Entwickeln einer Website: Abgesehen vom Urteilsvermögen liefern ChatGPT oder Claude alles andere..

Jetzt geht’s los.

Was Astro genau ist

Astro ist ein Framework zum Erstellen von Websites, also eine Sammlung von Werkzeugen und Richtlinien, die dir hilft, den Code deiner Website zu erzeugen.

Nicht mehr und nicht weniger.

Es gibt viele Frameworks, jedes mit seinen Eigenheiten. Hier erkläre ich dir die von Astro.

Astro ermöglicht es, mit wiederverwendbaren Bausteinen, gemeinsam genutzten Daten und Templates zu arbeiten. Anschließend kombiniert es alles, um die Website zu erzeugen.

Stell dir also vor, was du für die Website eines Unternehmens brauchst: Header, Menü, Serviceseiten, Fotos, Texte, Formular und Footer. Du könntest jede Seite von Hand in HTML schreiben, würdest aber viel Arbeit wiederholen.

Wenn du die Telefonnummer änderst, einen Menüpunkt oder einen Link im Footer hinzufügst, müsstest du das in allen Dateien der Website anpassen. Mit Astro nicht, denn es verwendet Elemente wieder.

Und du wirst sagen: wie bei WordPress. Ja, stimmt, aber hier steckt keine Datenbank dahinter.

Du könntest auch antworten: wie bei jeder serverseitigen Sprache wie PHP. Darauf würde ich sagen, dass auf dem Server keine Sprache installiert sein muss – dort müssen nur die Dateien liegen.

Wie ursprünglich: eine HTML-Datei pro URL samt zugehörigem CSS und JS.

Du kannst tatsächlich HTML, CSS und JavaScript oder TypeScript verwenden, aber bei Bedarf auch React-, Vue- oder Svelte-Komponenten einbinden, was ich nicht mache.

Und wie bekommt man wiederverwendbare Elemente und viele HTML-Dateien hin?

Der grundlegende Unterschied: die Website erzeugen, bevor der Nutzer kommt

Um Astro zu verstehen, sollte man die zwei Zeitpunkte einer Website unterscheiden:

1. Wann sie entwickelt wird.
2. Wann sie jemand besucht.

Bei einer traditionellen dynamischen Website bereitet der Server die Seite vor, wenn er eine Anfrage erhält. Er führt Code aus, holt die nötigen Daten, setzt sie in ein Template ein und liefert das Ergebnis an den Browser zurück.

WordPress funktioniert zum Beispiel so: PHP führt die Anwendung aus, fragt die Datenbank ab und nutzt Theme und Plugins, um die Seite zu erzeugen. Ja, der Cache kann eine Antwort speichern und wiederverwenden, sodass nicht bei jedem Besuch der gesamte Prozess wiederholt werden muss. Wichtig ist zu verstehen, dass eine Anwendung existiert, die die Antwort erzeugen kann, während die Website läuft.

Mit Astro hingegen kannst du diese Arbeit vor der Veröffentlichung erledigen. Du bereitest die Seiten vor, erzeugst die Dateien und legst das Ergebnis auf dem Hosting ab. Das nennt man einen Build..

Wenn dann jemand die Kontaktseite aufruft, liefert der Server bereits fertiges HTML aus. Er muss für diesen Besucher nicht den Header neu aufbauen, die Telefonnummer abrufen und den Footer zusammensetzen.

Diese Arbeitsweise nennt man SSG oder Static Site Generation. Sie hat mehrere Vorteile, zum Beispiel, dass solche Seiten buchstäblich fliegen..

Es gibt noch mehr, die ich im Artikel erkläre.

Was ich dir bisher erzählt habe, reicht aus, um dir eine Vorstellung davon zu machen, worüber wir sprechen, wenn du kein Techniker bist. Wenn doch, gehen wir ab jetzt tiefer in die Arbeitsweise des Frameworks.

Starker Kaffee für Kaffeefans. Du bist gewarnt.

Reden wir über Builds

Zuerst musst du verstehen, dass ein Build nichts anderes als das Ergebnis eines automatisierten Prozesses ist, der alle von dir geschriebenen Dateien (Code, Bilder, Styles) nimmt und sie in ein Paket verwandelt, das Server oder Webbrowser ausführen können..

Und das war’s.

Du hast also eine Reihe von Codedateien, die unterschiedliche Dinge tun. Wenn du den Befehl zum Kompilieren des Builds ausführst, erkennt Astro die Seiten, holt die Inhalte, führt die Templates aus und bereitet die Ressourcen vor, um dir schließlich eine vollständige statische Website mit HTML, CSS und JS (falls nötig) zurückzugeben..

Du kannst zum Beispiel ein gemeinsames Template und acht Service-Einträge haben. Der Build kombiniert das Template mit den Daten jedes Eintrags und erzeugt die entsprechenden Seiten.

In Astro geschieht das mit dem Befehl npm run build , der normalerweise astro build. ausführt. Die Website, die zum Hochladen bereit ist, liegt in dem Ordner dist und kann auf den Server hochgeladen werden, auf den deine Domain zeigt.

Wie eine Seite in Astro aufgebaut wird

Wenn du das nicht gewohnt bist, klingt das Vokabular komplizierter, als es ist. Schauen wir es uns an einer kleinen Unternehmenswebsite an.

Wie eine .astro-Datei aussieht

Eine .astro-Datei kann einen Codebereich mit einem HTML-ähnlichen Template kombinieren:

—

const titulo = 'Transporte para tu empresa';

—

<h1>{titulo}</h1>

<p>Organizamos los desplazamientos de tu equipo.</p>

Was zwischen den beiden Gruppen von Bindestrichen steht, bereitet die Daten vor. Darunter befindet sich das Template, das sie verwendet. Die geschweiften Klammern zeigen, wo ein Wert eingesetzt wird.

Dieser Code wird beim Erstellen der Website ausgeführt, und der Browser erhält eine normale Überschrift mit Text sowie einen normalen Absatz mit dem Inhalt der Variablen titulo.

Komponenten

Die Elemente, die wiederverwendet werden.. 

Zum Beispiel kann der Header eine Komponente sein. Der Footer eine andere. Ein Template für das Hero-Banner der Serviceseiten eine weitere. Du speicherst sie separat und verwendest sie auf den Seiten, die sie benötigen.

Zum Beispiel kann eine Seite Header.astro und Footer.astro importieren und <Header /> am Anfang und <Footer /> am Ende platzieren. Astro wandelt diese Bausteine in das entsprechende HTML-Markup um.

Props

Die Props sind die Daten, die du einer Komponente übergibst, damit sie mit unterschiedlichen Inhalten wiederverwendet werden kann..

Wenn du eine Komponente für das Hero-Banner-Modul der Serviceseiten erstellt hast, kannst du ihr einen Titel, eine Beschreibung und ein Bild übergeben. Die Struktur behält ihr Design, während sich die Werte ändern. So kann das Hero-Modul für Service 1 anders sein als das für Service 2, mit anderem Inhalt, aber demselben Design.

In Astro kann die Komponente diese Werte so auslesen: Astro.props. 

Layouts und Slots

Ein Layout ist eine von mehreren Seiten gemeinsam genutzte Struktur. Sagen wir, es ist wie eine Komponente eine Nummer größer: : Eine Komponente ist normalerweise ein kleiner Teil der Seite, während das Layout praktisch die gesamte Seite umfasst..

Es kann das HTML-Dokument, Metadaten, Header und Footer enthalten.

Der Slot ist der Platz, an dem der eigene Inhalt jeder Seite eingefügt wird. 

Wenn du von WordPress kommst, wird dich das an Templates erinnern, die Header und Footer gemeinsam nutzen, während sich der Hauptinhalt zwischen URLs unterscheidet. Es funktioniert nicht genau gleich, erfüllt aber einen ähnlichen Zweck: Gemeinsames nicht jedes Mal neu aufbauen zu müssen.

Wie Astro URLs organisiert

Astro verwendet ein dateibasiertes Routing-System. In einem einfachen Projekt bestimmt der Speicherort einer Seite innerhalb von src/pages ihre Adresse:

Datei	Route
src/pages/index.astro	/
src/pages/contacto.astro	/contacto
src/pages/servicios/bodas.astro	/servicios/bodas

Der abschließende Schrägstrich hängt von Konfiguration und Hosting ab, aber das ist die grundlegende Beziehung.

Du musst nicht für jeden Artikel oder Service manuell eine eigene Datei erstellen. So lassen sich viele Seiten aus einem Template und einem Datensatz erzeugen, ohne denselben Code immer wieder zu kopieren.

Wo Inhalte gespeichert werden, wenn Astro keine Datenbank hat

Dass Astro keine Datenbank verlangt, bedeutet, dass Texte und Daten in irgendeiner Art von Quelle gespeichert werden müssen; welche das ist, kannst du wählen.

Dateien, Markdown, JSON und YAML

Bei einer kleinen Website kann ein Teil des Textes direkt in den Seiten stehen. Gemeinsame Daten wie die Telefonnummer solltest du separat halten, damit du sie nicht an zwanzig Stellen ändern musst.

Ein Artikel kann in Markdown gespeichert werden, einem Textformat mit einfacher Auszeichnung für Überschriften, Listen und Links. JSON und YAML dienen zur Organisation von Daten: Service-Einträge, Fahrzeuginformationen oder Texte nach Sprache zum Beispiel.

Das sind unterschiedliche Formate für unterschiedliche Anforderungen. Du musst nicht alle verwenden und nicht jeden Satz deiner Website in eine komplizierte Struktur verwandeln.

Content Collections

Die Content Collections, also Inhaltssammlungen, helfen dabei, Gruppen von Dateneinträgen zu organisieren und ihre Struktur zu definieren..

Stell dir eine Servicesammlung vor, in der jeder Eintrag einen Titel, eine Beschreibung und ein Bild haben muss. Du kannst diese Regeln festlegen und die Daten validieren, sodass ein unvollständiger Eintrag oder ein Wert vom falschen Typ leichter auffällt.

Wenn du Inhaltstypen und benutzerdefinierte Felder aus WordPress kennst, wird dir die Idee, Einträge zu organisieren, vertraut vorkommen.

Fortgeschrittene Inhalte: APIs, CMS und externe Datenbanken

Auch wenn wir statische Websites erzeugen, können Inhalte auch aus einem CMS, einer API oder einer Datenbank stammen. Eine API ist eine Möglichkeit, wie zwei Systeme Informationen austauschen: Astro fordert Daten an und das andere System liefert sie.

Du kannst sogar WordPress als Quelle für Artikel verwenden und die öffentliche Website mit Astro bauen. Mehr zu dieser Kombination erfährst du hier: Astro vs WordPress..

Die entscheidende Frage ist, wann du diese Informationen abrufst. Werden sie während des Builds eingebunden, ändert eine Änderung in der Quelle das veröffentlichte HTML erst, wenn du es neu erzeugst. Werden sie bei einer Anfrage oder im Browser abgerufen, verhält sich das anders und ähnelt eher traditionellen dynamischen Seiten.

Was Astro Islands sind

Eine Seite kann viel Inhalt enthalten, den man nur lesen muss, und einen kleinen Teil, mit dem man interagieren möchte. Zum Beispiel einen Preisrechner innerhalb einer Serviceseite. Oder ein Formular..

Die Islands -Architektur ermöglicht, dass diese Komponente ihr eigenes Verhalten hat , ohne die gesamte Seite in eine im Browser laufende Anwendung zu verwandeln.

Was es bedeutet, eine Komponente zu hydrieren

Hydrieren bedeutet, den Code einer interaktiven Komponente zu bereits erzeugtem HTML hinzuzufügen, damit sie auf Aktionen des Nutzers reagieren kann.

Der Rechner oder das Formular können beim Laden der Seite angezeigt werden und anschließend ihre Logik aktivieren.. 

Hier sprechen wir von Client Islands. Astro bietet auch Server Islands , um dynamische Teile getrennt zu verarbeiten, auch wenn wir darauf für diese erste Erklärung nicht näher eingehen müssen.

Wann der Browser JavaScript braucht

Nicht jede Interaktion erfordert eine Island. Ein Link funktioniert mit HTML. Ein einfaches Dropdown-Menü lässt sich mit HTML und CSS umsetzen.

Ein Rechner hingegen, der Ergebnisse aktualisiert, während du Optionen änderst, braucht in der Regel JavaScript. Und das Formular benötigt eine Integration oder eine serverseitige Sprache, um die Daten zu senden.

Und genau hier gefällt mir Astros Ansatz: Die Entscheidung richtet sich nach der Funktion, die du anbieten willst, nicht nach der abgedroschenen Vorstellung, dass eine moderne Website eine komplette Anwendung laden müsse..

Astro versucht standardmäßig null JavaScript auszuliefern

Achtung, nicht verwechseln: Wir sprechen von der Website, die der Nutzer sieht.. 

Denn Astro verwendet JavaScript durchaus zum Arbeiten und Kompilieren, aber .astro -Komponenten müssen ihren Vorbereitungscode nicht an den Browser senden. 

Von dir hinzugefügte Scripts, hydrierte Islands und externe Tools können dennoch JavaScript einbinden. Ein Chat, eine Analytics-Plattform (GA4) oder ein eingebettetes Video brauchen es.

Daher gilt: „standardmäßig null JavaScript“ ist der Ausgangspunkt, keine Verpflichtung.

Und wie ich weiter unten erkläre, passt das für mich zum Beispiel extrem gut zur Entwicklung von Unternehmenswebsites.

Astro kann nicht nur statisch, sondern auch dynamisch oder hybrid sein

Gut, bisher habe ich mich auf einen einzigen Ansatz konzentriert, aber es gibt zwei Möglichkeiten.

SSG

Was wir bisher gesehen haben: Die Seite wird vor den Besuchen erzeugt, während des Builds. 

Das ist perfekt, wenn der Inhalt für alle bis zur nächsten Veröffentlichung gleich bleiben kann. Also für Seiten, die sich nicht oft ändern.

SSR

Die Seite wird bei Bedarf auf dem Server erzeugt. Sie kann Informationen verwenden, die während des Builds nicht vorliegen, etwa Daten, die mit einer Sitzung verknüpft sind. 

Jetzt reicht nicht mehr jeder Server: Du brauchst eine kompatible Laufzeitumgebung und den passenden Adapter.

Hybrides Rendering

Du kannst vorgerenderte Seiten und bei Bedarf erzeugte Seiten kombinieren. Zum Beispiel öffentliche Seiten vorbereiten und einen privaten Bereich auf dem Server verarbeiten.

Welche Rolle Node.js und Vite spielen

Node.js ermöglicht es, JavaScript außerhalb des Browsers auszuführen. In einem typischen Astro-Projekt ist es an Entwicklung und Build beteiligt, wobei npm bei der Verwaltung von Paketen und Befehlen hilft. Bei einer statischen Website muss Node.js auf dem Produktionsserver, auf dem der Build liegt, nicht laufen.

Vite ist eine Engine, die von vielen modernen Frameworks verwendet wird. Sie ist Teil der Maschinerie, mit der Astro Dateien verarbeitet und die Entwicklungsumgebung bereitstellt. 

Das reicht, um dir eine Vorstellung zu machen.

Wie ein Astro-Projekt organisiert ist

Wenn du ein Projekt öffnest, siehst du Ordner, die keine Seiten sind, und Dateien, die nicht veröffentlicht werden. Diese kleine Übersicht hilft dir, sie auseinanderzuhalten.

src

Enthält den Quellcode: Seiten, Komponenten, Layouts und andere Arbeitsdateien. Hier wird ein großer Teil der Website aufgebaut.

public

Enthält Ressourcen, die ohne die übliche Verarbeitung importierter Dateien ausgeliefert werden: zum Beispiel eine robots.txt oder bestimmte Bilder. Alles, was du hier ablegst, ist öffentlich, deshalb gehören Zugangsdaten nicht hierher.

package.json

Beschreibt das Projekt, seine Abhängigkeiten und Scripts. Dort wird festgelegt, was Befehle wie npm run build ausführen. Die Lock-Datei der Abhängigkeiten hilft, konkrete Versionen beizubehalten, damit sich die Installation reproduzieren lässt.

node_modules

Das ist der Ordner, in dem die für das Projekt benötigten Pakete installiert werden. Er wird normalerweise aus den Abhängigkeitsdateien neu erstellt und nicht vollständig in Git gespeichert.

dist

Enthält die Produktionsausgabe nach dem Build. Bei einer statischen Website findest du hier die zum Veröffentlichen vorbereiteten Dateien.

Was Browser und Google tatsächlich laden

Ich wiederhole es noch einmal für die Leute in der letzten Reihe: Der Browser erhält dein Projekt nicht so, wie du es im Editor siehst. Er erhält das HTML und die Ressourcen, die zum Anzeigen und Verwenden der Seite nötig sind.

Eine Suchmaschine, die diese URL abruft, erhält das HTML – egal, ob du es während des Builds vorbereitet oder auf dem Server erzeugt hast. Das garantiert weder Indexierung noch gute Rankings: Inhalte, Links sowie Crawling- und Indexierungseinstellungen bleiben wichtig. Nach meiner Erfahrung lässt sich das, was ausgeliefert wird, aber sehr, sehr gut optimieren.

Die Idee, die du mitnehmen sollst, ist diese: All diese Templates, Collections und Komponenten dienen dazu, eine Website zu erzeugen, die weiterhin die bekannten Technologien verwendet. Astro steuert die Erstellung der Website; das resultierende HTML wird von einem Browser empfangen.

Fazit: Für welche Arten von Websites Astro sinnvoll ist

Diese Arbeitsweise eignet sich gut für Websites, deren Inhalte sich nicht übermäßig oft ändern:

• Unternehmenswebsites.
• Portfolios
• Landingpages.

Für Magazine, Blogs und Websites, auf denen viel Inhalt erstellt wird oder mehrere Content-Creator arbeiten, würde ich es nicht empfehlen. Dafür bevorzuge ich weiterhin WordPress gegenüber Astro..

Wenn dir der Ansatz gefällt und du mehr wissen willst, kannst du weiterlesen über die Vor- und Nachteile von Astro..

Und wenn du es lieber an einem vollständigen Projekt praktisch sehen willst, habe ich den Prozess vorbereitet, mit KI eine Website für ein lokales Unternehmen zu erstellen, wobei ich mein letztes Projekt als Beispiel verwende.

Ich garantiere dir: Wenn du es einmal ausprobiert hast, gibt es kein Zurück.