React Native New Architecture nel 2026: Hermes V1, Bridgeless Mode e Domande per Colloqui

La React Native New Architecture ha raggiunto la piena maturità produttiva nel 2026. Con React Native 0.84 che distribuisce Hermes V1 come engine predefinito e la versione 0.85 che rimuove ogni traccia del legacy bridge, il framework offre prestazioni quasi native senza richiedere agli sviluppatori di occuparsi di flag architetturali o livelli di compatibilità.

Cosa è cambiato nello stack architetturale di React Native

La vecchia architettura di React Native si basava su un bridge JSON asincrono single-threaded per passare messaggi tra JavaScript e codice nativo. Ogni interazione attraversava questo collo di bottiglia: eventi touch, calcoli di layout, chiamate ai moduli. La New Architecture sostituisce ogni livello di questa pipeline con un'alternativa diretta e sincrona.

| Livello | Vecchia Architettura | Nuova Architettura | |---------|---------------------|--------------------| | JS Engine | JavaScriptCore | Hermes V1 (bytecode + JIT) | | Renderer | Paper (bridge asincrono) | Fabric (sincrono, C++ condiviso) | | Native Modules | Bridge Modules (serializzazione JSON) | TurboModules (JSI, chiamate dirette) | | Comunicazione | Bridge JSON asincrono | JSI (JavaScript Interface) | | Inizializzazione | Init del bridge + registrazione moduli | Bridgeless (lazy, on-demand) |

JSI (JavaScript Interface) costituisce le fondamenta. Invece di serializzare ogni chiamata in JSON e inviarla attraverso una coda, JSI espone oggetti host C++ direttamente a JavaScript. Una chiamata TurboModule che in precedenza richiedeva codifica JSON, accodamento nel bridge e decodifica JSON, ora si completa come invocazione diretta di funzione.

Hermes V1: Il motore JavaScript predefinito

Hermes V1 è diventato il motore predefinito con React Native 0.84, rilasciato nel febbraio 2026. Si tratta di una riscrittura completa del compilatore e della VM, non semplicemente un aggiornamento incrementale delle versioni precedenti di Hermes.

I miglioramenti coprono quattro aree: un compilatore riscritto con un nuovo formato bytecode, un compilatore JIT migliorato, il garbage collector concorrente Hades e un miglior supporto per i pattern JavaScript moderni utilizzati da React 19.

// 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, il garbage collector concorrente, merita un'attenzione particolare. Le versioni precedenti di Hermes utilizzavano un GC stop-the-world che occasionalmente causava jank visibile durante lo scrolling delle liste. Hades esegue la collection in modo concorrente su un thread in background, mantenendo le pause del GC sotto i 12ms. Per le app che renderizzano liste lunghe con celle complesse, questo elimina l'ultima fonte di frame drop lato JavaScript.

Fabric Renderer: Layout e Rendering Sincroni

Fabric sostituisce il renderer Paper con un core C++ condiviso tra iOS e Android. La differenza critica: i calcoli di layout avvengono in modo sincrono sul thread JavaScript invece che in modo asincrono attraverso il bridge.

Questo modello sincrono abilita due capacità impossibili con Paper:

1. Supporto al rendering concorrente: Fabric si integra con le funzionalità concorrenti di React 19. Transitions, Suspense boundaries e useTransition funzionano correttamente perché Fabric può interrompere e riprendere il rendering.

2. Layout C++ diretto: Yoga (il motore di layout) si esegue nello stesso spazio di memoria del runtime JavaScript. Nessun overhead di serializzazione per i calcoli flexbox.

// 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' },
})

L'hook useTransition in questo esempio dimostra perché Fabric è importante. Con Paper, startTransition non aveva effetto perché il renderer non poteva interrompere un rendering in corso. L'integrazione di Fabric con il concurrent mode di React 19 fa sì che gli aggiornamenti differiti funzionino come progettato, mantenendo il campo di testo reattivo mentre migliaia di elementi vengono filtrati in background.

TurboModules e JSI: Eliminazione dell'Overhead di Serializzazione

