Alpine.js vs. Vue 3 Composition API — Direkter Vergleich

1. Gemeinsame Wurzeln: Deklarative Templates und reaktiver State

Alpine.js wurde bewusst in der Tradition von Vue 2 entwickelt – sein Erfinder Caleb Porzio nennt es gerne „Vue for people who don't need Vue". Diese Verwandtschaft ist keine Metapher: Alpine.js v1 adaptierte die Vue-2-Direktiven-Syntax fast wörtlich. x-show entspricht v-show, x-if entspricht v-if, x-for entspricht v-for, x-model entspricht v-model. Wer Vue 2 kennt, kann Alpine.js in Minuten produktiv einsetzen. Der entscheidende Unterschied: Alpine.js braucht keine Komponenten-Dateien, keinen Build-Step und kein Virtual DOM – es arbeitet direkt mit bestehendem Server-generiertem HTML.

Vue 3 und die Composition API gingen einen anderen Weg: Statt HTML-zentriert zu bleiben, wurde die JavaScript-Seite der Gleichung gestärkt. setup() und die Composition-API-Funktionen (ref(), reactive(), computed(), watch()) ermöglichen es, Logik vollständig in JavaScript zu schreiben und in Composables zu kapseln – unabhängig von einem Template. Vue 3 Single File Components (.vue-Dateien mit <template>, <script setup> und <style>) sind das primäre Entwicklungsmodell und erfordern einen Build-Step mit Vite oder webpack. Alpine.js hat keinen Äquivalent zu .vue-Dateien – und braucht ihn nicht, weil das HTML-Template bereits die Struktur vorgibt.

Die ideologische Spannung zwischen beiden ist fruchtbar: Für eine kleine Webagentur, die Laravel- oder Magento-Projekte baut, ist Alpine.js die pragmatische Wahl – kein Vite-Setup, kein SFC-Kompilierungsschritt, direkte HTML-Bearbeitung. Für ein Vue.js-erfahrenes Team, das eine komplexe SPA aufbaut, ist Vue 3 mit Composition API die bessere Wahl – TypeScript-Integration, Devtools, ausgereiftes Ecosystem und die Möglichkeit, Logik vollständig vom Template zu trennen.

2. ref / reactive vs. x-data: Reaktivität im Vergleich

Vue 3 bietet zwei primitive Reaktivitätskonstrukte: ref() für primitive Werte (Number, String, Boolean) und reactive() für Objekte. ref() erzeugt ein Objekt mit einer .value-Property, auf die im JavaScript zugegriffen werden muss, im Template aber automatisch ausgepackt wird. Das führt zum bekannten „ref.value-Syndrom" – Entwickler vergessen in JavaScript regelmäßig das .value. reactive() ist direkter, kann aber nicht durch Destrukturierung übergeben werden, ohne die Reaktivität zu verlieren. Vue 3.3 führte toRef() und toValue() ein, um diese Grenzen zu mildern.

Alpine.js kennt diese Unterscheidung nicht: Alle Properties im x-data-Objekt sind reaktiv, egal ob primitiv oder verschachtelt. Direkte Mutation funktioniert für beide – this.count++ und this.user.name = 'Max' lösen beide DOM-Updates aus. Kein .value, keine Destrukturierungs-Falle, keine reaktive-vs-ref-Entscheidung. Das macht Alpine.js einfacher zu lernen und weniger fehleranfällig für Entwickler, die von imperativem JavaScript kommen. Der Preis: Alpine.js hat kein TypeScript-Äquivalent zu Vues typsicheren Refs und keine Composition-API-Testbarkeit außerhalb des Browsers.

// Vue 3 Composition API vs. Alpine.js — same UI, different approach

// --- Vue 3: Composition API in <script setup> ---
/*
import { ref, reactive, computed, watch } from 'vue'

const count = ref(0)           // primitive → .value required in JS
const user = reactive({        // object → direct mutation ok
  name: '',
  email: ''
})
const doubled = computed(() => count.value * 2)

watch(count, (newVal, oldVal) => {
  console.log(`count: ${oldVal} → ${newVal}`)
})
// Template: { { count } } (auto-unwrapped), { { user.name } }
*/

