Reaktivität: Alpine.js vs. Proxy-basierte Reaktivität in Vue im Vergleich

1. Der gemeinsame Ursprung: Alpine hängt direkt von @vue/reactivity ab

Ein Blick in die package.json des Alpine-Kernpakets zeigt eine Überraschung, die vielen Alpine-Entwicklern nicht bewusst ist: Alpine deklariert @vue/reactivity als direkte Abhängigkeit, aktuell auf eine Version aus der 3.1er-Reihe von Vue gepinnt. Alpine baut sein eigenes, kleines reactive(), effect() und raw() also nicht selbst nach, sondern importiert exakt die Bibliothek, die auch Vue 3 für seine eigene Reaktivität verwendet, und bindet sie über eine austauschbare Engine-Schnittstelle ein.

Der entscheidende Unterschied liegt deshalb nicht im zugrunde liegenden Mechanismus, sondern in der Art, wie beide Frameworks diesen Mechanismus für Endnutzer verpacken und einsetzen. Wer verstehen will, warum sich Alpine trotzdem anders verhält als eine Vue-Komponente, muss also nicht nach einem anderen Reaktivitäts-Algorithmus suchen, sondern danach, wie Alpine diese gemeinsame Grundlage einsetzt.

2. Wie Proxy-basierte Reaktivität grundsätzlich funktioniert

Sowohl Alpine als auch Vue verpacken ein einfaches JavaScript-Objekt in einen Proxy. Jeder lesende Zugriff auf eine Eigenschaft dieses Proxys läuft durch eine geteffect(), gerade diese Eigenschaft gelesen hat. Jeder schreibende Zugriff läuft durch eine set-Falle, die alle zuvor gemerkten Funktionen erneut ausführt, sofern sich der Wert tatsächlich geändert hat.

Genau dieses Zusammenspiel aus get-Tracking und set-Trigger ist es, was in Alpine dafür sorgt, dass x-text="count" automatisch aktualisiert wird, sobald irgendwo im Code count++ passiert, ganz ohne dass jemand manuell ein Update anstoßen müsste. Verschachtelte Objekte werden dabei nicht sofort beim Erzeugen des Proxys komplett durchgewandert, sondern erst beim ersten lesenden Zugriff auf ein verschachteltes Feld selbst wieder in einen Proxy verpackt, ein Verhalten, das man als lazy deep reactivity bezeichnet.

3. Unterschied 1: kein memoisiertes computed() in einfachen Alpine-Gettern

Vue bietet mit computed(() => ...) ein eigenes, öffentlich dokumentiertes Primitiv, das einen berechneten Wert cached und erst dann neu berechnet, wenn sich eine seiner Abhängigkeiten tatsächlich geändert hat. Alpine kennt kein vergleichbares öffentliches computed() für den täglichen Gebrauch in x-data. Wer in Alpine einen berechneten Wert über einen einfachen Getter im x-data-Objekt definiert, bekommt zwar Reaktivität, aber kein Caching: der Getter-Code läuft bei jedem einzelnen lesenden Zugriff erneut, auch wenn sich die zugrunde liegenden Werte seit dem letzten Zugriff gar nicht verändert haben.

Das ist keine Ungenauigkeit, sondern eine bewusste Konsequenz daraus, dass Alpine @vue/reactivity zwar als Engine nutzt, das separate computed()-Primitiv aus diesem Paket aber nicht für x-data-Getter einsetzt. Bei einer teuren Berechnung, etwa dem Filtern und Sortieren eines großen Arrays innerhalb eines Getters, der von mehreren x-text- oder x-show-Bindings gleichzeitig gelesen wird, führt das dazu, dass dieselbe teure Berechnung mehrfach pro Render-Zyklus läuft, während ein Vue-computed() an derselben Stelle nur einmal rechnen und das Ergebnis für alle weiteren Leser wiederverwenden würde.

Alpine.data('produktliste', () => ({
  produkte: [ /* großes Array */ ],
  filter: '',

  // Läuft bei JEDEM Lesezugriff neu, kein Caching wie bei Vues computed()
  get gefilterteProdukte() {
    console.log('Filter läuft erneut')
    return this.produkte.filter(p => p.name.includes(this.filter))
  },
}))

