React Native New Architecture in 2026: Hermes V1, Bridgeless Mode en Interviewvragen

De React Native New Architecture heeft in 2026 volledige productiegereedheid bereikt. Met React Native 0.84 dat Hermes V1 als standaard engine levert en versie 0.85 die elk spoor van de legacy bridge verwijdert, biedt het framework nu bijna-native performance zonder dat ontwikkelaars zich bezig hoeven te houden met architectuurvlaggen of compatibiliteitslagen.

Wat er veranderd is in de architectuurstack van React Native

De oude React Native architectuur was gebaseerd op een single-threaded asynchrone JSON-bridge die berichten tussen JavaScript en native code doorgaf. Elke interactie passeerde dit knelpunt: touch-events, layout-berekeningen, module-aanroepen. De New Architecture vervangt elke laag van deze pipeline door een direct, synchroon alternatief.

| Laag | Oude Architectuur | Nieuwe Architectuur | |------|-------------------|---------------------| | JS Engine | JavaScriptCore | Hermes V1 (bytecode + JIT) | | Renderer | Paper (async bridge) | Fabric (synchroon, gedeeld C++) | | Native Modules | Bridge Modules (JSON-serialisatie) | TurboModules (JSI, directe aanroepen) | | Communicatie | Async JSON Bridge | JSI (JavaScript Interface) | | Initialisatie | Bridge-init + moduleregistratie | Bridgeless (lazy, on-demand) |

JSI (JavaScript Interface) vormt het fundament. In plaats van elke aanroep als JSON te serialiseren en door een wachtrij te sturen, stelt JSI C++ host-objecten direct beschikbaar voor JavaScript. Een TurboModule-aanroep die voorheen JSON-encoding, bridge-queuing en JSON-decoding vereiste, wordt nu als directe functie-aanroep uitgevoerd.

Hermes V1: De standaard JavaScript-engine

Hermes V1 werd de standaard engine in React Native 0.84, uitgebracht in februari 2026. Het betreft een volledige herschrijving van de compiler en VM, niet slechts een incrementele update van eerdere Hermes-versies.

De verbeteringen bestrijken vier gebieden: een herschreven compiler met een nieuw bytecode-formaat, een verbeterde JIT-compiler, de Hades concurrent garbage collector en betere ondersteuning voor moderne JavaScript-patronen die door React 19 worden gebruikt.

// Comparing startup and runtime metrics

// Hermes V1 bytecode is pre-compiled at build time
// No parse-compile step at runtime = faster cold starts

// Cold start comparison (production build, Pixel 8):
// Hermes V1:  ~850ms TTI
// JSC:        ~1200ms TTI  (29% slower)

// Memory footprint (complex app, 50+ screens):
// Hermes V1:  ~45MB baseline
// JSC:        ~72MB baseline (38% more)

// GC pause comparison (FlatList, 500+ complex cells):
// Hermes V1 (Hades):  <12ms max pause
// Old Hermes:         ~45ms occasional pauses
// Result: zero dropped frames in scroll benchmarks

Hades, de concurrent garbage collector, verdient bijzondere aandacht. Eerdere Hermes-versies gebruikten een stop-the-world GC die bij het scrollen door lijsten af en toe zichtbare haperingen veroorzaakte. Hades voert de collection concurrent uit op een achtergrondthread en houdt GC-pauzes onder 12ms. Voor apps die lange lijsten met complexe cellen renderen, elimineert dit de laatste bron van JavaScript-gerelateerde frame drops.

Fabric Renderer: Synchroon Layout en Rendering

Fabric vervangt de Paper-renderer door een C++-kern die gedeeld wordt tussen iOS en Android. Het cruciale verschil: layout-berekeningen vinden synchroon plaats op de JavaScript-thread in plaats van asynchroon via de bridge.

Dit synchrone model maakt twee mogelijkheden mogelijk die met Paper onmogelijk waren:

1. Ondersteuning voor concurrent rendering: Fabric integreert met de concurrent-features van React 19. Transitions, Suspense boundaries en useTransition werken correct omdat Fabric het rendering kan onderbreken en hervatten.