// --- Alpine.js equivalent ---
Alpine.data('counterWithUser', () => ({
  count: 0,                    // all properties reactive — no .value
  user: { name: '', email: '' },

  // computed getter — auto-tracked, no import needed
  get doubled() { return this.count * 2 },

  init() {
    // $watch: explicit watcher with old/new value
    this.$watch('count', (newVal, oldVal) => {
      console.log(`count: ${oldVal} → ${newVal}`)
    })
  },

  increment() { this.count++ },
  updateName(n) { this.user.name = n }  // direct mutation, reactive
}))

// Key difference: Alpine.js has no .value indirection
// x-text="count"     — not x-text="count.value"
// x-text="doubled"   — not x-text="doubled.value"
// @click="count++"   — direct mutation works

3. computed() vs. berechnete Getter in x-data

Vues computed() erzeugt ein gecachtes, reaktives Ref, das seinen Wert neuberechnet, wenn sich eine seiner Dependencies ändert. Das Caching ist explizit: Vue merkt sich das Ergebnis und gibt es zurück, bis eine Dependency sich ändert. computed() kann auch einen Setter haben (computed({ get: ..., set: ... })), was beschreibbare berechnete Properties ermöglicht. In script setup ist der Wert direkt im Template verfügbar. computed() ist typsicher und kann gut isoliert getestet werden.

Alpine.js nutzt Standard-JavaScript-Getter (get propertyName() { ... }) im x-data-Objekt. Alpine.js trackt automatisch, welche reaktiven Properties in einem Getter gelesen werden, und invalidiert den Cache bei Änderungen. Das Verhalten ist identisch zu Vue's computed() – gecacht, automatisch reaktiv, kein manuelles Dependency-Tracking. Der Unterschied: Kein computed()-Import, keine .value-Eigenschaft, kein explizites Getter/Setter-Objekt für beschreibbare Properties. JavaScript-Getter mit Setter (set propertyName(val) { ... }) funktionieren ebenso für beschreibbare berechnete Properties in Alpine.js.

4. watch / watchEffect vs. $watch und x-effect

Vue 3 bietet watch() für explizites Beobachten einer oder mehrerer Sources mit Zugriff auf alten und neuen Wert, und watchEffect() für automatisches Tracking ohne explizite Source. watch() ist lazy (läuft nicht sofort) und kann mit { immediate: true } sofort ausgelöst werden. Beide geben eine Stop-Funktion zurück und haben eine Cleanup-Funktion als drittes Argument. Das ist ein ausgereiftes und vollständiges System – aber auch ein System mit mehr API-Oberfläche, die gelernt werden muss.

Alpine.js $watch('property', callback) entspricht Vues watch(): explizite Source, alten und neuen Wert im Callback, stoppt automatisch beim Destroy der Komponente. x-effect im HTML oder this.$watch mit automatischem Tracking entsprechen watchEffect(). Kein Cleanup-Argument – für komplexere Cleanup-Logik gehört die Logik in die destroy()-Methode des x-data-Objekts, die Alpine.js beim Entfernen der Komponente aus dem DOM aufruft. Für die allermeisten Beobachtungs-Anwendungsfälle in serverseitig gerenderten Projekten ist $watch vollständig ausreichend.

5. Composables vs. Alpine.data: Logik-Wiederverwendung

Vue 3 Composables sind Funktionen, die Composition-API-Primitives verwenden und wiederverwendbare, stateful Logik kapseln. Ein useMousePosition()-Composable trackt die Mausposition und kann in beliebig vielen Komponenten verwendet werden – jede Instanz hat eigenen State. Composables können untereinander verschachtelt werden, können Lifecycle Hooks aufrufen und sind vollständig in Isolation testbar (reines JavaScript, kein DOM nötig). Das ist ein starkes Muster für komplexe Logik und große Teams.

Alpine.js Alpine.data() ist weniger mächtig, aber in den meisten Fällen ausreichend: Eine Factory-Funktion registriert eine benannte Komponente mit State und Methoden. Jede x-data="name()"-Instanz bekommt eigene State-Kopie. Composable-ähnliches Sharing von Logik ist durch einfache JavaScript-Funktionen möglich, die in den Initialstate eingemischt werden (Object.assign(this, useSomeLogic())). Das ist weniger elegant als Vue Composables, aber für typische Anwendungsfälle in kleineren Projekten funktionstüchtig. Für wirklich komplexe, stark verschachtelte Logik-Wiederverwendung ist Vues Composable-System klarer strukturiert.