// Wenn gefilterteProdukte an drei verschiedenen Stellen im Markup
// gelesen wird (x-text, x-show, x-for), läuft der Filter DREIMAL
// pro Update, nicht einmal wie bei einem gecachten computed().

4. Unterschied 2: Granularität der Effekte statt Virtual-DOM-Diffing

Vue bindet Reaktivität an die Render-Funktion einer Komponente als Ganzes: ändert sich irgendein reaktiver Wert, den die Render-Funktion liest, läuft die komplette Funktion erneut, erzeugt einen neuen Virtual-DOM-Baum, und ein Diffing-Algorithmus vergleicht diesen mit dem vorherigen Baum, um die minimal nötigen echten DOM-Änderungen zu berechnen. Alpine geht diesen Umweg nicht: jede einzelne Direktive wie x-text, x-show oder x-bind:class bekommt ihren eigenen, winzigen effect(), der bei einer Änderung direkt und ausschließlich diese eine DOM-Operation ausführt.

Diese feinere Granularität ist einer der Hauptgründe, warum Alpine komplett ohne Virtual DOM auskommt: es gibt schlicht keinen ganzen Baum, der neu berechnet und verglichen werden müsste, weil jede reaktive Verbindung von Anfang an direkt und einzeln an genau die DOM-Stelle gebunden ist, die sie betrifft. Der Preis dafür ist mehr einzelne, kleine effect()-Instanzen im Speicher, der Nutzen ist ein Update-Modell, das für kleine, gezielt interaktive DOM-Inseln, wie Alpine sie typischerweise steuert, oft günstiger ist als ein komplettes Component-Rerendering.

5. Debugging-Konsequenz: welche Werte sind überhaupt reaktiv?

Reaktiv ist in Alpine ausschließlich das, was über die Proxy-Kette erreichbar bleibt, angefangen beim ursprünglichen x-data-Objekt. Wird eine einzelne primitive Eigenschaft aus diesem Objekt destrukturiert, etwa const { count } = this, verliert die neue lokale Variable count die Verbindung zum Proxy vollständig, weil Primitivwerte in JavaScript grundsätzlich by value kopiert werden und nicht wie Objekte als Referenz erhalten bleiben. Ein effect(), der danach nur noch die lokale Kopie liest, reagiert nie wieder auf spätere Änderungen am Original.

Das Tückische an diesem Fehler ist, dass er in der Konsole keinen einzigen Fehler wirft. Die Anwendung läuft weiter, der Wert wird angezeigt, nur eben nie wieder aktualisiert, was sich in der Praxis oft erst nach längerer Fehlersuche als verlorene Reaktivität statt als kaputte Logik entpuppt. Die Alpine DevTools zeigen für das Original-Objekt weiterhin korrekt reaktive Werte an, was die verlorene Verbindung der destrukturierten Kopie zusätzlich verschleiert, weil man dort ja gar nicht mehr hinschaut.

Alpine.data('zaehler', () => ({
  count: 0,

  init() {
    // FALSCH: count ist ab hier eine lose Kopie, keine Referenz mehr
    let { count } = this
    setInterval(() => {
      count++ // ändert nur die lokale Kopie, das UI aktualisiert sich nie
    }, 1000)
  },
}))

// RICHTIG: über this.count bleibt die Proxy-Verbindung erhalten
// setInterval(() => { this.count++ }, 1000)

6. Performance bei großen, tief verschachtelten Objekten

Weil sowohl Alpine als auch Vue verschachtelte Objekte erst beim ersten lesenden Zugriff in einen neuen Proxy verpacken, verteilt sich der Wrapping-Aufwand über die Laufzeit, statt beim Erzeugen des x-data-Objekts komplett auf einmal anzufallen. Bei kleinen, typischen Alpine-Komponenten, wie sie für einzelne interaktive Inseln auf einer serverseitig gerenderten Seite üblich sind, fällt dieser Aufwand praktisch nie ins Gewicht.

