Erste Eindrücke von Astro: Was mir gefiel und was nicht

Ich habe vor kurzem damit begonnen, Astro zu verwenden, um Nebenprojekte neu zu erstellen, die ursprünglich mit WordPress, Go, Rails und Hugo erstellt wurden. Ich habe mich für Astro entschieden, weil es über ein React-ähnliches DX mit guter Sprachserverunterstützung verfügt und weil es mit serverlosen Hosting-Plattformen kompatibel ist, die über ein großzügiges kostenloses Kontingent verfügen (Cloudflare, AWS Lambda usw.).

Ich wusste nicht viel über Astro, als ich anfing, es zu benutzen. Nachdem ich nun mehrere Websites migriert habe, möchte ich allen, die darüber nachdenken, es zu verwenden, mitteilen, was mir an dem Framework gefällt und was nicht.

Astro: Was mir gefallen hat

Im Kern ist Astro ein statischer Site-Generator mit der Fähigkeit, bei Bedarf dynamische, vom Server gerenderte Seiten zu erstellen. Astro eignet sich hervorragend für Blogs oder kleine Marketingseiten mit eingeschränkter Interaktivität. Das Framework stellt den Großteil der DX von Next.js ohne den React.js-Overhead bereit.

Gute IntelliSense- und Codeformatierung in einer vom Server gerenderten Vorlagensprache

Seien wir ehrlich: Gute Sprachserverunterstützung und Codeformatierung fehlen in herkömmlichen, servergerenderten Vorlagensprachen erheblich. Go-Vorlagen, Jinja, ERB und EJS liegen im Vergleich zu ihren React/Vue/Svelte-Gegenstücken bei der Toolausstattung deutlich zurück. Die meisten vom Server gerenderten Vorlagensprachen haben keine Möglichkeit zu wissen, welche Variablen sich im Gültigkeitsbereich befinden oder welche Typen sie haben.

Mit Astro sind alle diese Funktionen nur eine VS Code-Erweiterung entfernt.

Innerhalb von Astro-Vorlagen legen Sie Ihre Daten oben in der Vorlage innerhalb eines „Codezauns“ fest, der entweder zur Erstellungszeit oder bei der Beantwortung einer Anfrage auf dem Server ausgeführt wird. So sieht das in der Praxis aus:

---
import Layout from "../layouts/Layout.astro";
import { getPosts } from "../data/posts";