// Vue 3 Composable vs. Alpine.data pattern

// --- Vue 3 Composable: useSearch ---
/*
import { ref, computed, watch } from 'vue'

export function useSearch(fetchFn) {
  const query = ref('')
  const results = ref([])
  const loading = ref(false)
  const error = ref(null)

  const hasResults = computed(() => results.value.length > 0)

  watch(query, async (q) => {
    if (!q) { results.value = []; return }
    loading.value = true
    error.value = null
    try { results.value = await fetchFn(q) }
    catch (e) { error.value = e.message }
    finally { loading.value = false }
  }, { debounce: 300 })

  return { query, results, loading, error, hasResults }
}
// Any component: const { query, results, loading } = useSearch(apiCall)
*/

// --- Alpine.js equivalent: Alpine.data ---
Alpine.data('search', (fetchFn) => ({
  query: '',
  results: [],
  loading: false,
  error: null,

  get hasResults() { return this.results.length > 0 },

  init() {
    let debounceTimer = null
    this.$watch('query', (q) => {
      clearTimeout(debounceTimer)
      debounceTimer = setTimeout(() => this.doSearch(q), 300)
    })
  },

  async doSearch(q) {
    if (!q) { this.results = []; return }
    this.loading = true
    this.error = null
    try { this.results = await fetchFn(q) }
    catch (e) { this.error = e.message }
    finally { this.loading = false }
  }
}))
// <div x-data="search(window.productSearchApi)">

6. Pinia vs. Alpine.store: State-Management

Pinia ist der offizielle State-Manager für Vue 3 und ersetzt Vuex. Stores werden als Composable-ähnliche Funktionen definiert mit defineStore(), und innerhalb des Stores können ref(), computed() und reguläre Funktionen verwendet werden. Pinia bietet Server-Side-State-Transfer (SSR-freundlich), DevTools-Integration mit State-Inspection und Time-Travel-Debugging, TypeScript-Support out-of-the-box und ein Plugin-System für Persistence, Reset und Subscriptions. Für komplexe Anwendungen mit vielen geteilten State-Stücken ist Pinia die deutlich ausgefeiltere Lösung.

Alpine.store() ist bewusst einfach gehalten: Ein Store-Objekt, direkt mutierbar, automatisch reaktiv. Kein DevTools-Support, kein State-History, kein Plugin-System. Für einen E-Commerce-Warenkorb, einen Login-Status oder Theme-Einstellungen ist das vollständig ausreichend. $store.cart.items.push(newItem) – das ist die Alpine.js-Philosophie: direktes Mutieren, automatische DOM-Updates, kein Ceremony. Für Projekte mit mehr als fünf oder sechs globalen Stores oder mit komplexen Store-Interaktionen ist Pinia die bessere Wahl – aber diese Komplexitätsschwelle ist für die allermeisten Unternehmens-Webseiten nicht erreicht.

7. Template-Syntax: SFC vs. HTML-Direktiven

Vue 3 Single File Components (.vue-Dateien) trennen Template, Logik und Styles in einer Datei. <template> enthält HTML mit Vue-Direktiven (v-if, v-for, v-bind, v-on, v-model), <script setup> enthält die Composition-API-Logik, <style scoped> enthält komponentenspezifische CSS. Vite kompiliert SFCs in optimiertes JavaScript. Das Ergebnis ist eine hervorragende Developer-Experience mit Syntax-Highlighting, IDE-Auto-Completion und Type-Checking in allen drei Bereichen. Der Preis: Build-Step zwingend erforderlich, keine direkte HTML-Bearbeitung im Template, kein serverseits gerendertes HTML ohne zusätzliche Konfiguration.

Alpine.js hat keine eigene Template-Sprache: Es arbeitet mit Standard-HTML und Attributen. Das Template ist das HTML, das der Server ausspielt. Das ist ein fundamentaler Vorteil für alle serverseitig gerenderten Projekte: Kein Build-Step für das Template, volle SEO-Kompatibilität durch vollständig gerendertes HTML, direkte Bearbeitung in PHP-Templates, Blade, Twig oder Smarty ohne zusätzliche Compilation. Der Preis: Keine Scoped Styles, keine IDE-Type-Checking für Direktiv-Ausdrücke, keine SFC-basierte Komponenten-Organisation.

