Astro ist eine Rückkehr zu den Grundlagen des Webs

 (websmith.studio)
17 Punkte von GN⁺ 2025-07-10 | 1 Kommentare | Auf WhatsApp teilen

„Astro ist das beste Framework für Entwickler.“

  • Astro ist ein neuartiges Web-Framework, das für content-zentrierte Websites optimiert ist und standardmäßig eine Zero-JavaScript-Strategie, starke Performance und eine unkomplizierte Developer Experience bietet
  • Mit dem einzigartigen Ansatz der Island Architecture wird JavaScript nur dort eingesetzt, wo es gebraucht wird; der Rest wird als schnelles statisches HTML ausgeliefert
  • Astro-Websites laden im Vergleich zu klassischen React-basierten Ansätzen mehr als 40 % schneller, was konkrete Vorteile bei SEO, User Experience und Conversion bringt
  • Anders als bei anderen Frameworks sind Datenlogik und Frontend-Komponenten klar getrennt, zudem lässt sich Astro mit verschiedenen Frameworks wie React oder Vue kombinieren
  • Allerdings können Next.js und andere etablierte Frameworks besser geeignet sein, wenn SPA, komplexes State Management oder umfangreiches Routing erforderlich sind

Was ist Astro?

  • Astro ist ein 2021 erschienenes Web-Framework, das im Gegensatz zu bestehenden JS-Frameworks für komplexe Apps gezielt für content-zentrierte Websites konzipiert wurde
  • Die Grundphilosophie lautet „Content first, server first, standardmäßig Zero JavaScript“, wobei auch das Tooling als intuitiv und einfach gilt

Island Architecture

  • Astro führt das Konzept der „Island Architecture“ ein, bei dem nicht die gesamte Seite, sondern nur die benötigten Teile mit JavaScript versehen werden
  • Seiten wie Blogposts, die überwiegend aus Text bestehen, werden nur als HTML gerendert, und nur für interaktive Bereiche wie Kommentare oder Karussells wird JS geladen
  • Dadurch bleiben Seiten sehr schnell und leichtgewichtig

Reale Performance und Wirkung

  • Astro-basierte Websites erreichen mehr als 40 % schnellere Ladezeiten als traditionelle React-Frameworks
  • Diese Performance-Verbesserungen wirken sich auf Suchmaschinen-Rankings, Nutzerzufriedenheit und Conversion als geschäftliche Kennzahlen aus
  • Auf langsamen Geräten und in Netzwerken mit geringer Bandbreite ist der Geschwindigkeitsunterschied noch deutlicher spürbar

Developer Experience

  • Das Projekt-Setup ist einfach, und ein freundlicher Setup-Assistent namens „Houston“ führt durch den Prozess
  • Astro-Komponenten ermöglichen Logik, die nur zur Build-Zeit ausgeführt wird (z. B. Datenabfragen oder API-Aufrufe)
  • Ohne sich um komplexes State Management, Lifecycles oder Hooks kümmern zu müssen, kann clientseitiges JS nur dann genutzt werden, wenn es wirklich nötig ist

Kompatibilität mit verschiedenen Frameworks

  • Wichtige Frameworks wie React oder Vue lassen sich frei mit Astro kombinieren
  • Beispiel: Ein Admin-Dashboard in React, Datenvisualisierung in Vue und der Rest in Astro

Praktische Funktionen, die „einfach funktionieren“

  • Markdown kann direkt wie eine Komponente importiert und verwendet werden
  • Unterstützung für moderne Build-Pipelines wie TypeScript, Sass, Bildoptimierung und Hot Module Replacement
  • Statische Sites / SSR / hybrides Rendering sind alle wählbar und lassen sich flexibel passend zum Projekt einsetzen

Wo Astro glänzt

  • Marketing-Websites, Blogs, E-Commerce-Kataloge und Portfolios profitieren besonders bei content-zentrierten Projekten von der Performance
  • Ideal in Umgebungen, in denen kein komplexes clientseitiges State Management erforderlich ist

