Das No-Build-Manifest: Ausliefern ohne Bundler

Das Folgende ist kein Argument dafür, warum Sie Ihre Build-Tools aufgeben sollten. Es ist eine Messung dessen, was passiert, wenn Sie es tun.

blakecrosley.com läuft mit FastAPI + Jinja2 + HTMX + Alpine.js + reinem CSS. Kein webpack. Kein Vite. Kein Rollup. Kein TypeScript-Compiler. Kein Babel. Kein PostCSS. Kein Tailwind. Keine package.json. Kein node_modules/. Die Seite liefert 33 Blogbeiträge mit 14 interaktiven JavaScript-Komponenten, 20 Leitfäden, neun Sprachübersetzungen und erreicht 100/100/100/100 bei Lighthouse.

Zusammenfassung

Die HTMX-Community hat genug Befürwortung. Was ihr fehlt, sind Belege. Die Zahlen hier stammen von einer Produktionsseite mit umfangreichem Inhalt, interaktiven Funktionen und Internationalisierung – ganz ohne ein einziges Build-Tool. Die Kompromisse sind ehrlich, und die Schlussfolgerung ist eng gefasst: Für inhaltsorientierte Seiten mit einem Einzelentwickler oder kleinem Team lösen Build-Tools Probleme, die Sie nicht haben, während sie Probleme schaffen, die Sie haben. Für große Teams mit gemeinsamen Komponentenbibliotheken und Design-System-Paketen rechtfertigen Build-Tools ihre Komplexität. Die Grenze ist klarer, als die Diskussion vermuten lässt.

Der Stack

Backend:    FastAPI + Jinja2 (server-gerendertes HTML)
Frontend:   HTMX + Alpine.js + Bootstrap 5 (CDN)
Styles:     Reines CSS mit Custom Properties
JavaScript: Vanilla JS, IIFE-gekapselt pro Komponente
Deployment: Railway (git push → live)
CDN:        Cloudflare (Caching, Workers, D1)

Keine Transpilierung. Kein Tree Shaking. Kein Hot Module Replacement. Keine Source Maps. Das JavaScript, das Sie schreiben, ist das JavaScript, das ausgeliefert wird.

Die Zahlen

Hier sind die echten Messwerte, keine Schätzungen:

Die 18 Python-Pakete umfassen FastAPI, Jinja2, Pydantic, SQLAlchemy und 14 weitere. Keines ist ein Build-Tool. Keines ist ein Compiler. Keines ist ein Bundler.²

Was Sie aufgeben

Ehrlichkeit erfordert, die tatsächlichen Kosten aufzulisten. Sie sind real.

Kein TypeScript. Jede .js-Datei in diesem Projekt ist Vanilla JavaScript. Tests und die Analyse von Claude Code fangen Typfehler ab, nicht ein Compiler. Der Ansatz funktioniert für einen Einzelentwickler. Er würde nicht funktionieren für ein Team von 10 Personen, die Komponentenschnittstellen modulübergreifend teilen.

Kein Hot Module Replacement. Wenn ich eine CSS-Datei ändere, aktualisiere ich den Browser manuell. HTMXs hx-boost macht die Navigation schnell genug, dass vollständige Seitenaktualisierungen akzeptabel sind. Bei einem Projekt, in dem ich alle 30 Sekunden an visuellen Details iteriere, würde HMR nennenswert Zeit sparen.

Kein Tree Shaking. Jedes Byte JavaScript, das ich schreibe, wird an den Browser ausgeliefert. Ich kann keine einzelne Funktion aus einer Hilfsbibliothek importieren, ohne die gesamte Datei auszuliefern. Die Einschränkung erzwingt Disziplin: kleine, fokussierte Dateien statt großer Hilfsmodule. Die 14 interaktiven Komponenten umfassen durchschnittlich 300–700 Zeilen, weil sie eigenständig sein müssen.³

Keine Komponentenbibliothek aus npm. Kein Radix, kein shadcn/ui, kein Headless UI. Jedes interaktive Element (die Boids-Simulation, der Hamming-Code-Visualisierer, der Konsens-Simulator) ist von Hand gebaut. Der Ansatz ist nur umsetzbar, weil die interaktiven Komponenten spezifischen didaktischen Zwecken dienen, nicht generischen UI-Mustern.

Keine Design-System-Tokens aus npm. Mein Design-System lebt vollständig in CSS Custom Properties. Ich kann es nicht als Paket in ein anderes Projekt importieren. Für ein Einzelseiten-System ist die Einschränkung akzeptabel. Für eine Organisation mit mehreren Produkten ist sie es nicht.

Die fünf Kompromisse sind akzeptabel für eine inhaltsorientierte Seite mit einem Entwickler. Sie wären inakzeptabel für ein SaaS-Produkt mit einem 15-köpfigen Entwicklungsteam.