8. Lifecycle Hooks: onMounted/onUnmounted vs. init/destroy

Vue 3 bietet eine vollständige Lifecycle-Hook-API: onBeforeMount, onMounted, onBeforeUpdate, onUpdated, onBeforeUnmount, onUnmounted, onErrorCaptured und mehrere Debugging-Hooks. Diese Granularität ermöglicht präzises Timing von Seiteneffekten: Code nach dem ersten Render ausführen (onMounted), vor dem nächsten DOM-Update agieren (onBeforeUpdate), Ressourcen beim Unmount freigeben (onUnmounted). Das ist unverzichtbar für komplexe Animationen, Third-Party-Library-Initialisierungen und Ressourcen-Management in großen SPAs.

Alpine.js bietet zwei Lifecycle-Methoden: init() wird aufgerufen, wenn die Komponente initialisiert wird – entspricht onMounted. destroy() wird aufgerufen, wenn die Komponente aus dem DOM entfernt wird – entspricht onUnmounted. Für die meisten Anwendungsfälle in Alpine.js-Projekten ist das vollständig ausreichend. Third-Party-Libraries initialisiert man in init(), Event-Listener und Timer bereinigt man in destroy(). Kein onBeforeUpdate – aber für DOM-Updates nach State-Änderungen steht this.$nextTick(callback) zur Verfügung, das nach dem nächsten DOM-Update-Zyklus ausgeführt wird.

9. Entscheidungsmatrix: Alpine.js oder Vue 3?

Die Entscheidung zwischen Alpine.js und Vue 3 hängt von fünf zentralen Projektparametern ab: Rendering-Strategie (Server vs. Client), gewünschter Build-Komplexität, Team-Erfahrung, Anwendungsgröße und TypeScript-Anforderungen. Für Projekte mit serverseitigem Rendering, einfachem Build-Setup, kleinen bis mittleren Teams und überschaubarer Interaktivität ist Alpine.js die klarere Wahl. Für SPAs, komplexe State-Graphen, TypeScript-Anforderungen und Vue-erfahrene Teams ist Vue 3 mit Composition API besser geeignet.

Ein wichtiger Faktor, der oft übersehen wird: Langzeit-Wartbarkeit. Alpine.js-Code ist in HTML eingebettet – das ist gut lesbar für Entwickler, die keine JavaScript-Framework-Kenntnisse haben, aber weniger modular als Vue SFCs für sehr große Codebasen. Vue 3 mit Composition API skaliert durch Composables und SFCs deutlich besser auf Teams mit 5+ Entwicklern, die an derselben Frontend-Codebase arbeiten. Alpine.js skaliert gut bis zum ~5-Entwickler-Projektrahmen in serverseitig gerenderten Stacks.

10. Zusammenfassung

Alpine.js und Vue 3 sind konzeptuell nah verwandt – beide nutzen deklarative Direktiven, reaktiven State und Template-Rendering. Der fundamentale Unterschied liegt nicht in den Fähigkeiten, sondern im Betriebsmodell: Alpine.js ist HTML-First und braucht keinen Build-Step. Vue 3 ist JavaScript-First und setzt einen Build-Step voraus. Für serverseitig gerenderte Projekte – Magento 2 Hyvä, Laravel, WordPress, PHP-Anwendungen – ist Alpine.js die natürlichere und schlankere Wahl. Für JavaScript-first SPAs und Nuxt.js-Projekte ist Vue 3 mit Composition API die skalierbarere Architektur.

Die gute Nachricht für Umsteiger: Wer Alpine.js beherrscht, lernt Vue 3 Composition API schnell – und umgekehrt. Die konzeptuellen Parallelen (x-data → reactive, Getter → computed, $watch → watch, Alpine.store → Pinia) machen den Wechsel zu einer Frage der Syntax und des Build-Setups, nicht des grundlegenden Paradigmas. Das Wissen über reaktiven State, deklarative Templates und komponentenbasierte Architektur überträgt sich direkt.

11. FAQ: Alpine.js vs. Vue 3 Composition API