Das Argument für Redux und Rust in der Frontend-Entwicklung

2026-07-17

Kategorie: Technik

Frontend-Zustand neigt dazu, schnell auszuufern. Daten werden an einer Stelle geladen, an einer anderen verändert und an einer dritten gelesen. Sechs Monate nach Projektstart drehen sich die hartnäckigsten Bugs selten um was der Zustand enthält — sondern um wann und wie er dorthin gelangt ist. Irgendetwas hat den Zustand verändert, unter einer Komponente hinweg, die glaubte ihn zu besitzen, oder zwei Code-Stellen haben in leicht unterschiedlicher Reihenfolge um denselben Wert gewetteifert. Nichts davon zeigt sich in einer Typsignatur. Es zeigt sich erst um 2 Uhr nachts.

Das Redux-Pattern war eine direkte Antwort auf dieses Problem, und es hält sich auch mehr als ein Jahrzehnt später noch gut.

Was einem das Pattern bringt

Die Kernidee von Redux ist fast schon langweilig einfach: Es gibt genau eine Quelle der Wahrheit für den Zustand einer Anwendung, und der einzige Weg, ihn zu ändern, ist eine typisierte Aktion durch eine reine Reducer-Funktion zu schicken. Keine Komponente greift direkt ein und verändert den Zustand; kein Seiteneffekt schreibt im Stillen etwas um, worauf sich ein anderer Teil der UI verlässt. Jeder Zustandsübergang ist (alter_zustand, aktion) -> neuer_zustand, Punkt.

Diese Disziplin klingt einschränkend, zahlt sich aber fast sofort aus. Weil Reducer reine Funktionen sind, ist jeder Zustandsübergang inspizierbar, wiederholbar und isoliert testbar — kein Mocken eines DOM, kein Simulieren eines Komponenten-Lebenszyklus. Und sobald Zustandsänderungen nur noch ein Protokoll aus (aktion, resultierender_zustand)-Paaren sind, hören Time-Travel-Debugging und Undo/Redo auf, schwierige Features zu sein. Sie werden eher zu einem Nebeneffekt der Architektur als zu einem eigenen Projekt.

Unabhängigkeit vom Framework

Das ist der Teil, der zu wenig gewürdigt wird. Weil die Geschäftslogik — Aktionen, Reducer, Selektoren — überhaupt keine Abhängigkeit von der Render-Schicht hat, wird das GUI-Framework zu einem dünnen, austauschbaren Konsumenten des Zustands, statt zu dem Ding, um das herum alles andere gebaut ist. Ihren Reducern ist es egal, ob sie von React, einem nativen Toolkit oder gar nichts gerendert werden. Das bedeutet, Sie können das Render-Framework später austauschen, eine zweite Oberfläche neben der ersten betreiben — eine CLI, eine mobile Hülle, ein Server-seitiges Rendering — oder die Framework-Version aktualisieren, ohne einen einzigen Reducer anzufassen, weil es nie eine Abhängigkeit dorthin gab.

Das ist eine strukturelle Eigenschaft von Redux selbst, unabhängig von der Sprache. Es stellt sich aber heraus, dass Rust ein besonders guter Ort ist, um darauf aufzubauen.

Warum Rust das Pattern weiter schärft

Ein paar Dinge verstärken sich gegenseitig auf schöne Weise:

• Aktionen als Enums. Wenn jede Aktion eine Variante eines Enums ist, matchen Reducer erschöpfend über sie. Fügt man eine neue Aktion hinzu und vergisst, sie irgendwo zu behandeln, stoppt einen der Compiler — kein stiller No-Op, den ein Nutzer erst drei Releases später entdeckt.
• Ownership-Regeln eliminieren eine ganze Bug-Klasse. Der klassische Redux-Fallstrick in dynamisch typisierten Sprachen ist, dass etwas außerhalb des Reducer-Pfads in geteilten Zustand eingreift und ihn verändert. Rusts Borrow Checker macht das strukturell unmöglich, statt es der Teamdisziplin und Code-Reviews zu überlassen.
• Typen fangen ungültige Zustände zur Kompilierzeit ab. Statt einer Laufzeitwarnung über eine unerwartete Prop-Form kompiliert ein ungültiger Zustandsübergang einfach nicht. Die Feedback-Schleife verschiebt sich von "jemand bemerkt es in Produktion" zu "der Build schlägt fehl".

Der übliche Einwand

Die Standardbeschwerde über Redux ist Boilerplate — Action Creators, Typkonstanten, über Dateien verstreute Switch-Statements. Diese Beschwerde ist größtenteils ein Artefakt davon, Redux in einer Sprache ohne echtes Typsystem zum Anlehnen zu bauen. Enums, Derive-Makros und Pattern Matching reduzieren das meiste dieser Zeremonie automatisch, und der Compiler erledigt Validierungsarbeit, die ein dynamisch typisiertes Redux-Setup von Hand erledigen muss, Aktion für Aktion.

Wo es sich tatsächlich lohnt

Diese Kombination ist nicht das richtige Werkzeug für eine statische Marketing-Seite. Sie zahlt sich in Anwendungen mit wirklich langlebigem, komplexem Zustand aus — Undo-Historie, mehrere Ansichten, die synchron bleiben müssen, Sitzungen, die über viel Nutzerinteraktion hinweg bestehen. Genau dort hört auch der Framework-Unabhängigkeits-Punkt von vorhin auf, theoretisch zu sein: dieselbe Reducer- und Aktionslogik kann mehrere Laufzeitumgebungen ansprechen, nicht nur mehrere UI-Frameworks, da nichts davon von einer JS-Laufzeit, einem DOM oder einer bestimmten Plattform abhängt. Framework-Unabhängigkeit und Laufzeitumgebungs-Unabhängigkeit erweisen sich als zwei Seiten derselben Medaille — Logik, die wirklich nichts über die Render-Schicht weiß, läuft überall dort, wo irgendwann eine Render-Schicht gebraucht werden könnte.

Wir haben diese Kombination als wirklich nützlich erlebt und werden weiterhin darüber schreiben, was wir dabei lernen.