Trade-offs

  • Für Projekte, bei denen SPA, komplexes Routing oder geteiltes State Management zwischen Komponenten wichtig sind, können andere Frameworks wie Next.js besser geeignet sein
  • Das Ökosystem ist noch relativ klein, und file-basiertes Routing kann sich in großen Projekten eingeschränkt anfühlen

Schneller Einstieg

  • npm create astro@latest my-site
  • Bei Bedarf Frameworks mit npx astro add react ergänzen
  • Seiten in src/pages/ und Komponenten in src/components/ anlegen und mit der Entwicklung beginnen

Die Bedeutung von Astro

  • Während JS-Frameworks zuletzt immer komplexer geworden sind, bedeutet Astro eine Rückkehr zu den Grundlagen des Webs – also zu einer schnellen, zugänglichen und content-zentrierten Erfahrung – ohne die Entwicklerfreundlichkeit zu opfern
  • Die Designphilosophie „schnelle Websites als Standard, Interaktivität nur dort, wo sie gebraucht wird, und freie Wahl des gewünschten Frameworks“ kommt bei Entwicklern gut an
  • Von Blogs bis E-Commerce ist Astro eine klare Empfehlung für content-zentrierte Projekte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-07-10
Hacker-News-Kommentare

  • Traditionelle Web-Frameworks haben immer die ganze Seite mit JavaScript „hydratisiert“: Selbst wenn es in einem einfachen Blogbeitrag nur ein einziges interaktives Widget gab, wurde alles mit JavaScript verarbeitet. Astro dagegen verwendet standardmäßig statisches HTML und lässt nur die nötigen Teile als „JavaScript Islands“ laufen. Früher nannte man so etwas „Progressive Enhancement“ oder einfach „Webseite“, und das war der Standard beim Erstellen von Websites. Danach kamen SPAs auf, und Progressive Enhancement wurde immer seltener genutzt. Heute nennt man es „JavaScript Islands“, aber letztlich ist es eine Rückkehr zur alten Methode. Allen interessierten Webentwicklern am Anfang ihrer Laufbahn würde ich das Konzept des Progressive Enhancement empfehlen.

    • Es kommt oft vor, dass jemand die Beschreibung eines neuen Tools hört und dann denkt, das sei doch dasselbe wie etwas, das es schon früher gab. Der eigentliche Wert von Astro liegt aber darin, dass es mit verschiedenen JavaScript-Frameworks zusammenarbeitet und dabei nur jeweils bestimmte HTML-Subtrees separat verarbeiten kann. Der Initialzustand wird dabei als String gerendert und auf der Client-Seite mit vorab geladenen Daten hydratisiert. Das ist wertvoll, wenn man Frameworks wie React/Svelte/Solid/Vue nur für einzelne Teile einer Seite einsetzen und Daten vorab vom Server laden möchte. Das ist allerdings kein „Progressive Enhancement“: Das HTML vor der Hydratisierung muss nicht korrekt funktionieren. Ein <form> muss zum Beispiel ohne JavaScript nicht funktionieren. Genau solche Details erkennt man eher, wenn man neugierig statt zynisch an die Sache herangeht.

    • Stimme ich völlig zu. Astro ist ein großartiges Tool, aber das Schwierigste daran war für mich, all die Begriffe zu verstehen, die Entwickler, die nach 2010 eingestiegen sind, erfunden haben, um zu erklären, wie das Web funktioniert.

    • Es ist kein neues Konzept, aber die heutige Umsetzung wirkt deutlich ausgefeilter. Früher habe ich mit PHP und jQuery interaktive Websites gebaut, also noch vor React und SPAs. Rückblickend war die damalige Architektur eleganter, aber Debugging und DX waren wirklich schlecht. Ich möchte nicht noch einmal Zeit damit verbringen, mit PHP im Frontend zu debuggen. SPAs haben weiterhin ihren Platz bei komplexen Dashboards oder interaktiven Apps. Astro sorgt dafür, dass Server- und Client-Code an einem Ort verwaltet werden und klar getrennt sind, sodass man Daten nicht mehr erst mit PHP parsen und dann an JS weiterreichen muss, was die DX stark verbessert.

    • Ich erinnere mich noch an die Zeit, als man das AJAX nannte. Fühlt sich an, als hätte man völlig den Faden verloren.

    • Ich finde, frühe Web-Frameworks hatten den Umgang mit zustandslosen Websites und Server-Rendering wirklich richtig gut gelöst.

  • Ich persönlich empfehle Astro sehr. Anfangs hielt ich es für „ein Tool, das nur Includes zu HTML und CSS hinzufügt“, aber nachdem ich es für meine persönliche Website und beim Redesign der Matrix-Conference-Website verwendet habe, war es wirklich angenehm und ohne viel Aufwand zu benutzen.
    Die wichtigsten Vorteile von Astro:

    • immer noch HTML- und CSS-zentriert
    • nach dem Build standardmäßig kein JS nötig
    • JS kann gezielt nur dort hinzugefügt werden, wo Interaktivität gebraucht wird
    • die Content-Collections-Funktion ist sauber umgesetzt
    • Geschwindigkeitsoptimierung ist extrem gut, und die Maintainer wissen sehr genau, wie man das macht
    • es gibt eine Devbar für die Entwicklung, die visuell zeigt, wo eine Website noch schneller werden kann (z. B. Lazy Loading von Bildern unterhalb des sichtbaren Bereichs)
    • der CSS-Minifier inlinet einen Teil des CSS, um zusätzliche Requests zu reduzieren
    • die Bildkomponente setzt automatisch width/height-Attribute, um Content Layout Shift zu verhindern, und liefert auch responsive images

    • Wenn Astro HTML- und CSS-zentriert ist und nur bei Bedarf JS hinzufügt, dann hätte man doch im Prinzip dieselbe Erfahrung, wenn man direkt .html, .css und .js im Dateisystem anlegt und deployt. Eher wäre das sogar schneller, weil Dev-Time-Overhead und unnötiger Bloat entfallen. Außerdem war das Inlinen von CSS aus Performance-Sicht nie wirklich ein großes Problem. Aus Erfahrung mit Hunderten von Websites war CSS fast nie der Flaschenhals, sondern in der Praxis eher das Netzwerk.

    • Mein einziger echter Kritikpunkt war, dass das Routing mit zunehmender Komplexität sehr schnell immer stärker abstrahiert und dadurch eher verwirrender wurde. Komplexität bringt eben immer Friction mit sich, deshalb habe ich mich am Ende für einen anderen Ansatz entschieden.

    • Wenn man nur „Includes für HTML und CSS“ braucht, kann man auf einem normalen Webserver wie nginx einfach Server Side Includes aktivieren. Das ist seit über 20 Jahren eine stabile Lösung, die praktisch keine Wartung braucht. Außerdem bringt sie nicht die zusätzlichen Sicherheitsrisiken einer Template Engine mit sich: Man vermeidet Redundanz und kann reine Includes nutzen, ohne sich um Backend-Schwachstellen sorgen zu müssen.

    • Ich habe 20 Jahre lang nur Daten/Backend gemacht und bin wegen eines Frontend-Projekts wieder dazu zurückgekehrt. Nach viel Ärger mit React bin ich auf Astro+Svelte umgestiegen, und das war ein voller Erfolg. Weil es HTML/CSS-zentriert ist, ist die Code-Struktur vorhersehbar und sauber. Als ich das Frontend dann an einen Entwickler mit React-Erfahrung übergeben habe, hat er sich fast sofort zurechtgefunden.

  • Wenn ich höre, dass mit „traditionellen Frameworks“ SPA-/Virtual-DOM-Frameworks gemeint sind, merke ich den Generationenunterschied. Backbone, jQuery und Ähnliches waren die wirklich traditionellen Web-Frameworks, und genau sie funktionierten so, wie es im Blogbeitrag beschrieben wird.

    • „Tradition“ hängt letztlich davon ab, wann man geboren wurde. Für mich sind traditionelles Internet 56k-Modems, vbulletin-Foren, GTA:VC-Mods und IRC. Für ältere Generationen sind es BBS, für jüngere eher Discord. In der Politik gibt es ein ähnliches Phänomen: Jeder neigt dazu zu glauben, dass die Zeit gut war, als er jung war.

    • Ich erinnere mich, dass Backbone als reines SPA-Konzept auf clientseitiges MVC abzielte.

  • Ich frage mich, warum SSR-Frameworks wie Astro oder NextJS statische Seiten mit dynamischen Pfaden nicht so unterstützen wie SvelteKit. Eine Seite wie /todos/[todoId] lässt sich in NextJS zum Beispiel gar nicht als statisches Bundle aufnehmen. In SvelteKit funktioniert das dagegen über 404.html: Technisch ist es zwar ein 404, aber in Umgebungen wie Cloudflare oder mobilen WebViews funktioniert es perfekt. Gerade für das Bundling in mobilen WebViews ist das sehr nützlich.

    • Dem stimme ich teilweise zu, aber dieses Design hat auch Nachteile. Wenn man eine URL wie /todos/123 in einer SPA per Hard Reload lädt, fragt der Browser auf dem echten Server nach, ob es diese Datei gibt. Falls nicht, bekommt man ein 404 zurück. Dann muss die 404-Seite per Client-Routing die Daten erneut laden und verarbeiten. Dafür braucht man unbedingt eine HTTP-Server-Konfiguration wie in nginx, also geht es nicht mit rein statischen Dateien allein. Außerdem speichert der Browser-Cache laut HTTP-Spezifikation 404-Antworten niemals, deshalb kann man bei Hard Reloads oder Bookmarks nie den Cache nutzen. Wenn einem diese Konfiguration zu aufwendig ist, finde ich Query-Parameter wie /todo?id=123 unter Umständen sinnvoller.

    • Vielleicht habe ich es falsch verstanden, aber ich habe in statischen Builds von Next oder Astro schon dynamisches Routing bzw. dynamische Seiten umgesetzt. Bei CMS-Setups mit contentful oder storyblok konnten Editoren frei Routen und Komponenten anlegen, und ich habe mit dem Muster [...slug] alle Routen abgedeckt. Mit der Funktion getStaticPaths wurden dann alle Seiten vorab generiert. Wenn ISR/ISP aktiviert ist, werden auch Seiten, die zur Build-Zeit noch unbekannt waren, dynamisch vorgerendert. In Next heißt das dynamic routes, in Astro dynamic pages.
      Siehe: Next dynamic routes, Astro dynamic pages

    • Vielleicht verstehe ich es falsch, aber die Funktion getStaticPaths in Astro scheint genau das zu unterstützen, was du suchst.
      Siehe

    • Ich mag statische Deployments auch, deshalb als Hinweis: NextJS unterstützt ebenfalls die Generierung statischer Parameter.

    • Ich habe Astro und die verschiedenen Frameworks vielleicht noch nicht vollständig verstanden, aber eventuell ist Astors server islands nah an dem, was du suchst.

  • Ich finde die ganze Frontend-Diskussion viel zu verwirrend. Auch das, worüber der Artikel spricht, läuft am Ende auf die Frage hinaus, ob man den Browser als HMI oder als Application Runtime benutzen will. Trotzdem besteht der Großteil der Debatte aus vagen Aussagen wie „fühlt sich frisch an“ oder „lädt schnell“. Die Art, wie Frameworks fast wie Marken beworben werden, erinnert mich stark an die Modeindustrie.

    • Die Modeindustrie ist wahrscheinlich sogar die beste Analogie, um Diskussionen über Frontend-Frameworks zu erklären. Aussagen wie „content-driven“ oder „server-first“ werden kaum je technisch präzise hinterfragt.

    • Ich verstehe nicht, wie „lädt schnell“ eine Illusion sein soll. Das ist ein tatsächlich wichtiger Faktor.

  • Ich habe vor Kurzem eine Website für eine medizinische Einrichtung mit Astro gebaut, und es war viel einfacher als früher mit Wordpress. Außerdem kann man kostenlos bei Netlify oder ähnlichen Diensten hosten und muss sich keine Sorgen um Hacks machen. Ich habe sogar ein simples git-basiertes CMS gebaut, damit der Kunde Inhalte selbst bearbeiten kann. Da merkt man wirklich, wie weit sich Webentwicklung entwickelt hat.

    • War das ein Projekt für Bekannte, oder wie kommt man an Aufträge für Websites von medizinischen Einrichtungen?

    • Achtung: Netlify hat höhere Bandbreitenkosten als Vercel.

  • Der größte Vorteil von Astro ist für mich, dass man ohne Abhängigkeit von anderen Frameworks wie React oder Vue arbeiten kann und stattdessen nur mit HTML oder Web Components auskommt. Gleichzeitig unterstützt Astro aber wie Next und Nuxt auch SSR, ISR, SSG und Middleware.
    Als Unterscheidungsmerkmal gibt es die Islands-Architektur, mit der sich Micro-Frontends umsetzen lassen.
    Zum Beispiel können in einem Unternehmen mehrere Teams jeweils Checkout, Warenkorb und Produktseiten bauen und trotzdem alles auf einer Seite integrieren. Die Rendering-Methode lässt sich direkt steuern, und globaler State kann ebenfalls geteilt werden. So kann jedes Team unabhängig die Verantwortung für seinen Teil übernehmen und ihn separat entwickeln und deployen.
    Allerdings ist so eine Struktur nur bei großen Projekten wirklich nötig. Wenn alle Teams React auf unterschiedliche Weise einsetzen, entstehen schnell viele verschiedene Versionen nebeneinander, während Astro dieses Problem durch architektonische Trennung lösen kann.
    Ich bin mir nicht sicher, ob das das Web komplett verändern wird. Für mich fühlt es sich eher wie Next/Nuxt ohne starke Framework-Abhängigkeit und mit zusätzlicher Islands-Architektur an. Trotzdem würde ich empfehlen, es einmal auszuprobieren.
    Wenn man von React/Vue weg und zu Web Components wechseln oder Next/Nuxt ersetzen möchte, kann Astro schrittweise dafür eingesetzt werden, deshalb empfehle ich es.

  • Für mich ist Astro nicht in jeder Situation perfekt. Wenn man zum Beispiel nur Offline-Rendering braucht, gibt es keinen Grund, sich zwanghaft JavaScript aufzudrängen.
    Auch die Islands-Architektur hat ihre Grenzen, und die Build-Ergebnisse werden oft zu stark inlined.
    Ehrlich gesagt hat der Astro-Hype wahrscheinlich mehr mit Vite zu tun. Vite ist wirklich großartig.

    • Ich würde gerne wissen, wann genau „die Islands-Architektur an ihre Grenzen stößt“.

  • Ich wünschte, Next.js würde nicht als Standard-Framework für React empfohlen. Im Frontend braucht es mehr kritisches Denken. Remix (React Router v7) oder TanStack sind deutlich bessere Alternativen.

    • Stimme ich zu. Next.js hatte definitiv Potenzial, aber seit Vercel stärker eingegriffen hat, hat es sich für mein Gefühl deutlich zurückentwickelt. Ich nutze es seit v10 und war sowohl von der Verwirrung in v13 als auch von v15 ziemlich enttäuscht. React und Next.js verändern sich so schnell, dass man kaum noch hinterherkommt, und oft wirkt es eher wie Veränderung um der Veränderung willen als wie wirklich notwendiger Fortschritt.

    • Ich würde sogar aufhören, React selbst als Standard-Framework zu empfehlen. Für Frontend-Entwicklung halte ich HTML/CSS/JS für deutlich besser.

    • Ich denke, Remix/React Router v7 geht in die richtige Richtung. Besonders wenn Remix auf preact setzen und sich stärker an Webstandards orientieren würde, könnte das zu einer robusteren Art des Website-Bauens zurückführen. Allerdings verlief der Wechsel von Remix zu RR7 nicht reibungslos, sodass ich ein Projekt komplett neu schreiben musste.

  • Ich denke, die Grundprinzipien des Webs gelten weiterhin. Wer mit PHP, Spring, Quarkus oder ASP.NET MVC arbeitet, merkt vielleicht gar nicht, wie anstrengend JavaScript-Framework-zentrierte Webentwicklung geworden ist. Durch die modegetriebene Stimmung in der Branche ist es nicht leicht, zu den Grundlagen zurückzukehren.