2. Direct C++-layout: Yoga (de layout-engine) draait in dezelfde geheugenruimte als de JavaScript-runtime. Geen serialisatie-overhead voor flexbox-berekeningen.

// Concurrent features work correctly with Fabric
import React, { useState, useTransition } from 'react'
import { View, Text, FlatList, TextInput, StyleSheet } from 'react-native'

type Item = { id: string; name: string; category: string }

function SearchableList({ items }: { items: Item[] }) {
  const [query, setQuery] = useState('')
  const [filtered, setFiltered] = useState(items)
  const [isPending, startTransition] = useTransition()

  const handleSearch = (text: string) => {
    setQuery(text) // Urgent: update input immediately
    startTransition(() => {
      // Non-urgent: filter can be deferred
      const result = items.filter(item =>
        item.name.toLowerCase().includes(text.toLowerCase())
      )
      setFiltered(result)
    })
  }

  return (
    <View style={styles.container}>
      <TextInput
        value={query}
        onChangeText={handleSearch}
        placeholder="Search items..."
        style={styles.input}
      />
      {isPending && <Text style={styles.pending}>Filtering...</Text>}
      <FlatList
        data={filtered}
        keyExtractor={item => item.id}
        renderItem={({ item }) => (
          <View style={styles.row}>
            <Text>{item.name}</Text>
          </View>
        )}
      />
    </View>
  )
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 16 },
  input: { borderWidth: 1, borderColor: '#ccc', padding: 12, marginBottom: 8 },
  pending: { color: '#888', marginBottom: 4 },
  row: { padding: 12, borderBottomWidth: 1, borderBottomColor: '#eee' },
})

De useTransition-hook in dit voorbeeld laat zien waarom Fabric belangrijk is. Met Paper had startTransition geen effect omdat de renderer een lopende render niet kon onderbreken. De integratie van Fabric met de concurrent mode van React 19 zorgt ervoor dat uitgestelde updates werken zoals bedoeld, waarbij het tekstveld responsief blijft terwijl duizenden items op de achtergrond worden gefilterd.

TurboModules en JSI: Eliminatie van serialisatie-overhead

TurboModules vervangen het oude NativeModules-systeem. Het prestatieverschil komt voort uit de volledige eliminatie van JSON-serialisatie. Een bridge-module-aanroep volgde dit pad: JS-object -> JSON.stringify -> bridge-wachtrij -> JSON.parse -> native aanroep -> JSON.stringify -> bridge-wachtrij -> JSON.parse -> JS-callback. Een TurboModule-aanroep is een directe C++-functie-aanroep via JSI.

// TurboModule spec using the Codegen
import type { TurboModule } from 'react-native'
import { TurboModuleRegistry } from 'react-native'

export interface Spec extends TurboModule {
  // Synchronous: returns immediately, no bridge round-trip
  getDeviceModel(): string
  getOSVersion(): string
  getBatteryLevel(): number

  // Asynchronous: for operations that genuinely need async
  getStorageUsage(): Promise<{ used: number; total: number }>
}

export default TurboModuleRegistry.getEnforcing<Spec>('DeviceInfo')

// Native Android implementation of the TurboModule
package com.app.modules

import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.ReadableMap
import com.facebook.react.bridge.WritableNativeMap
import com.facebook.react.module.annotations.ReactModule

@ReactModule(name = "DeviceInfo")
class DeviceInfoModule(reactContext: ReactApplicationContext) :
  NativeDeviceInfoSpec(reactContext) {

  // Synchronous via JSI - no bridge, no JSON, no queue
  override fun getDeviceModel(): String {
    return android.os.Build.MODEL
  }

  override fun getOSVersion(): String {
    return "Android ${android.os.Build.VERSION.RELEASE}"
  }

  override fun getBatteryLevel(): Double {
    val manager = reactApplicationContext
      .getSystemService(android.content.Context.BATTERY_SERVICE)
      as android.os.BatteryManager
    return manager.getIntProperty(
      android.os.BatteryManager.BATTERY_PROPERTY_CAPACITY
    ).toDouble()
  }

  override fun getStorageUsage(
    promise: com.facebook.react.bridge.Promise
  ) {
    val stat = android.os.StatFs(
      android.os.Environment.getDataDirectory().path
    )
    val map = WritableNativeMap().apply {
      putDouble("used", (stat.totalBytes - stat.availableBytes).toDouble())
      putDouble("total", stat.totalBytes.toDouble())
    }
    promise.resolve(map)
  }

  override fun getName(): String = "DeviceInfo"
}