Problematisch wird es erst, wenn ein sehr großes, tief verschachteltes JSON-Objekt, etwa eine komplette Produktliste mit hunderten Einträgen und mehreren verschachtelten Ebenen pro Eintrag, komplett reaktiv gemacht wird, obwohl nur ein Bruchteil der Felder jemals in einer Direktive gelesen wird. Jeder Zugriff auf ein noch nicht verpacktes verschachteltes Feld erzeugt einen neuen Proxy, und bei einer x-for-Schleife, die über viele solcher Objekte iteriert, summiert sich das zu spürbarem Overhead, besonders beim initialen Rendern der Liste.

7. Alpine.raw(): Proxy-Wrapping gezielt umgehen

Für genau diesen Fall stellt Alpine Alpine.raw(proxy) bereit, das direkte Gegenstück zu Vues toRaw(). Der Aufruf liefert das zugrunde liegende, unverpackte Originalobjekt zurück, komplett ohne Proxy-Overhead und ohne Reaktivitäts-Tracking. Das eignet sich für große Datenmengen, die nur einmal geladen und dann iteriert, aber nie einzeln reaktiv beobachtet werden müssen, etwa eine große Referenzliste, aus der lediglich Werte gelesen werden.

Wichtig ist, dass Alpine.raw() das Objekt nur einmalig entpackt, das Ergebnis selbst bleibt danach ein normales, nicht reaktives JavaScript-Objekt. Wird dieses rohe Objekt anschließend wieder in ein reaktives x-data eingehängt, muss es erneut über Alpine.reactive() laufen, um wieder Änderungen zu verfolgen. In der Praxis lohnt sich Alpine.raw() vor allem in Kombination mit x-for über große, weitgehend statische Datensätze, bei denen Proxy-Tracking für jedes einzelne Feld reiner Overhead wäre.

Alpine.data('katalog', () => ({
  // große, weitgehend statische Referenzdaten ohne Feld-Reaktivität
  produkte: Alpine.raw(grosseProduktliste),
  filter: '',
}))

8. Oeffentliche API in Vue vs. internes Implementierungsdetail in Alpine

Vue macht seine Reaktivität zu einem zentralen, öffentlich dokumentierten Baustein der Sprache: ref(), reactive(), computed() und watch() sind Konzepte, die jede Vue-Dokumentation und jedes Tutorial von Anfang an lehrt. Alpine behandelt dieselbe zugrunde liegende Engine dagegen als internes Detail: Alpine.reactive(), Alpine.effect() und Alpine.raw() existieren zwar und sind für den Bau eigener Direktiven und Plugins essenziell, tauchen in normaler Alpine-Anwendungsentwicklung mit x-data aber praktisch nie auf.

Diese unterschiedliche Sichtbarkeit hat einen einfachen Grund: Vue-Komponenten werden explizit mit JavaScript-Code in einer setup()-Funktion oder <script setup>-Sektion gebaut, wo die Reaktivitäts-Primitive ohnehin manuell verwendet werden müssen. Alpine dagegen zielt bewusst auf HTML-first-Entwicklung ab, bei der ein einfaches Objektliteral in x-data automatisch komplett reaktiv wird, ohne dass irgendjemand reactive() selbst aufrufen müsste.

9. Praktische Konsequenz fürs tägliche Debugging

Wer aus der Vue-Welt kommt und in Alpine nach einem computed()-Import sucht, wird ihn nicht finden, denn er ist bewusst nicht Teil der öffentlichen API. Wer stattdessen einen Performance-Einbruch bei einer häufig gelesenen Getter-Property bemerkt, sollte zuerst prüfen, ob dieselbe teure Berechnung an mehreren Stellen im Markup gleichzeitig gelesen wird, denn genau das ist in Alpine, anders als in Vue, ein Kandidat für mehrfach unnötig wiederholte Arbeit.

Wer dagegen einen Wert findet, der sich einfach nicht mehr aktualisiert, obwohl die Logik korrekt aussieht, sollte gezielt nach Destrukturierung von primitiven Werten aus dem reaktiven Objekt suchen, dem häufigsten stillen Reaktivitätsverlust in Alpine-Code. Beide Muster lassen sich in den Alpine DevTools nachvollziehen, indem man beobachtet, welche effect()-Instanzen bei einer Änderung tatsächlich erneut laufen und welche nicht.

10. Zusammenfassung

11. FAQ: Alpine-Reaktivität im Vergleich zu Vue: das Wichtigste auf einen Blick