Astro

Man kann noch nicht einmal Code oder Dokumentation für Astro (öffentlich) ansehen – es ist eine in Arbeit befindliche Idee –, aber man kann sich ein Video ansehen, in dem Fred es Feross vorstellt.

Ich muss zugeben: es sieht großartig aus. Ich bin optimistisch, was zwei Hauptaspekte davon angeht

1. Jamstack ist eine gute Idee. Das Erstellen statischer, vorgerenderter, minimaler (oder gar keiner) JavaScript-Seiten ist schlau.
2. Komponenten sind eine gute Idee. Die Erstellung von Oberflächen aus zusammensetzbaren Komponenten ist die richtige Abstraktion. JavaScript macht das derzeit am besten wegen Dingen wie ES Modules, Template Literals, Web Components, tief entwickelten Werkzeugen usw.

Ich bin auch ein Fan von Eleventy, und das fühlt sich in gewisser Weise wie Eleventy an, außer dass ich keine der Template-Sprachen so mag wie JavaScript-Komponenten.

Hier ist eine Liste einiger interessanter Aspekte

• Wie Vue `.vue`-Dateien und Svelte `.svelte`-Dateien hat, hat Astro `.astro`-Dateien in einem einzigartigen Format. Mir gefällt, wie es JavaScript-oben in einem Frontmatter-ähnlichen Format erzwingt.
• Es ersetzt keine anderen JavaScript-Bibliotheken. Es ist wie ein Site-Builder-Framework, das auf ihnen aufbaut. Sie können buchstäblich React- und JSX-Komponenten oder Vue-Dateien oder Svelte-Dateien verwenden, einschließlich der Zustandsmanagementlösungen dieser Bibliothek. Sie importieren sie in Ihre Astro-Dateien.
• Es hat das-Dateisystem-ist-der-Standard-Router, wie Next.
• Es hat standardmäßig Scoped-CSS wie Vues <style scoped>, was bedeutet, dass es nicht einmal CSS Modules benötigt, da Sie ohnehin alle Vorteile erhalten.
• Es liefert überhaupt kein JavaScript an das Frontend, es sei denn, Sie entscheiden sich ausdrücklich dafür (oder verwenden seine :visible-Syntax, die gerade genug JavaScript injiziert, um bei Bedarf mehr nachzuladen).
• Es greift die Idee der Islands Architecture auf – die Idee, dass die meisten Websites aus statischem Inhalt bestehen, mit nur wenigen Teilen interaktiver/dynamischer Inhalte.
• Die Idee, JavaScript nur für interaktive Komponenten anzufordern, wenn sie sichtbar sind (über IntersectionObserver), ist ein First-Class-Citizen des Frameworks – irgendwie wie loading="lazy" für alles Interaktive.
• Sie schreiben Marko (die Hybrid-Sprache HTML/JavaScript) direkt auf der Homepage gut (dafür, dass sie "die Frage gestellt haben"). Erinnert mich an Ansätze wie Alpine oder htmx.
• Es schleicht MDX (oder ähnliches) hinein, was bedeutet, dass Sie Inhalte in Markdown (gut) verfassen können, aber auch <Components /> hineinschleusen können (ebenfalls gut).

Mir gefällt sehr gut, dass es nicht diese ganze "Das ist etwas Neues! Du magst es! Alte Dinge sind schlecht! Neue Dinge sind gut!"-Stimmung hat. Stattdessen hat es die Stimmung "Wir werden jede letzte gute Idee stehlen, die wir von dem, was vorher kam, bekommen können, und uns auf das verlassen, was das native Web am besten kann", was mich wiederum an Baldur Bjarnasons Artikel "Welche Art von neuheitssuchendem Webentwickler bist du?" denken lässt.

Schlecht

Dies ist die erste Art von neuheitssuchendem Webentwickler. Die Art, die die Geschichte nur als eine Litanei von Fehlern betrachtet und dass neue Dinge gut sein müssen, weil sie neu sind. Warum sollte irgendjemand etwas Neues machen, wenn es keine Verbesserung des Status quo ist? Ergo, es muss eine Verbesserung des Status quo sein.

Gut

Dies ist die andere Art von neuheitssuchendem Webentwickler, einer, der versucht, auf der Geschichte und Natur des Webs aufzubauen, anstatt zu versuchen, es zu verändern.