Was Sie gewinnen

Null Build-Fehler. Die Deploy-Pipeline ist git push. Kein npm install kann wegen eines Peer-Dependency-Konflikts fehlschlagen. Kein next build kann wegen eines TypeScript-Fehlers in einer Datei fehlschlagen, die ich nicht angerührt habe. Kein Dependabot-PR aktualisiert eine transitive Abhängigkeit und bricht den Build.⁴

Debuggen mit Quelltext anzeigen. Das JavaScript, das im Browser läuft, ist das JavaScript, das ich geschrieben habe. Keine Source Maps nötig. Kein Mapping von kompilierter Ausgabe zu Originalquelle. Wenn ein Bug in der Produktion auftritt, lese ich die bereitgestellte Datei direkt.

Sofortiger lokaler Start. uvicorn app.main:app --reload startet in unter 2 Sekunden. Kein npm run dev, das erst installiert, kompiliert und bündelt, bevor eine Seite angezeigt wird.

Kein Dependabot-Rauschen. Keine package-lock.json bedeutet keine wöchentlichen PRs, die semver, ansi-regex oder glob-parent aktualisieren: Pakete, die ich nie direkt importiert habe, die aber drei Ebenen tief in meinem Abhängigkeitsbaum leben.

Zukunftssicher. Die Seite wird in 10 Jahren funktionieren. Das HTML ist HTML. Das CSS ist CSS. Das JavaScript ist JavaScript. Es gibt keine Webpack 4 → 5-Migration, keine Create-React-App-Einstellung, keine Next.js-App-Router-Migration. Die Plattform ist der Standard.⁵

HTMX als Architektur

Die HTMX-Diskussion konzentriert sich auf Syntax: hx-get, hx-swap, hx-target. Das ist der falsche Rahmen. Die architektonische Erkenntnis ist, dass server-gerendertes HTML die API ist.

In einer traditionellen SPA:

Browser → fetch('/api/users') → JSON → React rendert HTML → DOM-Update

Mit HTMX:

Browser → GET /users (hx-get) → Server rendert HTML-Fragment → DOM-Austausch

Der Server liefert die finale Darstellung. Kein clientseitiges State-Management, keine Serialisierung/Deserialisierung, keine Hydration. Das Jinja2-Template ist die Komponente. Der FastAPI-Endpunkt ist die API. Eine Schicht, nicht drei.⁶

Das Muster entspricht direkt dem Compounding-Engineering-Prinzip: Jedes Infrastrukturelement tut genau eine Sache, und die Elemente lassen sich ohne Interferenzen zusammenfügen. Ein Template rendert HTML. Eine Route liefert es zurück. HTMX tauscht es ein. Kein Build-Schritt koordiniert diese Teile, weil keine Koordination nötig ist.

Reines CSS ist ausreichend

Mein Design-System verwendet 10 Farb-Tokens, 13 Typografie-Skalenstufen und acht Abstandswerte – alles CSS Custom Properties:

:root {
  --color-bg-dark:        #000000;
  --color-text-primary:   #ffffff;
  --color-text-secondary: rgba(255,255,255,0.65);
  --spacing-sm:           1rem;
  --spacing-md:           1.5rem;
  --font-size-lg:         1.25rem;
}

Kein Sass-Kompilierungsschritt. Keine Tailwind-Konfiguration, die Hilfswerkzeuge generiert. Keine PostCSS-Plugins, die benutzerdefinierte Syntax transformieren. Der Browser liest diese Werte direkt.⁷

Die Beauty-and-Brutalism-Ästhetik dieser Seite (Weiß auf absolutem Schwarz mit vier Opazitätsstufen) entsteht aus der Einschränkung. Wenn Sie nicht auf eine Farbpalette zurückgreifen können, trägt Typografie die Hierarchie. Wenn Sie nicht auf Komponentenschatten zurückgreifen können, schafft Weißraum Struktur. Die Einschränkung ist das Design.⁸

Die CLS-Reise

Die Lighthouse-Reise legte einen echten Kostenpunkt des No-Build-Ansatzes offen: Die Extraktion von kritischem CSS erforderte ein benutzerdefiniertes Python-Skript. In einem Next.js-Projekt erledigt das Framework dies automatisch.

Der konkrete Bug: Eine Mobile-Media-Query überschrieb eine CSS Custom Property (--gutter: 48px → --gutter: 24px). Das kritische CSS enthielt den Desktop-Wert, aber nicht die Mobile-Überschreibung. Auf Mobilgeräten wurde der Hero mit 48px Padding gerendert, verschob sich dann auf 24px, als das vollständige Stylesheet geladen wurde, und erzeugte einen CLS von 0,493.

