Hvordan fungerer React Native-arkitekturen (bridge vs ny arkitektur)?

Question

Accepted Answer

React Native kjører **JavaScript** og **native** kode som må kommunisere. Den originale arkitekturen brukte en asynkron **bridge**; den **nye arkitekturen** (JSI, TurboModules, Fabric) muliggjør raskere, synkron kommunikasjon. Å forstå dette klargjør React Native-atferd og ytelse.

## Den originale arkitekturen: bridge-en

```text
React Native runs:
  → a JS THREAD (your React/JS code) and the NATIVE side (UI, native modules)
  → they communicate over a BRIDGE: messages are SERIALIZED (to JSON), passed ASYNC,
    and deserialized on the other side
Limitations:
  ✗ ASYNCHRONOUS only (can't call native synchronously)
  ✗ SERIALIZATION overhead; the bridge can be a BOTTLENECK with heavy traffic
  ✗ e.g. fast scrolling/animations passing data over the bridge → jank
```

## Den nye arkitekturen (JSI, TurboModules, Fabric)

```text
The NEW ARCHITECTURE replaces the bridge:
  JSI (JavaScript Interface) → JS can call native code DIRECTLY and SYNCHRONOUSLY
    (no serialization bridge) → much faster JS↔native interop
  TURBOMODULES → native modules loaded lazily, via JSI (faster, on-demand)
  FABRIC → the new rendering system → better, more efficient UI rendering; sync layout
  CODEGEN → type-safe JS↔native interfaces
→ Result: better performance, less overhead, synchronous calls, smoother UI.
```

## Hvorfor det betyr noe (praktisk)

```text
→ Explains React Native's PERFORMANCE characteristics (why bridge traffic was costly)
→ The new architecture (default in recent RN) improves performance and interop
→ Informs optimization (minimize bridge crossings on the old architecture; native-thread
  animations) and understanding of how RN executes
```

## Hvorfor det betyr noe

Å forstå React Native-arkitekturen er verdifull kunnskap på seniorxnivå fordi det **forklarer React Native-atferd og ytelseskarakteristika**, og forsterker evnen til å resonnere om og optimalisere apper.

Den grunnleggende strukturen — React Native som kjører en **JS-tråd** (koden din) og **native-siden** (UI, native moduler) som må **kommunisere** — er nøkkelen til å forstå hvordan React Native fungerer.

Å forstå den **originale bridge-arkitekturen** (der JS og native kommuniserer via en asynkron bridge som serialiserer meldinger til JSON og passerer dem over) forklarer React Native-ens historiske ytelseskarakteristika og begrensninger: kommunikasjon var kun asynkron, hadde serialiseringsoverhead, og bridge-en kunne bli en **flaskehals ved tung trafikk** (forårsaker jank ved rask scrolling eller animasjoner som passerer data over) — som er **hvorfor minimering av bridge-kryssinger og kjøring av animasjoner på native-tråden var viktige optimaliseringer**, og knytter arkitektur til praktisk ytelsesråd.

Å forstå den **nye arkitekturen** (**JSI** som muliggjør direkte, synkron JS↔native-samtaler uten serialiserings-bridge; **TurboModules** for lat innlasting av native moduler; **Fabric** for bedre rendering; Codegen for type-sikre grensesnitt) blir stadig viktigere da det blir standardoppsettet — det forbedrer ytelse, reduserer overhead, muliggjør synkrone samtaler, og produserer glattere UI, og representerer React Native-ens betydelige utvikling.

Å forstå denne arkitekturen **forklarer React Native-ytelse** (hvorfor bridge-en betød noe), **informerer optimalisering** (praksisene som følger fra arkitekturen), og klargjør hvordan React Native kjører — og transformerer React Native fra en svart boks til et forståelig system.

Siden forståelse av arkitekturen (bridge-en og den nye JSI-baserte arkitekturen) forklarer React Native-ytelseskarakteristika, informerer optimalisering, og gjenspeiler bevissthet om dets viktige utvikling, og siden denne dybden løfter en fra å bruke React Native til å forstå det, er forståelse av React Native-arkitekturen verdifull kunnskap på seniorxnivå — som forklarer atferd og ytelse, informerer optimalisering, og gjenspeiler dybde og bevissthet om plattformutvikling som forventes for seniorroleroller innen React Native.