Ein Mittagsgespräch hat meine Website verändert

Ammar Najjar · Veröffentlicht am 19. Juli 2026 — astromigrationfrontendarchitecturestorytelling

Einige der spannendsten Projekte, an denen ich gearbeitet haben, begannen in überraschend alltäglichen Momenten. Ein Gespräch führt zu einer neuen Idee, jemand teilt eine Erfahrung aus seiner Arbeit, oder ich stoße auf einen anderen Ansatz für ein vertrautes Problem. Das Gespräch endet irgendwann, alle kehren zu ihrer täglichen Arbeit zurück, doch eine kleine Idee bleibt weiter in meinen Gedanken. In den folgenden Tagen wächst diese Idee langsam zu Dokumentation, Notizen, Experimenten und gelegentlich zu einem völlig neuen Projekt zurück. Wenn ich zurückblicke, kann ich viele meiner liebsten Lernerfahrungen genau auf solche Momente zurückführen, und der Neubau meiner persönlichen Website wurde eine weitere dieser unerwarteten Reisen.

Die Geschichte begann während einer Mittagspause mit einem meiner Kollegen Chapter Leads, während wir über Frontend-Technologien sprachen und Erfahrungen aus unseren Teams austauschten. Wie es oft passiert, wenn Ingenieure zusammen sitzen, schweifte die Diskussion natürlich zwischen Projekten, Frameworks und den verschiedenen Entscheidungen um, die wir in unserer täglichen Arbeit treffen. An einem Punkt erwähnte er, dass sein Team ihr Frontend mit Astro gebaut hatte. Ich kannte den Namen sofort, merkte aber, dass mein Wissen dort endete. Er sprach mit echter Begeisterung über das Framework, beschrieb, wie gut es zu ihrem Anwendungsfall passte und wie sehr sie dessen Performance schätzten. Wir führten unser Gespräch weiter, sprachen über verschiedene andere Themen und kehrten schließlich zur Arbeit zurück, doch Astro blieb den ganzen Nachmittag leise bei mir.

Ich habe es immer genossen, Technologien zu erkunden, die mir unbekannt sind, weil jedes ausgereifte Framework Jahre an Ingenieurserfahrung, unzählige Designentscheidungen und eine bestimmte Art repräsentiert, über Software zu denken. Dokumentation zu lesen war nie das Sammeln neuer APIs oder das Auswendiglernen von Syntax. Ich verstehe gerne, warum eine Technologie so gestaltet wurde, wie sie ist, welche Probleme sie lösen sollte und wie ihre Autoren die Kompromisse angegangen sind, die jede ingenieurtechnische Entscheidung unweigerlich mit sich bringt. Jede Erkundung erweitert meine eigene Perspektive, und das allein macht die Zeit lohnenswert.

An diesem Nachmittag öffnete ich Astros Dokumentation mit genau dieser Neugier. Innerhalb der ersten Seiten wurde ich zunehmend von der Philosophie hinter dem Framework fasziniert. Astro beginnt mit statischem HTML und führt JavaScript schrittweise dort ein, wo Interaktivität zum Erlebnis beiträgt. Die Einfachheit dieser Idee sprach mich sofort an, weil sie eine sehr bewusste Art widerspiegelt, über Websites nachzudenken. Jedes Stück JavaScript hat einen Zweck, jede interaktive Komponente verdient ihren Platz, und der Inhalt selbst bleibt im Mittelpunkt des Erlebnisses. Als ich weiter las, fand ich mich dabei wieder, wie ich über meine eigene Website und die Rolle nachdachte, die sie in den kommenden Jahren spielen sollte.

Meine Website hatte sich schritt über ihren ursprünglichen Zweck hinaus entwickelt. Sie enthielt weiterhin technische Artikel und Dokumentation, doch im Laufe der Zeit war sie zu einem Ort geworden, an dem ich Projekte sammelte, architektonische Entscheidungen dokumentierte, Experimente teilte und Ideen erkundete, die mich interessierten. In letzter Zeit war die Fotografie zu einem zunehmend wichtigen Hobby geworden, und ich hatte mir bereits eine Zukunft vorgestellt, in der größere Bilder, reichere Galerien und visuelles Storytelling natürlich Teil der Website werden würden. Diese Gedanken ließen mich meine Website aus einer anderen Perspektive betrachten. Anstatt eine Sammlung von Seiten zu sehen, begann ich über das Erlebnis nachzudenken, das ich den Lesern bieten wollte, und die Art von Grundlage, die dieses Erlebnis verdiente.