Het cruciale detail: getDeviceModel(), getOSVersion() en getBatteryLevel() zijn synchroon. De JavaScript-thread roept direct native code aan en ontvangt de retourwaarde in dezelfde tick. Geen promises, geen callbacks, geen bridge-roundtrip. Dit is alleen mogelijk via JSI.

Bridgeless Mode: Wat het verwijdert en waarom het belangrijk is

Bridgeless Mode, geintroduceerd in React Native 0.73 en standaard sinds 0.74, voltooit de architectuurmigratie door de bridge-initialisatie volledig te verwijderen. Zelfs nadat Fabric en TurboModules waren geadopteerd, initialiseerde de oude bridge nog bij het opstarten om globale event-emitters, timers en foutafhandeling te beheren. Bridgeless Mode verplaatst deze resterende systemen naar JSI-gebaseerde implementaties.

De praktische impact:

• Snellere opstart: Geen overhead van bridge-initialisatie. De runtime start alleen op wat de app daadwerkelijk gebruikt via lazy loading.
• Verminderd geheugengebruik: Geen bridge-datastructuren worden bij het opstarten gealloceerd.
• Schonere foutafhandeling: Error boundaries en globale error handlers werken via de nieuwe architectuur zonder bridge-fallbacks.

React Native 0.82 heeft de oude bridge permanent uitgeschakeld. React Native 0.85, uitgebracht in april 2026, heeft alle resterende bridge-gerelateerde code uit de codebase verwijderd. Er is geen fallback-pad.

Productiemigratie: Praktijkgerichte performance-benchmarks

Productiemigraties van de oude naar de nieuwe architectuur tonen consistente verbeteringen in de belangrijkste metrieken:

| Metriek | Oude Architectuur | Nieuwe Architectuur | Verbetering | |---------|-------------------|---------------------|-------------| | Cold start (TTI) | 1,4s | 0,8s | 43% sneller | | Schermovergang | 180ms | 110ms | 39% sneller | | Geheugen-baseline | 89MB | 66MB | 26% lager | | JS-naar-native-aanroep | ~5ms (async) | ~0,1ms (sync) | 40x sneller | | GC max pauze | 45ms | 12ms | 73% korter | | FlatList scroll (1000 items) | Af en toe haperingen | Vloeiende 60fps | Geen verloren frames |

De meest impactvolle verbetering voor de gebruikerservaring is de reductie van GC-pauzes. Hades houdt collection-pauzes onder het budget van een frame (16,6ms bij 60fps), waardoor de meest voorkomende bron van zichtbare haperingen in complexe React Native-apps wordt geelimineerd.

Ecosysteemcompatibiliteit in 2026

Het ecosysteem is volledig geconvergeerd op de New Architecture. Expo SDK 55 en latere versies draaien uitsluitend op de New Architecture, zonder optie om het uit te schakelen. Belangrijke bibliotheekcompatibiliteit:

• React Navigation 7.2+: Volledige Fabric-ondersteuning met native-stack-schermen
• Reanimated 3.5+: Gedeelde animatie-backend met React Native 0.85
• Gesture Handler 2.16+: Directe JSI-gebaseerde gesture-herkenning
• Vision Camera 4.0+: Frame-verwerking via JSI
• Detox: E2E-testen compatibel met de New Architecture

Voor teams die Expo gebruiken, genereert npx create-expo-app een project met de New Architecture standaard ingeschakeld. Geen configuratie nodig.

Interviewvragen: React Native New Architecture

Deze vragen verschijnen regelmatig in senior React Native-interviews in 2026. Elk antwoord dekt de diepgang die op staff-/senior-niveau wordt verwacht.

V1: Leg het verschil uit tussen de oude Bridge en JSI. Waarom maakt JSI synchrone native aanroepen mogelijk?