const posts: { id, title }[] = await getPosts();
---
<layout pagetitle="Posts">
  <h1 id="Posts">Posts</h1>

  {post.length > 0 ? (
    <ul>
      {posts.map((post) => (
        <li>
          <a href="%7B%60/posts/%24%7Bpost.id%7D%60%7D">
            {post.title}
          </a>
        </li>
      )}
    </ul>
  ) : null}
</layout>

Da alle Daten für die Vorlage in den „Codezaun“ über der Vorlage geladen werden, kann der Sprachserver eine automatische Vervollständigung für die Eigenschaften aller im Bereich definierten Objekte bereitstellen. Es wird auch angezeigt, wenn Sie versuchen, eine Variable zu verwenden, die nicht existiert.

Astrodateien können „Komponenten“ sein

Einer meiner größten Kritikpunkte an traditionellen Vorlagensprachen wie Go-Vorlagen, Jinja und EJS ist, dass sie keine „Komponenten“ haben, die Kinder akzeptieren können. Die meisten meiner Websites verfügen über eine Art „Container“-UI-Element mit eingeschränkter Breite, das sicherstellt, dass der Inhalt auf ultrabreiten Monitoren nicht bis zum Ende des Bildschirms hinausfliegt. Wenn Sie eine .container-Klasse haben, die Sie manuell zu

hinzufügen Elemente, dann funktioniert das normalerweise gut. Wenn Sie jedoch ein Utility-CSS-Framework wie Tailwind verwenden, fügen Sie möglicherweise den folgenden Code zu jeder einzelnen Seitenvorlage hinzu:

<div>



<p>When you eventually need to change these classes, it's an error-prone pain to update each file manually. But if your templating language doesn't have components that can accept children, it's almost inevitable. </p>

<p>Unlike those traditional templating languages, Astro templates can be used as components that accept children using a <slot></slot> tag. A long string of utility classes could be extracted into a reusable Astro component:<br>
</p>

<pre class="brush:php;toolbar:false"><div>



<p>The Astro component could then be consumed from another Astro file.<br>
</p>

<pre class="brush:php;toolbar:false">---
import Container from "../components/Container.astro";
---
<container>
  <h1 id="Hello-world">Hello, world!</h1>
</container>

Astro-Dateien sind nicht auf einen einzelnen Steckplatz beschränkt: Sie können mehrere haben.

Mein Lieblingsmerkmal von Astro-Komponenten ist, dass sie Requisiten innerhalb des Codezauns akzeptieren können. Hier ist ein Beispiel:

---
import Layout from "../layouts/Layout.astro";
import { getPosts } from "../data/posts";

const posts: { id, title }[] = await getPosts();
---
<layout pagetitle="Posts">
  <h1 id="Posts">Posts</h1>

  {post.length > 0 ? (
    <ul>
      {posts.map((post) => (
        <li>
          <a href="%7B%60/posts/%24%7Bpost.id%7D%60%7D">
            {post.title}
          </a>
        </li>
      )}
    </ul>
  ) : null}
</layout>

Die Komponente kann dann Requisiten akzeptieren, wenn sie in einer anderen Datei verwendet wird.

<div>



<p>When you eventually need to change these classes, it's an error-prone pain to update each file manually. But if your templating language doesn't have components that can accept children, it's almost inevitable. </p>

<p>Unlike those traditional templating languages, Astro templates can be used as components that accept children using a <slot></slot> tag. A long string of utility classes could be extracted into a reusable Astro component:<br>
</p>

<pre class="brush:php;toolbar:false"><div>



<p>The Astro component could then be consumed from another Astro file.<br>
</p>

<pre class="brush:php;toolbar:false">---
import Container from "../components/Container.astro";
---
<container>
  <h1 id="Hello-world">Hello, world!</h1>
</container>

Eine Frontend-Asset-Pipeline mit Live-Reloads ist integriert

Ich habe bereits meine eigenen serverseitigen Integrationen mit Vite erstellt. Wenn Sie versuchen, schnell etwas online zu stellen, ist dies die Art von Standardfunktion, die Sie nicht selbst erstellen möchten. Bei Astro ist es integriert.

Wenn Sie einer Astro-Seite oder -Komponente ein benutzerdefiniertes Skript hinzufügen möchten, müssen Sie lediglich ein Skript-Tag auf der Seite einfügen.

---
type Props = { pageTitle: string; pageDescription: string };

const { pageTitle, pageDescription } = Astro.props;
---



  
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>{pageTitle}</title>
    <meta name="description" content="{pageDescription}">
  
  
    <slot></slot>
  

Astro kompiliert automatisch TS- und JS-Dateien als Teil des Erstellungsprozesses einer Site. Sie können auch Skripte schreiben, die Importe von node_modules innerhalb eines Skript-Tags innerhalb einer Astro-Komponente verwenden, und Astro kompiliert diese während der Erstellungszeit und extrahiert sie in eine eigene Datei.

---
import Layout from "../layouts/Layout.astro";
---
<layout pagetitle="Tyler's Blog" pagedescription="I don't really post on here.">
  <h1 id="Tyler-s-blog">Tyler's blog</h1>
  <p>Sorry, there's no content yet...</p>
</layout>

Sie können CSS- oder Scss-Stile in eine Astro-Datei einbinden, indem Sie sie innerhalb des Codezauns importieren.

<div>
  <h1 id="This-is-my-page">This is my page</h1>
  <script src="../assets/script.ts"></script>
</div>

Astro bietet auch die Möglichkeit, bereichsbezogene Stile zu erstellen, indem ein Stil-Tag in einer Astro-Datei verwendet wird. Diese Funktion ist Vue-Benutzern möglicherweise bekannt.

Gegeben sei die folgende Astro-Datei:

<script>
  // This will also compile down to a JavaScript file at build time.

  import axios, { type AxiosRequestConfig, type AxiosResponse } from "axios";

  const response = await axios
    .get<AxiosRequestConfig, AxiosResponse<{foo: string}>>("/some-endpoint");

  console.log(response.data.foo);
</script>

Einfach, oder?

Aktionen

Aktionen bieten eine typsichere Möglichkeit, Backend-Funktionen auszuführen. Sie bieten Validierung und können sowohl JSON- als auch Formulardaten verarbeiten. Sie sind mit Sicherheit eine der Killerfunktionen von Astro: All dies müsste auf maßgeschneiderte Weise in einer Next.js-App von Hand verkabelt werden. Sie erfordern etwas mehr Code, als in ein Beispiel passt, sind aber recht elegant zu verwenden. Ich würde empfehlen, die Seite mit den Aktionsdokumenten zu lesen.

Keine Laufzeit-JS-Kosten

Es gibt unzählige Twitter-Entwickler, die sagen, React sei „schnell genug“. Bei vielen Dingen ist das nicht der Fall.

Ich verwende Rasbperry Pi 4s für kleine Projekte, und Sie können spüren die Laufzeitkosten von React. Ich bin mir sicher, dass das auch bei preiswerten Android-Telefonen der Fall ist, außer dass in diesem Fall der JS-Overhead auch den Akku entlädt.

Wenn die einzige Interaktivität, die meine Website benötigt, das Umschalten eines Navigationsmenüs ist, würde ich das lieber selbst verkabeln. Ich greife gerne zu React, wenn ich es brauche, aber für so viele Projekte brauche ich es eigentlich nicht.

Astro: Was mir nicht gefallen hat

Die Dinge, die ich an Astro nicht mag, betreffen nicht nur das Framework: Es sind Ideen, die von anderen Tools im JavaScript-Ökosystem übernommen wurden.

Dateibasiertes Routing

Da Astro dateibasiertes Routing verwendet, erhält die Hälfte der Dateien in einem Astro-Projekt den Namen index.(astro|js|ts) oder [id].(astro|js|ts). Dateibasiertes Routing ist ein widerwärtiges Muster, das die Frontend-Welt im Sturm eroberte, nachdem Next.js es implementiert hatte, und es bringt viele Nachteile mit sich:

• In Ihrem Editor sind häufig fünf Registerkarten mit demselben Dateinamen geöffnet. Sie müssen mindestens dreimal raten, um die gesuchte Registerkarte zu finden.
• Der Datei-Fuzzy-Finder des Editors ist weitaus weniger nützlich, da so viele Dateien denselben Namen haben.
• Dateibasiertes Routing verstreut eines der Hauptanliegen einer Anwendung auf viele Dateien und Ordner, sodass es schwierig ist, alle Routen im Editor auf einen Blick zu sehen. Stattdessen müssen Sie einen Drilldown in mehrere Ordner durchführen, um zu verstehen, welche Seiten verfügbar sind.

Ich gebe zu: Dateibasiertes Routing fühlt sich großartig an, wenn Sie eine Website mit weniger als 10 Seiten erstellen. Aber wenn eine Website wächst, erhöht sich die Reibung, und Sie bekämpfen die Funktion mehr, als dass Sie davon profitieren.

Im JavaScript-Ökosystem zeichnet sich Remix dadurch aus, dass es eine Version des dateibasierten Routings anbietet, die alle Routen in einem einzigen Verzeichnis zusammenfasst und es einem Benutzer ermöglicht, das dateibasierte Routing durch manuelle Routenkonfiguration vollständig zu deaktivieren.

Dateibasiertes Routing ist mein größter Kritikpunkt an Astro, aber es ist eine Funktion, der ich nur schwer entkommen kann. Es ist in Next.js, Nuxt.js, SvelteKit und anderen implementiert. Was noch seltsamer ist, ist, dass diese Frameworks weitgehend uneinig sind, was die Dateinamen für andere Teile der Anwendung angeht. Im Gegensatz zu Ruby on Rails bieten Ihnen die meisten JavaScript-Frameworks ein hohes Maß an Freiheit bei Dateinamen und Projektstruktur – außer beim Routing. Es handelt sich um einen Sonderfall, und Sonderfälle erhöhen die Komplexität der Software.

Eine Komponente pro Datei (sozusagen)

Eine JavaScript-Sprachfunktion, die mir wirklich gefällt, ist die Möglichkeit, mehrere Variablen, Funktionen und Klassen in einer einzigen Datei zu definieren. Dies macht es einfach, verwandte Funktionen zusammenzufassen, ohne sie aufgrund von Einschränkungen auf Sprachebene vorzeitig in andere Dateien extrahieren zu müssen.

Ähnlich wie die Einzeldateikomponenten von Vue ermöglichen Astro-Dateien die Definition einer Komponente pro Datei. Das kommt mir mühsam vor, aber Astro bietet einen Workaround.

Astro kann vorgerenderte React-, Vue-, Svelte-, Solid- und Preact-Komponenten direkt in seine Vorlagen einbetten, ohne clientseitiges JavaScript zu laden. Preact-Komponenten lassen sich ziemlich gut mit Astro kombinieren, da Preact JSX viel näher an HTML ist als React JSX. Es wird allerdings umständlich, sowohl Astro- als auch Preact-Komponenten im selben Projekt zu verwalten, und sobald ich anfange, Preact-Komponenten zu verwenden, verschiebe ich den größten Teil der Benutzeroberfläche aus Astro-Dateien in Preact.

Letzte Gedanken zu Astro

Wenn Sie ein begeisterter Benutzer von Next.js, Nuxt oder SvelteKit sind und mit Ihrem Framework zufrieden sind, werden Sie möglicherweise nicht viel von Astro profitieren. Wenn Sie Ihren Benutzern jedoch weniger JavaScript-Aufblähung liefern und gleichzeitig die DX von etwas wie Next.js beibehalten möchten, dann könnte Astro das Richtige für Sie sein.

Astro ist auf inhaltsgesteuerte Websites ausgerichtet und bietet sofort einsatzbereite Markdown-Unterstützung. Aufgrund seines Fokus auf Inhalte ist es eine ideale Entwickler-Blogging-Plattform, um eine WordPress- oder Hugo-Site zu ersetzen. Durch Funktionen wie Aktionen ist es jedoch in der Lage, weit mehr als nur Inhaltsseiten zu erstellen.

Trotz meiner starken Abneigung gegen dateibasiertes Routing ist meine größte Sorge bei der Einführung von Astro die Möglichkeit, dass es zu bahnbrechenden Änderungen kommt, die mich dazu zwingen würden, meine Websites neu zu erstellen. JavaScript-Tools gehen bei Breaking Changes viel aggressiver vor als Tools, die Sie in anderen Sprachökosystemen finden. Da ich noch so neu bei Astro bin, weiß ich nicht, wie viel sich von einer Hauptversion zur nächsten ändert. Trotz dieser Bedenken plane ich, 5 bis 6 meiner Websites von anderen Plattformen auf Astro zu verlagern, damit ich von der erstklassigen DX profitieren und die Websites kostengünstig hosten kann.