I TurboModules sostituiscono il vecchio sistema NativeModules. La differenza prestazionale deriva dall'eliminazione completa della serializzazione JSON. Una chiamata bridge module seguiva questo percorso: oggetto JS -> JSON.stringify -> coda bridge -> JSON.parse -> chiamata nativa -> JSON.stringify -> coda bridge -> JSON.parse -> callback JS. Una chiamata TurboModule è un'invocazione diretta di funzione C++ tramite 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"
}

Il dettaglio fondamentale: getDeviceModel(), getOSVersion() e getBatteryLevel() sono sincroni. Il thread JavaScript chiama direttamente il codice nativo e riceve il valore di ritorno nello stesso tick. Nessuna promise, nessun callback, nessun round-trip del bridge. Questo è possibile solo attraverso JSI.

Bridgeless Mode: Cosa rimuove e perché è importante

Il Bridgeless Mode, introdotto in React Native 0.73 e reso predefinito nella 0.74, completa la migrazione architetturale rimuovendo completamente l'inizializzazione del bridge. Anche dopo l'adozione di Fabric e TurboModules, il vecchio bridge si inizializzava ancora all'avvio per gestire event emitter globali, timer e gestione degli errori. Il Bridgeless Mode sposta questi sistemi residui su implementazioni basate su JSI.

L'impatto pratico:

• Avvio più veloce: Nessun overhead di inizializzazione del bridge. Il runtime avvia solo ciò che l'app effettivamente utilizza tramite lazy loading.
• Memoria ridotta: Nessuna struttura dati del bridge allocata all'avvio.
• Gestione errori più pulita: Le Error Boundaries e i gestori di errori globali funzionano attraverso la nuova architettura senza fallback sul bridge.

React Native 0.82 ha disabilitato permanentemente il vecchio bridge. React Native 0.85, rilasciato nell'aprile 2026, ha rimosso tutto il codice bridge residuo dalla codebase. Non esiste un percorso di fallback.

Migrazione in Produzione: Benchmark Prestazionali Reali

Le migrazioni in produzione dalla vecchia alla nuova architettura mostrano miglioramenti consistenti nelle metriche chiave:

| Metrica | Vecchia Architettura | Nuova Architettura | Miglioramento | |---------|---------------------|--------------------|--------------| | Cold start (TTI) | 1,4s | 0,8s | 43% più veloce | | Transizione schermo | 180ms | 110ms | 39% più veloce | | Memoria baseline | 89MB | 66MB | 26% inferiore | | Chiamata JS-to-native | ~5ms (async) | ~0,1ms (sync) | 40x più veloce | | Pausa GC massima | 45ms | 12ms | 73% più breve | | Scroll FlatList (1000 elementi) | Jank occasionale | 60fps fluidi | Nessun frame perso |

Il miglioramento più impattante per la qualità percepita dall'utente è la riduzione delle pause GC. Hades mantiene le pause di collection sotto il budget di un frame (16,6ms a 60fps), eliminando la fonte più comune di jank visibile nelle app React Native complesse.

Compatibilità dell'Ecosistema nel 2026

L'ecosistema è completamente convergente sulla New Architecture. Expo SDK 55 e versioni successive funzionano esclusivamente sulla New Architecture, senza opzione per disabilitarla. Compatibilità delle librerie principali:

• React Navigation 7.2+: Supporto Fabric completo con schermate native-stack
• Reanimated 3.5+: Backend animazioni condiviso con React Native 0.85
• Gesture Handler 2.16+: Riconoscimento gesture basato su JSI diretto
• Vision Camera 4.0+: Elaborazione frame tramite JSI
• Detox: Test E2E compatibili con la New Architecture

Per i team che utilizzano Expo, npx create-expo-app genera un progetto con la New Architecture abilitata di default. Nessuna configurazione necessaria.

Domande per Colloqui: React Native New Architecture

Queste domande appaiono frequentemente nei colloqui senior React Native nel 2026. Ogni risposta copre la profondità attesa a livello staff/senior.

D1: Spiegare la differenza tra il vecchio Bridge e JSI. Perché JSI permette chiamate native sincrone?

