Die "React Native Referenz"-Serie hat die alte Bridge und die grobe Idee der JSI kurz gestreift (Thema "Bridging"). Dieses Kapitel geht deutlich tiefer: WARUM wurde die gesamte Architektur neu gebaut, WAS genau ändert sich technisch, und was bedeutet das PRAKTISCH für unser Projekt?

Das alte Problem: die JSON-Bridge

In der klassischen Architektur (bis React Native 0.70) kommunizierten JavaScript- und Native-Seite AUSSCHLIESSLICH über eine Bridge: jeder Aufruf ("rendere diese View", "lies die Kamera-Berechtigung") wurde in ein JSON-serialisierbares Nachrichtenformat verpackt, ASYNCHRON über die Bridge geschickt, auf der anderen Seite wieder DESERIALISIERT. Drei strukturelle Probleme: (1) JSON-Serialisierung kostet Zeit UND Speicher bei jedem einzelnen Aufruf, (2) alle Bridge-Kommunikation ist ZWINGEND asynchron, selbst wenn ein Wert eigentlich sofort verfügbar wäre (z. B. eine einfache Geräte-Eigenschaft abfragen), (3) alle verfügbaren Native-Module werden beim App-Start VOLLSTÄNDIG geladen, auch wenn eine Sitzung sie nie benutzt.

JSI: der fundamentale Wechsel

JSI (JavaScript Interface) ersetzt die Bridge durch eine C++-Schicht, die JavaScript-Objekten DIREKTEN, SYNCHRONEN Zugriff auf native C++-Objekte gibt – kein JSON, keine Serialisierung, keine erzwungene Asynchronität. JavaScript kann eine native Funktion GENAUSO aufrufen wie eine normale JS-Funktion, mit sofortigem Rückgabewert, wenn die Aufgabe es erlaubt.

Fabric: die neue Rendering-Engine

Fabric ist die JSI-basierte Neuimplementierung des Rendering-Systems – erinnern Sie sich an den Shadow-Thread aus der "React Native Referenz"-Serie (Yoga-Engine berechnet Flexbox-Layout im Hintergrund)? Fabric erlaubt es, Layout-Messungen SYNCHRON abzufragen, wo es nötig ist (z. B. "wie hoch ist diese View gerade tatsächlich gerendert?"), statt zwingend über einen asynchronen Bridge-Roundtrip warten zu müssen. Der "Shadow Tree" existiert jetzt direkt in C++, nicht mehr als separate, über die Bridge synchronisierte Kopie.

TurboModules: native Module bei Bedarf laden

TurboModules ersetzt das alte "Native Modules"-System – der wichtigste praktische Unterschied: Module werden erst beim ERSTEN tatsächlichen Zugriff geladen ("lazy"), nicht mehr pauschal beim App-Start. Nutzt Ihre App z. B. expo-camera nur auf einem einzigen, selten besuchten Screen, wird der native Kamera-Code auch erst geladen, wenn dieser Screen tatsächlich erreicht wird – schnellerer App-Start für alle Nutzer, die diesen Screen nie öffnen.

Praxis: den New-Architecture-Status prüfen

Seit React Native 0.76 ist die New Architecture der STANDARD für neue Projekte (analog zu Hermes aus dem letzten Kapitel). In app.json lässt sich der Status einsehen/steuern:

{
  "expo": {
    "newArchEnabled": true
  }
}

Überraschung: Sie nutzen JSI bereits, ohne es zu wissen

zustand und @reduxjs/toolkit aus den Kapiteln 2-3 sind reine JavaScript-Bibliotheken, berühren JSI nicht direkt. ABER: @react-native-async-storage/async-storage aus "React Native für Einsteiger" ist bereits ein natives Modul – seine moderne Version kommuniziert über TurboModules/JSI, ohne dass unser eigener Code sich dafür ändern musste. GENAU DAS ist der Sinn der neuen Architektur: bestehender JavaScript-Code (AsyncStorage.getItem(...)) funktioniert UNVERÄNDERT, die Performance-Verbesserung passiert TRANSPARENT darunter.

Wann Sie das aktiv wissen MÜSSEN

• Beim Einbinden mancher älterer, seit Jahren nicht aktualisierter Native-Module-Bibliotheken – manche unterstützen die New Architecture noch nicht vollständig ("backward compatibility mode" nötig, mit reduzierten Vorteilen).
• Beim Schreiben EIGENER nativer Module (Swift/Kotlin-Code, der mit JavaScript kommuniziert) – die API dafür hat sich mit TurboModules/Fabric fundamental geändert (siehe nächstes Kapitel für das Konzept, ohne selbst natives Code zu schreiben).
• Bei Performance-kritischen Bibliotheken wie react-native-reanimated (nächstes Kapitel), die JSI DIREKT und BEWUSST nutzen, um synchron mit dem UI-Thread zu kommunizieren.