Vortrag in Köln beim CologneJS Meetup

Am 2. November 2021 stand ich auf der Bühne des CologneJS Meetups in Köln und präsentierte eine Frage, die eigentlich eine Provokation war:

“Petite-Vue, das kleinere und bessere Alternative zu Vue.js & Alpine.js?”

Es war eine Frage, die ich selbst lange nicht gestellt hatte. Ich war Teil einer Industrie, die immer größer dachte, immer komplexer baute, immer mehr JavaScript in den Browser lud. Und eines Tages, während ich an einem Projekt arbeitete, merkte ich: Das stimmt nicht.

Der Vortrag war nicht primär eine technische Präsentation über ein neues Framework. Es war eine Anklagerede gegen das unkritische Überengineering, das ich selbst täglich praktizierte. Und es war ein Versuch, die Idee von Progressive Enhancement aus der Vergangenheit wieder lebendig zu machen.

Die Lüge der Single Page Application

Wir hatten uns selbst belogen. Die ganze Industrie hatte sich in eine Vorstellung verrannt, die uns besänftigt hatte: Um eine moderne Website zu bauen, brauchst du ein großes Framework. React, Vue, Angular. Die Webseite lädt blank, bis das ganze JavaScript heruntergeladen ist, dann wird sie vom Browser neu erfunden. Das war normal geworden. Das war der Standard.

Aber Standard bedeutet nicht richtig.

Parallel dazu gewöhnte sich die Industrie an größere Bundle-Größen an. 64 KB für Vue, 121 KB für React, gzipped. Jedes Byte ein Versprechen, dass die Komplexität, die wir bauen, wirklich nötig ist. Und dann stellte sich die Frage, die ich immer wieder verdrängte: Warum?

Warum brauchte jede Website diese Komplexität? Warum konnten wir nicht einfach HTML schreiben, das vom Server kommt, und nur dort, wo es sinnvoll ist, Interaktivität hinzufügen? Die Antwort war immer die gleiche: “Weil alle es so machen.”

Das ist keine Antwort. Das ist eine Ausrede.

Progressive Enhancement ist eine Philosophie, nicht nur eine Technik. Sie besagt: Der Inhalt kommt zuerst. Der HTML-Server liefert dem Nutzer sofort etwas zum Lesen, zum Interagieren. Der Schmuck, die Verbesserungen, die kommen danach. Die Webseite funktioniert ohne JavaScript, und mit JavaScript wird sie besser. Nicht umgekehrt.

Für Jahre war diese Philosophie aus der Mode gekommen. Und ich war mitverantwortlich dafür, dass sie vergessen wurde.

Petite-Vue, Das Werkzeug der Ehrlichkeit

Dann kam Evan You mit Petite-Vue. Ein Framework, das 6 Kilobyte groß ist, gzipped. Das ist ein Zehntel von Vue, ein Zwanzigstel von React.

Aber es geht nicht primär um die Größe. Es geht um die Philosophie, die hinter diesem Framework steckt.

  1. Kein Virtual DOM: Petite-Vue mutiert den bestehenden DOM direkt. Das klingt technisch simpel, aber es bedeutet etwas Fundamentales: Der DOM wird zur Template, nicht umgekehrt. Die Wahrheit ist das HTML, nicht das JavaScript. Das JavaScript schmückt die Wahrheit aus.

  2. Kein Build-Schritt: Du brauchst keine CLI, keine Webpack-Konfiguration, keine Single-File-Components, wenn du sie nicht brauchst. Du linkst eine Datei ein, und fertig. Das ist radikal ehrlich. Es sagt: Du brauchst diese Komplexität nicht, es sei denn, du brauchst sie wirklich.

  3. Reaktivität ohne Overkill: Mit reactive() kannst du State teilen, ohne eine zusätzliche State-Management-Library laden zu müssen. Der Code ist klein genug, dass er direkt im Framework drin steckt.

  4. Lokale Scope mit v-scope: Du kannst ein Element mit v-scope annotieren, und Petite-Vue aktiviert sich nur dort. Das ist Progressive Enhancement im Reinkultur. Der Rest der Seite funktioniert normal, ein Element kriegt Superkräfte.

Das ist das technische Gerüst, auf dem ich meinen Vortrag aufbaute. Aber die Emotionale Wahrheit dahinter war anders.

Die Größenwahrheit

Während meines Vortrags zeigte ich die Zahlen nebeneinander:

Petite-Vue: 6 KB gzipped. Vue: 64 KB gzipped. React: 121 KB gzipped. Alpine.js: 15 KB gzipped.

Jeder zusätzliche Kilobyte bedeutet: Längere Ladezeit. Längere Parse-Zeit. Längere Execution-Zeit im Browser. Und für viele Nutzer auf langsamen Verbindungen bedeutet das: Warten. Lange warten.

Die Industrie hatte das Konzept von “Performance Budget” aus den Augen verloren. Oder sie hatte nie wirklich hingeschaut. Es war zu einfach, das Framework zu nehmen, das alle nehmen. Es war zu einfach, nicht zu fragen: Brauch ich das wirklich?

