Über diesen Blog habe ich zwei Jahre lang nachgedacht
"Gewollt" trifft es nicht ganz, es war eher eine fixe Idee. Sie war schon da, als ich weder Frontend noch Backend schreiben konnte und auch keinen Embedded-Code. Damals bastelte ich noch an Elektronik herum, und zufällig stieß ich auf die Videos von @ushio auf und auf ihre Website, und fand das so toll, dass ich das auch haben wollte. Danach brauchte ich ein knappes halbes Jahr, lernte C von Grund auf, dazu ein bisschen JS und CSS, baute mit Hexo einen statischen Blog und stellte ihn auf Github Pages — damit hatte ich endlich mein eigenes kleines Fleckchen.
Später stieß ich auf die persönliche Website von @Innei. Sie war sehr elegant gestaltet und bot jede Menge Funktionen; ein einziger Blick genügte, und ich wollte sie haben. Ich unterstützte das Projekt sogar finanziell. Zwar kam sie später doch nicht zum Einsatz, aber das Geld war nicht umsonst ausgegeben, denn so bekam ich den React-Quellcode in die Hände. Es war wie damals, als ich zum ersten Mal C sah: Es ist doch nur Code – was soll daran so schwierig sein? Eines Tages werde ich selbst so etwas schreiben.
Das war 2024, und dann kamen 24, 25 und 26, bis wir beim Heute angelangt waren
Seitdem gibt es kein Halten mehr.
Außer Kontrolle
Angefangen hat es damit, dass ich dem Hexo-Theme Nlvi von @colmugx bloß eine Hell-Dunkel-Umschaltung verpassen wollte. Ich habe mir eine aus dem JS von Dark Reader zusammengeschustert -- hässlich, damit war ich nicht zufrieden. Dann lernte ich CSS @media, danach das Umschalten per JS im SPA, dann die .dark class von TailwindCSS, dann next-theme im SSR, und am Ende habe ich ein Cookie samt Head-Sync-Inline-Skript , um das FOUC-Flackern loszuwerden. Vier oder fünf Ansätze waren es am Ende.
Doch das war nur die Spitze des Eisbergs. Nachdem ich React entdeckt hatte, arbeitete ich mich von der Steinzeit mit Hexo und reinem JavaScript bis zum Seitenrouter von Next.js 13 vor, machte dann einen Abstecher zu Vue, beschäftigte mich mit der Routensteuerung von Einzelseitenanwendungen, verstand schließlich den Rückfall auf index.html und setzte das Projekt unzählige Male neu auf. Ich kaufte einen Server und experimentierte mit Docker, Nginx und einem netzgebundenen Speichersystem; weil ich 1Panel hässlich fand, schrieb ich kurzerhand das Canopy-Bedienfeld selbst, erforschte Speicherverbünde und entwickelte RFS, und als mich bei der Einrichtung von SSL-Zertifikaten das im chinesischen Umfeld ständig streikende acme.sh zur Verzweiflung brachte, schrieb ich in Rust einen Reverse-Proxy namens Vane & Lazyacme. Ursprünglich waren das nur achthundert Zeilen Schrott, die ich an einem Abend in drei Stunden hingehackt hatte, doch nachdem mich ein paar Leute aus der Chatgruppe angestachelt hatten, arbeitete ich vier Monate daran und stopfte HTTP/3, kopierfreie Verarbeitung, ein Schichtenmodell und eine Fluss-Engine hinein. Danach kam noch Seam, ein Full-Stack-Framework und ebenfalls ein bodenloses Fass – aber davon ein andermal.
Überentwicklung
Dann begann das KI-Zeitalter, und meine Ängste verdoppelten sich erneut.
Das Ironischste daran ist, dass all diese Dinge eigentlich erst nach dem Blog entstehen sollten, dokumentiert, während ich sie baue. Stattdessen wurde der Blog , die Ideen wurden immer mehr, und es gab keinen einzigen Ort, an dem ich sie hätte festhalten können. Auf der einen Seite klagte mich mein Inneres an: Du hast gesagt, Vane wird fertig, also darfst du jetzt nicht aufhören. Auf der anderen Seite eine Ohnmacht, die mit jedem Schritt größer wurde, weil ich mich immer weiter entfernte. Ich wusste die ganze Zeit, was ich tun wollte, ich brachte es nur nicht zustande. Wenn ich genauer darüber nachdenke, habe ich schon sehr lange nicht mehr dagesessen und irgendetwas geschrieben. Im Rückblick zeigt das alles auf dasselbe -- auf Overengineering.
Damals war es eigentlich nicht so, dass ich nicht gemerkt hätte, wie ich vom Weg abkam. Vane? Der Blog musste schließlich irgendwann bereitgestellt werden, also brauchte ich doch ohnehin einen Reverse-Proxy. Seam? Früher oder später würde ich sowieso Full-Stack-Code schreiben, also konnte ich auch zuerst mein ideales Framework bauen. Jeder Schritt hatte seine Begründung, und alles würde ich „später noch brauchen“. Das Problem war nur: Dieses „später“ würde niemals kommen, weil ich nie angefangen hatte ...
Scheitern
Für einen Blog braucht man eigentlich weder einen Reverse-Proxy noch ein selbst entwickeltes Framework. Damals hielt ich beides jedoch für Voraussetzungen und machte es zu einer scheinbar vernünftigen Begründung, die mich auf Dauer vom Anfangen abhielt. Dabei waren diese Dinge nie Voraussetzungen. Die einzige wirkliche Voraussetzung war: mich hinzusetzen und den ersten Artikel zu schreiben.
Tatsächlich war es nicht so, dass ich nie an dem Blog gearbeitet hätte. Ganz im Gegenteil: Ich habe es dreimal versucht.
Mein erster Versuch fiel noch in die Zeit des Page Router von Next.js 13. Damals hatte ich nur eine vage Vorstellung davon, was eine Single-Page-Anwendung ist, und verstand kein einziges der Konzepte SSR, SSG und ISR. Aber andere sagten, SSR sei gut, also wollte ich es ebenfalls verwenden. Während der Entwicklung stellte ich jedoch fest, dass ich überhaupt nicht verstand, welche Probleme diese Architekturen lösen sollten, und kam nicht mehr weiter. Später wechselte ich zu einer reinen Single-Page-Anwendung mit Vue 2. Warum Vue? Ehrlich gesagt ist es mir peinlich: Mir gefiel einfach der Name, und da es für mich ohnehin neu war, wollte ich es ausprobieren. Auch damit hielt ich nicht lange durch. Beim dritten Versuch kehrte ich zu React zurück und begann mit einfachem JSX. Ich lernte TypeScript, beherrschte TSX, verstand den Unterschied zwischen CJS und ESM, verliebte mich in reaktive Programmierung und setzte Bibliotheken wie Lucide, Framer Motion und Radix UI ein, auf die ich später nicht mehr verzichten konnte – diesmal nahm das Ganze endlich Gestalt an. Trotzdem scheiterte ich erneut, denn im Grunde ahmte ich nur andere nach: Was sie verwendeten, übernahm ich ebenfalls. Es sah überzeugend aus, aber tatsächlich verstand ich überhaupt nicht, warum man es so machen sollte. Mit den Halluzinationen der KI als zusätzlichem Anschub ließ sich zwar vieles als minimal funktionsfähiges Produkt zum Laufen bringen, doch beim Hochskalieren lauerte überall eine Falle.
Später lernte ich noch die Loader von React (Remix) Router, den App Router von Next.js 15 und RSC kennen, doch zu diesem Zeitpunkt war mein Alltag bereits so voll, dass ich kaum noch Zeit zum Programmieren hatte – und damit auch keine Gelegenheit, ein viertes Mal zu scheitern. Rückblickend habe ich meine Website von Next.js 13 bis Next.js 15 weiterentwickelt; kaum war die Migration abgeschlossen und noch bevor sie online ging, erschien bereits Next.js 16 beta 1.
Lass los
Zu sagen, ich hätte „losgelassen“, trifft es nicht ganz – ich war einfach müde.
Das Tempo der KI-Ära ist zu hoch. Modelle folgen einander in immer neuen Iterationen, neue Techniken tauchen Welle um Welle auf, und ich wurde immer nervöser, als würde ich überholt, sobald ich stehen bleibe. In der wildesten Zeit habe ich sechzehn Stunden am Tag Code geschrieben und konnte an einem Tag $1.9k USD an Token verfeuern (ungefähr im Februar, glaube ich); ich war fast am Ende. Aber was das alles gestoppt hat, war keine Erleuchtung, sondern schlicht Erschöpfung. Unter einem Takt, der immer enger wurde, fiel der letzte Tropfen, und gerade da wurde ich ruhig, ließ ich los, ; und so ist es auch ganz gut.
Ich begann loszulassen. Ich gab auf, woran ich früher verbissen festgehalten hatte, lernte, es gut sein zu lassen, und verschob die Sorgen von morgen auf morgen. Vane ist nicht fertig? Erst einmal liegen lassen. Seam ist noch lange nicht so weit? Später weitermachen. Der Blog ist nicht perfekt? Erst einmal veröffentlichen. Ich stieg vollständig auf Vibe Coding um: Solange es keine Probleme gibt, lasse ich alles in Ruhe; wenn welche auftreten, kümmere ich mich dann darum.
Das Seltsame ist: Nachdem ich losgelassen hatte, wurde die Qualität nicht schlechter. Ich glaube, das liegt daran, dass die Zeit des nicht umsonst war. Schon zu GPT-2-Zeiten habe ich KI benutzt, aber damals schrieb ich noch brav jede einzelne Zeile Code und verstand jedes einzelne Konzept. Diese Zeit hat mir das Fundament gegeben. Was danach kam, war weniger Vibe Coding als Context Coding — das nötige Urteilsvermögen war noch da, und das Loslassen hat weder zu dummen Fehlern noch zu Unfällen geführt.
All die früheren Experimente haben mir die Grundlage gegeben, jetzt loszulassen.
Ausgangspunkt
Die endgültige Lösung war überraschend einfach: alles auf Cloudflare. R2 als Objektspeicher, D1 als Edge-Datenbank, KV als Cache und Worker für serverseitiges Rendering – alles serverlos, ganz ohne Server.
Ist diese Antwort ironisch? Und wie. Denn bevor ich dieses „einfache“ Ziel erreichte, nahm ich einen gewaltigen Umweg. Ich hatte einmal vor, alles selbst zu hosten, musste dafür aber einen Server verwalten, mich mit Docker herumschlagen und Container betreuen. Also schrieb ich Canopy als Verwaltungsoberfläche, Lazycert zur Zertifikatsverwaltung, Vane als Reverse-Proxy und Twig zur Instrumentierung der Ressourcenüberwachung. Ein ganzer Haufen Projekte, nur um einen einzigen Schrottserver zu bedienen.
Beim Speicher war es genauso. Objektspeicher war mir zu teuer, und ich wollte die Festplatte meines eigenen Servers nutzen. Also schrieb ich RFS, ein VFS, das Daten atomar deduplizierte und in einer einzigen Datei zusammenführte. Ich belebte sogar das Registry-Konzept der 1980er- und 1990er-Jahre wieder und band das Ganze schließlich über FUSE ein. Das Ergebnis? Ich verbrachte noch mehr Zeit damit, ein schlechteres Rad neu zu erfinden, während der Server ein Jahr lang ungenutzt lief – ein durch und durch verlustreiches Geschäft.
Nach einem großen Umweg bin ich am Ende doch wieder beim Serverless-Computing gelandet. Das Konzept von Vercel ist gut, aber Next.js gefällt mir nicht; außerdem steckt bei Vercel zu viel Magie dahinter. Auch das Middleware-Design, bei dem sie vorkompiliert und am Edge ausgeführt wird, führt letztlich zu einer fragmentierten Architektur und hat sogar mehrere CVEs hervorgebracht. Dann kann man gleich alles gemeinsam auf dem Ursprungsserver ausführen. Cloudflare Workers hingegen ist hervorragend und treibt das Ganze in ein anderes Extrem: Artefakte unter 10 MB werden zu WASM kompiliert, sodass echte Geschäftslogik am Edge laufen kann. Genau das will ich. Der einzige Nachteil sind die Kosten – aber eigentlich ist selbst das keiner, denn gesparte Zeit ist Geld.
Weniger ist mehr
Diesen Satz hatte ich unzählige Male gehört, doch es dauerte zwei Jahre, bis ich seine Bedeutung wirklich verstand.
Zurück zum Wesentlichen des Engineerings: „Make it function, make it correct, then make it exceptional.“ Endlich war ich auf dem richtigen Weg und hatte es zum Laufen gebracht. Ist der Blog gerade rudimentär? Ist er. Unvollständig? Definitiv. Aber immer noch besser als gar nichts. Wenn du noch nicht einmal etwas online gestellt hast, ständig an dem arbeitest, was du „vielleicht brauchst“, und einer unsichtbaren Perfektion hinterherjagst, wirst du am Ende gar nichts vorweisen können. Das ist kein Kompromiss, sondern eine Abwägung aus Sicht des Engineerings. Jedenfalls habe ich gelernt, loszulassen. Also ließ ich los. Als ich aufhörte, mich an einem einzigen Detail festzubeißen, ging ich stattdessen tatsächlich vor die Tür. In meinen Handyfotos gab es schon ewig keine Aufnahmen von draußen mehr, also machte ich einen schnellen Schnappschuss am Straßenrand — ich war schließlich schon lange nicht mehr draußen gewesen (
Bereue ich die Umwege, die ich früher gegangen bin, wenn ich heute darauf zurückblicke? Nein. Manche Dinge versteht man vielleicht nie, wenn man sie nicht selbst ausprobiert. Außerdem ist es im KI-Zeitalter praktisch unmöglich geworden, denselben alten Weg zu gehen wie ich damals; zu viele Arbeitsabläufe haben sich bereits verändert. Dann ist da noch dieses Projekt: Taki, vollständig mit KI programmiert. Das bedeutet jedoch weder, dass es sich nicht langfristig warten lässt, noch, dass ihm die menschliche Note fehlt. Eigentlich spielt es keine Rolle, ob KI beteiligt war. Mir gefällt schließlich nicht das Programmieren an sich, sondern etwas zu erschaffen ...