Als diese Ideen zusammenkamen, meldete sich leise eine weitere Frage. Wenn ich diese Website heute bauen würde, mit allem, was ich in den letzten Jahren gelernt habe, welche Technologien würde ich wählen? Ich suchte nicht nach einer schnellen Antwort, denn die Frage selbst wirkte weit interessanter als jedes einzelne Framework. Sie lud mich ein, Annahmen zu überprüfen, die sich im Laufe der Zeit eingestellt hatten, erneut Entscheidungen zu betrachten, die ich einst als abgeschlossen betrachtet hatte, und die gesamte Website mit frischem Blick anzugehen. Fragen wie diese haben eine bemerkenswerte Fähigkeit, ihren ursprünglichen Rahmen zu sprengen, und ich konnte bereits spüren, dass ich etwas viel Größeres beginnen würde als das Lesen der Dokumentation eines Frameworks, das ich zuvor nie benutzt hatte.

Dieser Abend markierte den Beginn einer ingenieurtechnischen Übung, die letztlich weit mehr als nur das Frontend-Framework umgestalten würde. Sie wurde zu einer Gelegenheit, die Architektur der Website, den Veröffentlichungsworkflow, die dahinterstehenden Technologien und vielleicht am wichtigsten den Zweck der Website selbst zu überdenken. Zu diesem Zeitpunkt hatte ich immer noch keine Ahnung, wohin die Reise führen würde, doch ich genoss bereits den Prozess, denn Neugier hat eine wunderbare Angewohnheit, eine einfache Frage in eine Gelegenheit zu verwandeln, etwas völlig Unerwartetes zu lernen.

Neugier hat die Angewohnheit zu wachsen

Die Frage, die ich mir gestellt hatte, erschien zunächst wunderbar einfach. Wenn ich diese Website heute bauen würde, würde ich die gleichen Technologieentscheidungen treffen? Ich erwartete, dass die Antwort nach dem Vergleich einiger Frameworks, dem Lesen einiger Dokumentation und vielleicht dem Bau eines kleinen Prototyps entstand. Stattdessen erweiterte sich diese eine Frage langsam in etwas viel Größeres, weil jede Antwort natürlich zu einer weiteren Frage führte und jede Frage mich ermutigte, die Website aus einer leicht anderen Perspektive zu betrachten. Als ich meine anfängliche Recherche abgeschlossen hatte, bewertete ich kein Framework mehr. Ich bewertete die Website selbst, die Art, wie sie sich im Laufe der Jahre entwickelt hatte, und die Richtung, die ich ihr für die Zukunft geben wollte.

In den folgenden Abenden tauchte ich in Dokumentation, technische Artikel, Konferenzvorträge und Community-Diskussionen ein und baute allmählich ein Bild der verschiedenen Philosophien hinter den Frameworks auf, die ich verstehen wollte. Astro blieb im Mittelpunkt dieser Erkundung, doch es wurde zu einer Stimme unter vielen. Hugo zog meine Aufmerksamkeit schnell mit seiner Reife, bemerkenswerten Performance und eleganten Einfachheit. Docusaurus blieb ein wichtiger Referenzpunkt, weil ich seine Stärken aus mehreren Jahren der Nutzung bereits kannte. Ich überarbeitete auch Angular und React, teilweise weil sie einflussreiche Ansätze der Frontend-Entwicklung repräsentieren und teilweise weil das Verständnis, wo jedes Framework glänzt, es viel leichter macht, die Designentscheidungen der anderen zu schätzen.