Il bridge serializzava ogni messaggio JS-to-native come JSON, lo inseriva in una coda asincrona e lo deserializzava lato nativo. JSI (JavaScript Interface) espone oggetti host C++ direttamente nella VM JavaScript. Le funzioni native registrate tramite JSI appaiono come normali funzioni JavaScript che eseguono codice nativo inline, senza serializzazione o accodamento. Le chiamate sincrone sono possibili perché JSI opera nello stesso contesto di thread senza una coda messaggi intermedia.

D2: Quale problema risolve il renderer Fabric che Paper non poteva risolvere?

Paper renderizzava in modo asincrono attraverso il bridge, rendendo impossibile il supporto delle funzionalità concurrent di React. Una chiamata startTransition non aveva effetto perché Paper non poteva interrompere un render tree in corso. Fabric implementa il rendering in codice C++ condiviso, si integra direttamente con il reconciler di React 19 e supporta rendering concorrente, Suspense e transitions. I calcoli di layout tramite Yoga avvengono anch'essi in modo sincrono nello stesso spazio di memoria, eliminando la latenza del layout cross-bridge.

D3: Perché Hermes è richiesto per la New Architecture? Si potrebbe usare un altro engine?

La New Architecture dipende da JSI, che richiede che il motore JavaScript supporti la registrazione di oggetti host C++. Hermes è stato progettato da zero con l'integrazione JSI. JavaScriptCore potrebbe teoricamente supportare JSI, ma l'implementazione ufficiale e il testing sono costruiti attorno a Hermes. Hermes V1 fornisce inoltre precompilazione bytecode (elimina il parsing a runtime), il GC concorrente Hades (pause sotto i 12ms) e supporto WebAssembly, nessuno dei quali è disponibile tramite l'integrazione JSC di React Native.

D4: Come differiscono i TurboModules dalla vecchia API NativeModules dal punto di vista dello sviluppatore?

I TurboModules richiedono una spec Codegen (un'interfaccia TypeScript che estende TurboModule) che genera binding nativi type-safe al momento della build. I vecchi NativeModules usavano reflection a runtime senza type checking. I TurboModules supportano valori di ritorno sincroni (non solo promise), inizializzazione lazy (i moduli si caricano solo al primo accesso) e chiamate JSI dirette senza serializzazione JSON. Lo sviluppatore scrive una spec TypeScript, esegue Codegen e implementa l'interfaccia nativa generata.

D5: Descrivere il Bridgeless Mode e cosa rimuove rispetto ad avere solo Fabric e TurboModules.

Anche dopo l'adozione di Fabric e TurboModules, il vecchio bridge si inizializzava ancora all'avvio per gestire event emitter globali, timer, gestione errori e altra infrastruttura runtime. Il Bridgeless Mode sostituisce questi sistemi residui dipendenti dal bridge con implementazioni basate su JSI. Elimina l'overhead di inizializzazione del bridge, riduce l'utilizzo di memoria di base e garantisce che l'intero runtime operi tramite JSI. A partire da React Native 0.85, il Bridgeless Mode è l'unica modalità operativa.

Esercitarsi con queste domande utilizzando esempi di codice funzionanti rafforza sia la comprensione concettuale che la capacità di richiamo pratico.

Conclusione

• Hermes V1 offre cold start più veloci del 29%, memoria inferiore del 38% e pause GC sotto i 12ms di default in React Native 0.84+
• Fabric abilita le funzionalità concurrent di React 19 (transitions, Suspense) che Paper non poteva supportare
• I TurboModules eliminano la serializzazione JSON, rendendo le chiamate JS-to-native 40x più veloci tramite invocazione JSI diretta
• Il Bridgeless Mode rimuove le ultime dipendenze dal bridge; React Native 0.85 non contiene codice bridge residuo
• L'ecosistema è completamente compatibile: Expo SDK 55+, React Navigation 7.2+, Reanimated 3.5+ e tutte le librerie principali supportano la New Architecture in esclusiva
• La preparazione ai colloqui dovrebbe concentrarsi sulla meccanica JSI, i trade-off Fabric vs Paper, il workflow Codegen dei TurboModules e le modifiche runtime del Bridgeless Mode