Die Oberfläche folgt den Daten

Die Frage ist nicht das Framework

Viele Gespräche über Frontend beginnen beim Stack. Eine Seite oder eine App, ein Framework oder ein Baukasten. Für Unternehmen mit erklärungsbedürftigen Produkten ist das die falsche Reihenfolge.

Die Oberfläche ist die Ausgabe eines Bestands: Varianten, Regeln, Dokumente, Preise, Rechte. Wer zuerst das Framework wählt, baut eine Interaktionsfläche um Daten, die noch nicht stehen.

Bestände brauchen eine Ausgabe, kein Theme

Ein Theme denkt in Fläche: Hero, Raster, Beitrag. Das reicht, wenn die Website eine Haltung erzählen soll. Es reicht nicht, wenn ein Interessent Modelle vergleichen, eine Konfiguration teilen oder ein Händler denselben Gegenstand später wiederfinden muss.

Deshalb sind Sulu und Sylius für uns keine Geschmacksfrage. Sie sind von Hause aus strukturiert – Seite und Schnittstelle aus demselben Modell. Symfony bleibt offen, wo die Anwendung die Sache ist. Die Folge für die Oberfläche: Sie kann dem Bestand folgen, statt ihn in ein Theme zu pressen.

Die Seite ist das Produkt

Solange die Aufgabe nichts anderes verlangt, ist die Oberfläche eine serverseitig gerenderte Ausgabe. Schnell, haltbar, auffindbar. Der Median unserer Kunden braucht das: strukturierte Inhalte, klare Strecken, gelegentlich eine Anfrage, die denselben Gegenstand trägt.

Neuere Systeme arbeiten mit Turbo und Stimulus: Strecken werden vorausschauend geladen, Zustände tauschen sich aus, ohne die komplette Seite neu zu holen. Das ist spürbar schneller und fühlt sich näher an einer App an, als es eine ist. Eine Seite, die den Bestand ausliefert, bleibt die ehrlichere Form, wenn hinter der Fläche viele Daten und wenig Theater liegen.

Puls, wo die Aufgabe ihn braucht

Ein Konfigurator, ein Assistent, ein Filter, der am Regelwerk hängt: Hier muss die Oberfläche Zustand halten und auf Konflikte reagieren. Das ist keine App. Das ist eine Aufgabe mit Puls – mitten in einer bestehenden Website, einem CMS oder einem Shop.

Dafür bleiben wir in derselben technischen Welt. Symfony UX Live Components sind Twig-Komponenten: Der Zustand lebt in PHP, die Fläche in Twig. Stimulus holt bei Interaktion einen frischen Ausschnitt vom Server und schreibt ihn in die Seite. Kein zweites Frontend. Keine zweite Talentbasis.

Eine App, wenn der Nutzen eine App ist

Wir haben SPAs und PWAs gebaut – mit Svelte und SvelteKit, wenn die Interaktion die eigentliche Arbeit ist. Das bleibt möglich. Es ist nicht der Alltag.

Eine App-ähnliche Oberfläche verdient den Aufwand, wenn jemand wiederkehrend, offline oder in einem dichten Prozess arbeiten muss. Hinter den meisten unserer Systeme liegen Bestände, Regeln und Übergaben. Dort sitzt die teure Arbeit im Modell, nicht in der Fläche. Wer eine App aus Prestige bestellt, kauft Betrieb und Komplexität, die der Nutzen nicht trägt.

Offen, wenn Prozesse es verlangen

Manchmal muss dasselbe Modell mehr als eine Fläche bedienen: ERP, PIM, ein zweiter Auftritt, ein Werkzeug im Vertrieb. Dann exponieren wir den Bestand – API, Webhooks, MCP. Das ist keine Frontend-Entscheidung. Es ist dieselbe Anschlussfähigkeit, die das CMS schon als Annahme mitbringt.

Die Auswahl folgt dem Zielbild. Nicht dem, was gerade als modern gilt.