De bridge serialiseerde elk JS-naar-native bericht als JSON, plaatste het in een asynchrone wachtrij en deserialiseerde het aan de native kant. JSI (JavaScript Interface) stelt C++ host-objecten direct beschikbaar in de JavaScript-VM. Native functies die via JSI zijn geregistreerd, verschijnen als gewone JavaScript-functies die native code inline uitvoeren, zonder serialisatie of queuing. Synchrone aanroepen zijn mogelijk omdat JSI opereert in dezelfde threadcontext zonder een tussenliggende berichtenwachtrij.

V2: Welk probleem lost de Fabric-renderer op dat Paper niet kon oplossen?

Paper renderde asynchroon via de bridge, waardoor ondersteuning voor Reacts concurrent-features onmogelijk was. Een startTransition-aanroep had geen effect omdat Paper een lopende render-tree niet kon onderbreken. Fabric implementeert rendering in gedeelde C++-code, integreert direct met de reconciler van React 19 en ondersteunt concurrent rendering, Suspense en transitions. Layout-berekeningen via Yoga vinden ook synchroon plaats in dezelfde geheugenruimte, waardoor de latentie van cross-bridge layout wordt geelimineerd.

V3: Waarom is Hermes vereist voor de New Architecture? Zou een andere engine kunnen worden gebruikt?

De New Architecture is afhankelijk van JSI, dat vereist dat de JavaScript-engine registratie van C++ host-objecten ondersteunt. Hermes is van de grond af ontworpen met JSI-integratie. JavaScriptCore zou JSI theoretisch kunnen ondersteunen, maar de officiele implementatie en het testen zijn gebouwd rondom Hermes. Hermes V1 biedt daarnaast bytecode-voorcompilatie (elimineert runtime-parsing), de Hades concurrent GC (pauzes onder 12ms) en WebAssembly-ondersteuning, die geen van alle beschikbaar zijn via de React Native JSC-integratie.

V4: Hoe verschillen TurboModules van de oude NativeModules-API vanuit het perspectief van de ontwikkelaar?

TurboModules vereisen een Codegen-spec (een TypeScript-interface die TurboModule uitbreidt) die type-safe native bindings genereert tijdens de build. De oude NativeModules gebruikten runtime-reflectie zonder type-checking. TurboModules ondersteunen synchrone retourwaarden (niet alleen promises), lazy-initialisatie (modules laden alleen bij eerste toegang) en directe JSI-aanroepen zonder JSON-serialisatie. De ontwikkelaar schrijft een TypeScript-spec, voert Codegen uit en implementeert het gegenereerde native interface.

V5: Beschrijf Bridgeless Mode en wat het verwijdert in vergelijking met alleen Fabric en TurboModules.

Zelfs na de adoptie van Fabric en TurboModules initialiseerde de oude bridge nog bij het opstarten om globale event-emitters, timers, foutafhandeling en andere runtime-infrastructuur te beheren. Bridgeless Mode vervangt deze resterende bridge-afhankelijke systemen door JSI-gebaseerde implementaties. Het elimineert de overhead van bridge-initialisatie, vermindert het basisgeheugengebruik en zorgt ervoor dat de gehele runtime via JSI opereert. Sinds React Native 0.85 is Bridgeless Mode de enige operationele modus.

Het oefenen van deze vragen met werkende codevoorbeelden versterkt zowel het conceptuele begrip als de praktische herinnering.

Conclusie

• Hermes V1 levert 29% snellere cold starts, 38% lager geheugengebruik en GC-pauzes onder 12ms standaard in React Native 0.84+
• Fabric maakt concurrent-features van React 19 mogelijk (transitions, Suspense) die Paper nooit kon ondersteunen
• TurboModules elimineren JSON-serialisatie en maken JS-naar-native-aanroepen 40x sneller door directe JSI-aanroep
• Bridgeless Mode verwijdert de laatste bridge-afhankelijkheden; React Native 0.85 bevat nul bridge-code
• Het ecosysteem is volledig compatibel: Expo SDK 55+, React Navigation 7.2+, Reanimated 3.5+ en alle grote bibliotheken ondersteunen de New Architecture exclusief
• Interviewvoorbereiding moet zich richten op JSI-mechanica, Fabric-vs-Paper-afwegingen, de TurboModule-Codegen-workflow en Bridgeless-Mode-runtime-wijzigingen