Ich war schuldig. Jahre lang war ich schuldig daran, diese Fragen nicht zu stellen.

Die Illusion der Kontrolle

Was mich am meisten bei diesem Vortrag beschäftigte, war eine tiefere Einsicht: Wir bauten große SPAs, nicht weil sie besser waren, sondern weil sie uns das Gefühl gaben, die Kontrolle zu haben.

Mit Vue oder React kontrollierst du den gesamten Rendering-Prozess. Du definierst, wie und wann der DOM sich verändert. Das ist beruhigend für Entwickler. Es fühlt sich sicher an. Es ist nicht sicher, aber es fühlt sich so an.

Mit Progressive Enhancement gibst du diese Illusion auf. Der Server liefert HTML. Der Browser nutzt HTML. Das ist einfach, aber es bedeutet auch Verantwortung. Du musst Fallbacks bauen. Du musst testen, dass es auch ohne JavaScript funktioniert. Das ist anstrengender. Das ist unbequemer.

Aber es ist ehrlicher.

Die Zukunft, Die Ich Erhoffte

Mit meinem Vortrag in Köln verfolgte ich eine kleine, vielleicht naive Hoffnung: Dass Entwickler anfangen würden, kritischer zu fragen. Dass sie die großen Frameworks nicht mehr als Standardwerkzeug nehmen würden, sondern als bewusste Entscheidung.

Petite-Vue war nicht das Ziel. Petite-Vue war ein Symbol. Ein Symbol dafür, dass es anders geht. Dass du nicht immer jeden Satz mit einem Build-Tool kompilieren musst. Dass du nicht immer eine ganze State-Management-Bibliothek laden musst, nur um ein paar Buttons interaktiv zu machen.

In den Jahren nach diesem Vortrag sah ich, dass diese Hoffnung langsam, sehr langsam, Form annahm. Island Architecture, Partial Hydration, Astro, Qwik, andere Frameworks, die sich wieder auf Progressive Enhancement besinnen. Die Industrie beginnt, die Fragen zu stellen, die ich damals auf der Bühne stellte.

Das macht mich hoffnungsvoll.

Progressive Enhancement Ist Nicht Rückwärts

Das Wichtigste, das ich in meinem Vortrag vermitteln wollte, war dieses: Progressive Enhancement ist nicht rückwärts. Es ist nicht die Vergangenheit, die wir wieder aufbauen. Es ist eine intelligente Zukunft, die wir verdrängt haben.

Mit Progressive Enhancement sagst du:

  1. Inhalt ist König: HTML vom Server, sofort verfügbar.
  2. Interaktivität ist optional: JavaScript macht es besser, nicht möglich.
  3. Performance ist Ethik: Kleiner Bundle bedeutet schneller für alle, besonders für die Langsamen.
  4. Wartbarkeit ist Sanftheit: Kleiner Code ist leichter zu verstehen, zu testen, zu ändern.

Diese Prinzipien waren nicht neu. Sie sind alt wie das Web selbst. Aber sie waren vergessen.

Und ich war mitverantwortlich für dieses Vergessen.

Die Kleine Rebellion

Was mein Vortrag letztlich war, war ein winziger Akt der Rebellion. Nicht gegen Framework. Nicht gegen Fortschritt. Sondern gegen die Passivität, gegen die unkritische Übernahme von Komplexität ohne Fragen.

Wir als Entwickler haben die Macht, diese Entscheidungen zu treffen. Wir könnten nein sagen. Wir könnten sagen: Das Feature braucht kein ganzes Framework. Diese Seite braucht kein SPA. Diese Interaktion kann mit 6 Kilobyte gelöst werden statt mit 121.

Es ist ein kleiner Nein, aber ein wichtiges.

Heute, Jahre später, sehe ich Kolleg:innen, die dieses Nein sprechen. Die Petite-Vue verwenden, die Alpine.js nutzen, die HTMX erforschen. Die anfangen, zu fragen: Brauchen wir das wirklich?

Es ist nicht Revolution. Es ist nicht mal Umsturz. Aber es ist Fortschritt in einer Industrie, die zu lange nicht fragte, ob der Weg, den sie geht, der richtige ist.

Und dafür stehe ich gerne auf der Bühne.


Wenn du diesen Vortrag damals besuchtest oder wenn du diese Worte heute liest: Gib dir selbst die Erlaubnis, kritisch zu sein. Kritisch gegenüber Frameworks, kritisch gegenüber Komplexität, kritisch gegenüber der Annahme, dass größer immer besser ist.

Kontaktier mich gerne, wenn du über Progressive Enhancement sprechen möchtest oder wenn du Petite-Vue in deinem Projekt ausprobieren willst. Lass uns gemeinsam daran arbeiten, das Web wieder zu dem zu machen, was es sein sollte: Schnell, zugänglich und für alle da.

Weitere Artikel

Schau dir das Blog-Archiv an, um tiefer in inklusives Design und Barrierefreiheitspraktiken einzutauchen.

Zur Blogübersicht