Die Lösung waren 12 Zeilen Python. Die Untersuchung dauerte drei Stunden. Ein Build-Tool hätte dies automatisch gehandhabt.

Die ehrliche Bilanz: Build-Tools automatisieren Dinge, die Sie manuell erledigen können, aber die manuelle Version kostet Debugging-Zeit, wenn sie fehlschlägt. Die Frage ist, ob die Automatisierungskosten (Komplexität, Abhängigkeiten, Build-Fehler, Migrationswechsel) die manuellen Kosten (gelegentliche Debugging-Sitzungen) übersteigen.

Für diese Seite waren die manuellen Kosten geringer. Drei Jahre, ein CLS-Bug, drei Stunden Debugging. Die Alternative (eine Build-Pipeline zu pflegen) hätte kumulativ mehr Zeit durch Abhängigkeits-Updates, Breaking Changes und Konfigurationswartung verbraucht.

Wann Sie diesen Ansatz nicht verwenden sollten

Der No-Build-Ansatz ist falsch für:

Große Teams. Der Wert von TypeScript skaliert mit der Teamgröße.⁹ Wenn 10 Entwickler Komponentenschnittstellen teilen, verhindert Typprüfung zur Kompilierzeit Integrationsfehler, die Laufzeittests zu spät erkennen. Ein Einzelentwickler hat das gesamte System im Kopf. Ein Team kann das nicht.

Design-System-Pakete. Wenn mehrere Produkte Ihr Design-System nutzen, muss es ein npm-Paket mit ordentlicher Versionierung, Tree Shaking und einer Build-Pipeline sein. CSS Custom Properties in einem einzelnen Stylesheet lassen sich nicht über Repositories hinweg zusammenfügen.

Komplexer Client-State. Wenn Ihre Anwendung umfangreichen clientseitigen State hat (Drag-and-Drop-Oberflächen, Echtzeit-Zusammenarbeit, Offline-first-Daten), rechtfertigt ein Framework wie React oder Svelte seine Komplexität. HTMX ersetzt Client-State durch Server-Roundtrips, was funktioniert, bis Latenz eine Rolle spielt.

npm-Ökosystem-Bibliotheken. Wenn Sie Radix-Primitives, Framer Motion oder TanStack Query brauchen, brauchen Sie eine Build-Pipeline. Alle drei setzen einen Bundler voraus. Sie ohne einen zu verwenden, reicht von schmerzhaft bis unmöglich.

Die Grenze ist einfacher, als die Diskussion vermuten lässt: Wenn Ihre Anwendung hauptsächlich Inhalt ist, der von einem Server gerendert wird, sind Build-Tools Overhead. Wenn Ihre Anwendung hauptsächlich State ist, der von einem Client verwaltet wird, sind Build-Tools Infrastruktur.

Wichtigste Erkenntnisse

Für Einzelentwickler und kleine Teams:

• Der Beweis ist die Seite, nicht das Argument. blakecrosley.com liefert 33 Beiträge, 14 interaktive Komponenten, 20 Leitfäden und neun Sprachen mit null Build-Tools und perfekten Lighthouse-Werten. Die Zahlen sind überprüfbar.

• Die ehrlichen Kosten von No-Build sind gelegentliches Debugging. Der CLS-Bug brauchte drei Stunden zur Behebung. Ein Build-Tool hätte ihn automatisch gehandhabt. Über drei Jahre war die kumulative Debugging-Zeit weit geringer als die kumulative Wartungszeit, die eine Build-Pipeline erfordert hätte.

• Einschränkungen erzeugen Design. Keine Farben zwangen die Typografie, die Hierarchie zu tragen. Keine Build-Tools erzwangen einfaches, eigenständiges JavaScript. Die besten Einschränkungen sind die, die Sie wählen, bevor Sie sie brauchen.

Für Teamleiter bei der Bewertung von Stack-Entscheidungen:

• Build-Tools lösen Probleme auf Team-Ebene. TypeScript, Tree Shaking und Komponentenbibliotheken rechtfertigen ihre Komplexität, wenn mehrere Entwickler Schnittstellen teilen. Ein Einzelentwickler, der inhaltsorientierte Seiten baut, hat diese Probleme nicht.

• Der eigentliche Beitrag von HTMX ist architektonisch. Server-gerendertes HTML als API eliminiert Client-State-Management, Serialisierung und Hydration. Die Syntax ist zweitrangig gegenüber der Erkenntnis.

Dieser Artikel verbindet die Bereiche Design und Engineering des Blogs. Design-Entscheidungen finden sich in Beauty and Brutalism, Design Systems for Startups und Type Scales. Die technischen Messwerte stehen in Lighthouse Perfect Score und Compounding Engineering. Der Beitrag über Vibe Coding untersucht, wo diese Philosophie auf KI-gestützte Entwicklung anwendbar ist.