React Native Bridgeless + Hermes — What Actually Changed

The "New Architecture" stopped being new. It became the architecture. React Native 0.76 made it default in late 2024. Expo SDK 52 followed weeks later. By early 2026, every new app is bridgeless, Fabric-rendered, TurboModule-driven, and Hermes-engined—and most teams haven't actually internalized what that means.

This is the part that gets glossed over in the migration guides. What actually changed, where the wins are real, and where the pain still lives.

The Old Mental Model

For five years, React Native was: JavaScript thread ↔ async JSON bridge ↔ Native thread. Every native call was serialized to JSON, queued, and processed asynchronously. Layout calculations happened on a third thread. Animations on the JS thread paid a serialization tax for every frame.

This is the model every "Why is React Native slow?" Hacker News thread was about. It wasn't slow because of React. It was slow because of the bridge.

What Bridgeless Actually Is

Bridgeless mode removes the asynchronous JSON bridge entirely. Instead, JavaScript and native code share a synchronous, type-safe interface called JSI (JavaScript Interface). Hermes exposes itself through JSI directly. Native modules expose themselves as TurboModules. The renderer (Fabric) talks to native views through ShadowNodes that exist in C++.

The practical consequences are not subtle:

• Synchronous native calls. You can now call native code and get a result on the same tick. The old async pattern still works, but for things like measuring a view, reading a config value, or accessing a native data source, the synchronous path is dramatically simpler.
• No JSON serialization. Strings stay as strings, numbers as numbers, JS objects as JS objects. The bridge isn't there to translate them. CPU and memory savings are meaningful on data-heavy paths.
• Concurrent rendering. Fabric supports React 18's concurrent features properly. useTransition, Suspense, and selective hydration finally work the way they do on web.
• C++ shadow tree. Layout happens in C++, off the JS thread. Animations driven by react-native-reanimated v4 run on the UI thread without round-tripping through JS.

The headline number that keeps showing up in benchmarks: 20–40% faster startup, 30–50% fewer dropped frames on heavy scrolls. The bigger win is qualitative: the app stops feeling like a webview pretending to be native.

What Hermes Actually Does

Hermes is now the only JavaScript engine that matters for React Native. JSC (JavaScriptCore) was deprecated for new projects in 2024 and removed from the templates in 2025. Hermes won, and the reasons it won compound:

• Bytecode precompilation. JS gets compiled to bytecode at build time. Startup parses no JavaScript at runtime.
• Smaller heap, smaller binary. Both ship as part of the app. Both are smaller than JSC was.
• Native debugger protocol. Chrome DevTools speaks to Hermes directly. The "JS Debugger" pattern of running JS in a remote Chrome tab is dead.
• Tighter integration with TurboModules. JSI was designed with Hermes in mind. The other engines never got there.
• Ahead-of-time optimization. Hermes can apply optimizations a JIT can't, because it knows the code can't change at runtime.

The trade-off is real: no JIT means peak JS-only performance is slightly lower than JSC with hot loops. For UI work, the loss is noise. For computation-heavy paths, you should be in native code anyway.

The Migration Pain That's Still Real

Most of the "New Arch broke my app" posts in 2025 came down to four problems:

1. Native modules without TurboModule support. A library that only ships an old-style RCTBridgeModule won't work in bridgeless mode. By 2026, the major libraries have migrated. The long tail still hasn't.
2. requireNativeComponent callers. Old-style native components don't render under Fabric. They need a codegenNativeComponent migration. Most UI libraries finished this in 2024-2025.
3. react-native-firebase and similar SDKs. These are migrating but version mismatches between the SDK, your RN version, and your Expo SDK can produce mysterious crashes. Pin everything explicitly.
4. iOS Swift modules using old patterns. The Expo Modules API now wraps the migration cleanly. Hand-rolled modules using RCT_EXPORT_MODULE in Swift need real refactoring.

If you're starting a new project: use Expo SDK 53+, accept the New Arch, and move on. If you're migrating an existing project: budget two weeks for the long-tail dependency cleanup.

The Practical Stack For 2026

What I'm putting in every new RN app:

• Expo SDK 53+ (managed flow, EAS Build, EAS Update)
• react-native-reanimated 4 for animations on the UI thread
• react-native-gesture-handler 2.20+ for touch handling
• expo-router 4 for file-based routing
• react-native-screens with native-stack
• Tanstack Query for server state
• Zustand or Jotai for UI state—keep it small
• NativeWind 5 / Tailwind CSS v4 for styling

This stack is the closest thing to "boring" you can have in mobile right now. Every piece is bridgeless-ready. Every piece is Hermes-friendly. Every piece survived the New Arch transition.

The Quiet Lesson

The New Architecture is the first time React Native delivered on the promise it always made: the cross-platform app that doesn't feel like a cross-platform app. It took a decade. The migration was painful. The result is that the gap between RN and SwiftUI/Compose for normal app workloads is now genuinely small.

If you've been holding off on RN because of the bridge, the reason is gone. Start a new project on Expo SDK 53, turn nothing on, and feel the difference. The old mental model—asynchronous, slow, fragile—doesn't apply anymore.

The architecture finally caught up to the marketing.