astro.build

Mit dem vorherrschenden Nutzererlebnis beginnen

Verwenden Sie die auf dieser Seite verlinkten Alternativen als Kandidaten und vergleichen Sie diese anschließend mit der Art von Erlebnis, das Sie tatsächlich bereitstellen müssen. Astro ist am unmittelbarsten auf Projekte abgestimmt, bei denen das Lesen, Navigieren, Vergleichen oder Entdecken von Inhalten wichtiger ist als ein kontinuierlicher clientseitiger Zustand im Browser.

Wählen Sie die Aussage aus, die am besten zu Ihrem Projekt passt:

• Der Großteil der Seite sollte als HTML funktionieren. Gewichten Sie Astro stärker, da statische Inhalte standardmäßig kein clientseitiges JavaScript benötigen.
• Interaktion findet in mehreren klar abgegrenzten Steuerelementen statt. Testen Sie, ob diese Steuerelemente klare, unabhängig hydrierte Islands bilden.
• Nahezu jeder Bereich teilt sich einen dynamischen clientseitigen Zustand. Prüfen Sie anwendungsorientierte Kandidaten sorgfältig, da Island-Grenzen möglicherweise weniger Nutzen bringen.
• Die Veröffentlichung von Markdown benötigt eine einheitliche Struktur. Vergleichen Sie Astros validierte, TypeScript-kompatible Content Collections mit dem Content-Modell jedes verlinkten Kandidaten.
• Das Team muss vorhandene UI-Komponenten wiederverwenden. Prüfen Sie die relevante Integration, die Runtime-Kosten und die Wartungsanforderungen, statt davon auszugehen, dass sich jedes Komponentensystem beliebig kombinieren lässt.

Eine repräsentative Seite vergleichen

Verwenden Sie für jede verlinkte Alternative dieselbe echte Seite und dieselben Anforderungen. Eine Starter-Vorlage beweist, dass ein Werkzeug funktioniert, zeigt jedoch nicht, ob seine Architektur zu Ihren schwierigsten Anforderungen an Inhalte, Interaktion und redaktionelle Arbeit passt.

Entscheidungsfrage	Zu erhebende Nachweise
Kommen wesentliche Inhalte ohne Ausführung im Browser an?	Untersuchen Sie das ausgelieferte HTML
Lässt sich die Interaktion sauber trennen?	Ordnen Sie Komponenten und gemeinsamen clientseitigen Zustand zu
Wann sollte jedes Steuerelement aktiviert werden?	Testen Sie Anforderungen an sofortiges, Leerlauf- und Viewport-basiertes Laden
Ist der Content-Arbeitsablauf wartbar?	Modellieren Sie eine echte Collection mit Validierungsanforderungen
Was gelangt in den Browser?	Prüfen Sie Komponentencode, Runtimes, Medien und Skripte von Drittanbietern
Kann das Team das System zuverlässig betreiben?	Vergleichen Sie Konventionen, Fehlersuche und laufende Wartung

Eine interaktive Bewertungstabelle anwenden

Bewerten Sie für jeden verlinkten Kandidaten jedes Kriterium als sehr gut geeignet, praktikabel oder mit hohen Hürden verbunden. Gewichten Sie die Kriterien entsprechend dem Projekt, statt lediglich die Bewertungen zu zählen.

1. Inhalte sind als nützliches HTML verfügbar.
2. Klarheit der Interaktionsgrenzen.
3. Unterstützung für den bevorzugten UI-Ansatz des Teams.
4. Strukturierte Inhalte und Validierung.
5. Kosten eines gemeinsamen clientseitigen Zustands.
6. Integrations- und Deployment-Anforderungen.
7. Duplizierung von Runtime-Code und Wartung von Abhängigkeiten.
8. Barrierefreiheit bei realen Interaktionsmustern.

Wenn Astro ein Kandidat bleibt, testen Sie ein großes oder anspruchsvolles Island und nicht nur einen statischen Artikel. Wenn eine verlinkte Alternative ein Kandidat bleibt, unterziehen Sie sie denselben Medien, derselben Navigation, denselben Skripten von Drittanbietern und demselben redaktionellen Arbeitsablauf, damit der Vergleich die Produktionsbedingungen widerspiegelt.