Was mich während des gesamten Prozesses faszinierte, war nicht die Entdeckung, welches Framework die längste Funktion bot oder den schnellsten Benchmark lieferte. Diese Zahlen haben durchaus ihren Platz, doch ich genoss eine andere Art des Vergleichs. Meine Notizen wurden allmählich zu einer Sammlung architektonischer Beobachtungen. Ich erforschte Renderstrategien, Markdown-Workflows, Bildoptimierung, Routing, Bereitstellungsmodelle, Erweiterbarkeit, Inhaltsverwaltung, Entwicklererfahrung und langfristige Wartbarkeit und fragte mich stets, wie jede Entscheidung das Erlebnis des Schreibens und Lesens in den kommenden Jahren beeinflussen würde. Irgendwann fiel mir auf, dass meine Notizen weniger Frameworknamen und viele mehr Fragen über die Website selbst enthielten, und dieser Perspektivwechsel stellte sich als eines der wertvollsten Ergebnisse der gesamten Übung heraus.

Die Website, die ich ursprünglich gebaut hatte, spiegelte ein anderes Stadium meiner Reise wider. Sie stellte meine berufliche Erfahrung vor, präsentierte ausgewählte Projekte und bot einen Ort, an dem ich gelegentlich technische Artikel veröffentlichen konnte. Im Laufe der Zeit, ohne bewussten Plan, wuchs die Website leise zu etwas weit Persönlicherem. Ich begann längere Reflexionen zu schreiben, architektonische Entscheidungen zu dokumentieren, Experimente zu veröffentlichen, Lesenotizen zu sammeln und Ideen zu teilen, die mich interessierten, lange bevor ich darüber nachdachte, ob sie in ein traditionelles Portfolio gehören. Gleichzeitig kehrte die Fotografie allmählich als wichtiges Hobby zurück, und ich konnte mir bereits eine Zukunft vorstellen, in der Fotos, visuelle Geschichten und Galerien natürlich ein weiterer Teil der Website würden. Als ich sie durch diese Linse betrachtete, erkannte ich, dass ich keine Visitenkarte mehr entwarf. Ich baute einen Ort, der meine Neugier widerspiegelte.

Diese Erkenntnis beeinflusste leise fast jede Entscheidung, die folgte. Astro fühlte sich stets mit der Art von Erlebnis vereinbart, das ich schaffen wollte, weil seine Inhalt-erst-Philosophie genau die Qualitäten förderte, die ich am meisten schätzte. Statisches HTML, responsive Bilder, selektives JavaScript, ausgezeichnete Markdown-Unterstützung und die Flexibilität, interaktive Komponenten nur dort einzuführen, wo sie das Erlebnis tatsächlich bereichern, trugen allesamt zu einer Architektur bei, die sich einfach und zukunftsorientiert anfühlte. Das Framework selbst wurde weniger wichtig als das Vertrauen, dass es sich über viele Jahre hinweg zusammen mit der Website bequem weiterentwickeln konnte, ohne unnötige Komplexität zu fördern.

Als ich mich für die Migration entschied, wurde mir schnell klar, dass der Austausch des Frameworks sowieso fast jeden Teil des Projekts betreffen würde. Das schuf natürlich eine Gelegenheit, unzählige Entscheidungen zu überdenken, die sich im Laufe der Jahre leise angesammelt hatten, und jede Verbesserung, die ich vornahm, schien eine weitere lohnenswerte zu offenbaren. Anstatt mich auf die Migration selbst zu beschränken, beschloss ich, das Projekt als eine vollständige Modernisierung der Website zu betrachten und jeden Aspekt zu verbessern, der die Standards nicht mehr widerspiegelte, die ich für die Seite wollte.

Als ich fertig war, war die Migration zu einer viel umfassenderen Transformation gewachsen:

• Migration der Website von Docusaurus zu Astro.
• Wechsel des Entwicklungsworkflows von npm zu Bun.
• Neugestaltung der Startseite als persönliche Website statt eines traditionellen Lebenslaufs.
• Auffrischung des visuellen Designs mit verbesserter Typografie, Abständen und Responsivität.
• Umstrukturierung der Inhaltsstruktur, um Artikel und Projekte leichter auffindbar zu machen.
• Optimierung jedes Bildes und automatische Generierung responsiver Bildvarianten.
• Reduzierung der JavaScript-Auslieferung und erhebliche Verringerung der Gesamtpaketgröße.
• Verbesserung der Ladeleistung und Core Web Vitals auf der gesamten Website.
• Ergänzung von Deutsch und Arabsch neben Englisch, wobei jede Sprache natürlich für ihr Publikum geschrieben wurde statt wörtliche Satz-für-Satz-Übersetzungen zu folgen.
• Verbesserung der Auffindbarkeit durch bessere Metadaten, strukturierte Daten, Sitemaps, kanonische URLs, robots.txt und KI-orientierte Dateien wie llms.txt.
• Verfeinerung des Veröffentlichungsworkflows gemeinsam mit GitHub und Cloudflare zur Vereinfachung von Bereitstellungen und globalem Content-Delivery.
• Überprüfung Dutzender kleiner Details, die sich über die Lebenszeit des Projekts leise angesammelt hatten und ihnen endlich die Aufmerksamkeit schenkten, die sie verdienten.

Wenn ich auf diese Liste zurückblicke, finde ich es interessant, wie wenig davon in der ursprünglichen Idee erschien. Meine Neugier hatte mit einem einzelnen Framework begonnen, doch jede Verbesserung offenberte natürlich eine weitere Gelegenheit, die Website ein wenig besser zu machen, ähnlich wie der Kompounding-Effekt, den James Clear in Atomic Habits beschreibt. Bildoptimierung ermutigte mich, die Performance zu überdenken, verbesserte Performance führte mich dazu, den Veröffentlichungsworkflow neu zu denken, Umstrukturierung der Inhalte inspirierte eine persönlichere Startseite und die Einführung mehrerer Sprachen ermutigte mich, sorgfältiger über die Leser nachzudenken, die ich erreichen wollte. Die Migration hörte allmählich auf, sich wie eine Reihe unabhängiger Aufgaben anzufühlen, und wurde zu einer einzigen ingenieurtechnischen Übung, bei der jede Entscheidung die nächste stärkte.

Als ich die neue Version veröffentlichte, war Astro nur ein Kapitel einer viel größeren Geschichte geworden. Das eigentliche Ergebnis war eine Website, die sich kohärenter, persönlicher und viel näher an der Vision anfühlte, die sich über die Jahre leise entwickelt hatte. Wenn ich jetzt zurückblicke, schätze ich die Migration, weil sie mir die Gelegenheit gab, innezuhalten, Annahmen zu überdenken und bewusst das nächste Kapitel der Website zu gestalten, anstatt einfach den Pfad fortzusetzen, den sie bereits eingeschlagen hatte.

Infrastruktur festigen

Die Framework-Migration warf natürlich Fragen nach Hosting und Bereitstellung auf. Der Wechsel von Docusaurus zu Astro bedeutete, die gesamte Deployment-Pipeline neu zu denken. Ein separater Artikel behandelt, wie das Hosting von GitHub Pages zu Cloudflare gewechselt ist, den Vergleich der Domain-Registrar, die Stolpersteine bei der Paketmanager-Erkennung und der Docusaurus-URL-Konfiguration und die beteiligten Schritte. Zusammen mit dem Framework-Wechsel vollendete diese Migration die Modernisierung der Infrastruktur, die diese Website nun antreibt. Die vollständige technische Architektur, Content-Collection, Bildbehandlung, SEO-Setup und der Bereitstellungsworkflow sind im Begleitartikel beschrieben.

Mehr als ein Framework

Wenn ich die Website heute betrachte, fällt es mir schwer, dieses Projekt als eine Framework-Migration zu betrachten. Astro wurde sicherlich ein wichtiger Teil der Geschichte, doch das Framework schwand allmählich in den Hintergrund, wie sich das Projekt weiterentwickelte. Was viel sichtbarer bleibt, ist die Website selbst, das Gefühl sie zu nutzen, wie sie meine Interessen widerspiegelt und wie sie die Art von Inhalt unterstützt, die ich in den kommenden Jahren erstellen möchte. Die Migration schuf einfach die Gelegenheit, innezuhalten, Jahre an angesammelten Entscheidungen zu überdenken und bewusst das nächste Kapitel zu gestalten, anstatt weiter auf Entscheidungen aufzubauen, die ich vor mehreren Jahren getroffen hatte.

Vielleicht ist das das, was ich an Projekten wie diesem am meisten schätze. Sie schaffen Raum, über die unmittelbare technische Entscheidung hinauszudenken und breitere Fragen über Zweck, Richtung und Erlebnis zu stellen. Jede Verbesserung wurde Teil derselben Vision, und zusammen verwandelten sie viel mehr als die Technologie hinter der Website.

Heute spiegelt sich diese Vision in mehreren wider:

• Eine persönliche Website statt eines digitalen Lebenslaufs: wo Artikel, Projekte und Ideen meine Geschichte besser erzählen als ein traditioneller Lebenslauf jemals könnte.
• Ein inhaltserstes Erlebnis: wo Performance, responsive Bilder und leichtgewichtige Seiten den Lesern helfen, sich auf das zu konzentrieren, wegen dessen sie kamen.
• Ein Veröffentlichungsworkflow, der auf Einfachheit gebaut ist: der es mir erlaubt, in Markdown zu schreiben, während GitHub und Cloudflare sich um alles Weitere kümmern.
• Inhalte, die sich in mehreren Sprachen natürlich anfühlen: wobei jede Locale für ihr Publikum geschrieben wurde statt mechanisch übersetzt.
• Eine Grundlage, die auf kontinuierliche Entwicklung ausgelegt ist: die Raum für Fotografie, reicheres visuelles Storytelling und welche Ideen auch immer als Nächstes entstehen lässt.

Wenn ich auf diese Liste blicke, erkenne ich, dass keines dieser Ergebnisse im ursprünglichen Plan erschien. Sie entstanden allmählich, als eine Verbesserung die nächste inspirierte, und dieser Fortschritt lehrte mich etwas, das ich in meiner Karriere viele Male erlebt habe. Gute Technik entsteht selten durch die Suche nach einer perfekten Lösung. Sie wächst durch Erkundung, durchdachte Bewertung und die Bereitschaft, Entscheidungen zu überdenken, die bereits vollkommen vernünftig erscheinen. Jede Frage öffnet die Tür zu einer weiteren, und jede Antwort vertieft unser Verständnis des Systems, das wir aufbauen.

Ein Gedanke begleitet mich, seit ich die Migration abgeschlossen habe. Astro fühlt sich heute wie die richtige Wahl für meine Website an, weil es mit der Richtung übereinstimmt, die ich jetzt einschlagen möchte. In fünf Jahren könnte ein anderes Gespräch, ein anderer Artikel oder ein anderes Framework mich ermutigen, dasselbe Problem aus einer völlig anderen Perspektive zu betrachten, und ich hoffe aufrichtig, dass das passiert. Ich strebe nicht danach, eine Technologie zu finden, die für immer unverändert bleibt. Ich hoffe, neugierig genug zu bleiben, um weiter zu lernen, meine eigenen Annahmen zu hinterfragen und diese Website zu verbessern, wenn sich eine bessere Idee bietet. Auf vielerlei Weise fühlt sich diese anhaltende Weiterentwicklung viel wichtiger an als der Name des Frameworks, das sie antreibt.

Wenn dieser Artikel die Geschichte darüber erzählt, warum sich die Website veränderte, erzählt ein anderer Artikel die Geschichte darüber, wie sie funktioniert. Die Migration führte letztlich zu einem Veröffentlichungsworkflow, der auf Astro, GitHub und Cloudflare aufgebaut war, und diese Architektur wurde zu einem ebenso genussvollen ingenieurtechnischen Projekt. Wenn Sie an den technischen Entscheidungen hinter dem Stack, dem Bereitstellungsworkflow und der Infrastruktur interessiert sind, die diese Website antreibt, finden Sie diese Geschichte in meinem Begleitartikel.