Bridge e Bridgeless: como o React Native conversa com o nativo (e por que isso mudou)

🚀 Contexto: Este artigo compara o Bridge (arquitetura antiga) com o modo Bridgeless (New Architecture, padrão a partir do RN 0.76).o. A ideia é construir o modelo mental certo: entender o que existia entre o seu JavaScript e o código nativo, por que isso custava caro, e o que mudou.

Você já chamou uma função nativa. Sabe o que acontece no meio do caminho?

Toda vez que você usa AsyncStorage, abre a câmera, lê um sensor ou chama qualquer lib nativa, o seu JavaScript precisa conversar com código nativo (Kotlin no Android, Swift no iOS). São dois mundos diferentes, rodando em threads diferentes, escritos em linguagens diferentes.

A pergunta deste artigo é uma só:

O que existe no meio do caminho entre “eu chamei a função” e “o valor voltou”?

Por quase uma década, a resposta foi: o Bridge. A partir do RN 0.76, a resposta padrão virou: nada — uma chamada direta via JSI.

Entender essa troca é entender o coração da New Architecture. E você não precisa de uma linha de código pra isso — precisa da analogia certa.

Os dois mundos que precisam se falar

Independente da arquitetura, sempre existem dois lados:

A única coisa que muda entre Bridge e Bridgeless é aquela seta no meio. Todo o resto do artigo é sobre o que ela é em cada arquitetura.

O Bridge: uma agência dos correios entre JS e Nativo

A melhor forma de entender o Bridge é pensar nele como uma agência de correios.

Quando o JavaScript quer pedir algo ao nativo, ele não fala diretamente. Ele:

1. Escreve uma carta — empacota o pedido (nome do módulo, nome do método, argumentos) em JSON, um formato de texto que os dois lados entendem.
2. Coloca na caixa de saída — a mensagem entra numa fila.
3. Espera o carteiro — de tempos em tempos, o Bridge despacha um lote de cartas de uma vez (batch).
4. O outro lado lê a carta — o nativo desempacota o JSON, executa o trabalho.
5. A resposta volta pelo mesmo caminho — outra carta, outra fila, outra viagem de volta.

Três características que definem o Bridge

• Assíncrono por natureza. Como a carta entra numa fila e o carteiro passa em lotes, você nunca recebe a resposta “na hora”. Por isso quase tudo no mundo bridge devolve Promise. Não é capricho da API — é a arquitetura.
• Tudo vira texto (JSON). Até um número simples vira texto, é transmitido e parseado de volta. Isso se chama serialização, e é o imposto principal do Bridge.
• Sem tipos. O nome do módulo e do método são strings. Se você errar uma letra, ninguém avisa em tempo de compilação — só estoura em produção.

Por que isso custava caro

Aqui está o ponto mais importante do artigo, e ele é contra-intuitivo:

O Bridge não era lento por chamada. Ele era lento por frequência.

Mandar uma carta é instantâneo na percepção humana — alguns microssegundos. Se você chama uma função nativa uma vez quando a tela abre, o Bridge é perfeito. Você nunca vai notar.

O problema aparece quando você precisa mandar muitas cartas, muito rápido. Pense em:

• Uma animação que atualiza posição a cada frame
• Um gesto de arrastar, que dispara dezenas de eventos por segundo
• Um scroll que precisa reager em tempo real

A tela atualiza 60 vezes por segundo. Isso te dá ~16 milissegundos por frame pra fazer tudo. Se cada interação precisa de várias idas e voltas pelo Bridge — cada uma com serialização JSON, espera na fila e troca de thread — o imposto se acumula e estoura o orçamento do frame. O resultado é o que todo mundo já sentiu: a animação engasga.

Custo de UMA chamada:        invisível  (µs)
Custo de 60 chamadas/seg:    perceptível
Custo numa animação fluida:  o frame estoura → engasga

Some a isso outras dores estruturais:

Limitação do BridgeConsequência práticaSerialização JSON em toda chamadacaro em alta frequênciaAssíncrono obrigatóriodifícil ter resposta “na hora”Sem tipagem (strings nas pontas)bugs só aparecem em runtimeTroca de thread obrigatóriaoverhead mesmo em operações triviaisTodos os módulos carregam no bootcold start mais lento

Essas cinco dores foram exatamente o que motivou a New Architecture.

A virada: do correio para o telefone

Se o Bridge é uma agência de correios, o JSI (JavaScript Interface) é uma linha telefônica direta.

Em vez de escrever uma carta, colocar na fila e esperar, o JavaScript agora liga direto para o nativo e fala na hora. Sem envelope (sem JSON), sem fila, sem carteiro.

Tecnicamente, o JSI é uma camada em C++ que permite ao JavaScript chamar funções nativas como se fossem funções JavaScript comuns, e até compartilhar memória entre os dois mundos sem copiar nada. A “seta no meio” deixou de ser uma fila e virou uma chamada de função direta.

Isso destrava três coisas que o Bridge não conseguia:

1. Chamadas síncronas baratas. Como não há fila, dá pra receber o valor na hora — sem Promise, sem hack.
2. Sem serialização. O argumento não precisa virar texto JSON e voltar. Ele é acessado direto na memória.
3. Múltiplas runtimes JavaScript. É isso que permite o código rodar em outra thread (a base dos worklets do Reanimated — assunto do artigo anterior).

Bridgeless na prática: o que muda no dia a dia

“Bridgeless” é o nome do modo da New Architecture em que o Bridge simplesmente não existe mais. Toda a comunicação passa pelo JSI. Três peças sustentam isso:

TurboModules — a evolução dos Native Modules. São os módulos nativos acessados via JSI. Duas mudanças grandes:

• Carregamento preguiçoso (lazy). No Bridge, todos os módulos eram instanciados no startup, mesmo os que você nunca usava — peso morto no boot. TurboModules são criados só na primeira vez que você os usa. Cold start mais rápido.
• Tipagem real. O contrato do módulo é descrito num arquivo tipado, e uma ferramenta chamada Codegen gera a “cola” nativa a partir dele. Um erro de tipo ou de nome vira erro de build, não um crash misterioso depois.

Fabric — o novo renderizador, que coloca a montagem das telas também sobre o JSI, permitindo cálculos de layout síncronos e incrementais (sem a antiga “Shadow Thread” separada).

Codegen — o gerador que lê suas especificações tipadas e produz o código nativo de ligação, garantindo que JS e nativo concordem sobre os contratos antes mesmo do app rodar.

Quando isso realmente importa pra você

Seja honesto sobre o impacto — ele não é uniforme:

SituaçãoNo BridgeNo BridgelessChamada nativa esporádica (1x por tela)imperceptívelimperceptívelComunicação em alta frequência (por frame)engasgafluidoCold start com muitas libs nativasmais lentomais rápido (lazy)Erros de contrato JS ↔ Nativosó em runtimebarrados no buildPrecisar de um valor nativo “na hora”hack arriscadonatural via JSI

A mensagem: para um app simples com poucas interações nativas, você talvez nunca tenha sentido o Bridge. Para apps com animações ricas, gestos complexos, muitas libs nativas ou interações em tempo real, a diferença é a fronteira entre “engasga” e “60 FPS”.

Conclusão: o Bridge funcionou — e ensina por que o JSI ganhou

O Bridge não foi um erro de projeto. Ele sustentou o React Native por quase uma década e ainda roda em milhares de apps em produção sem problema. Para a maioria das chamadas — esporádicas e tolerantes a assincronismo — ele continua sendo mais que suficiente.

O que ele cobrava era um imposto fixo por mensagem: serialização em JSON, fila assíncrona e troca de thread. Invisível numa chamada isolada. Caro a 60 frames por segundo.

O Bridgeless ataca cada ponto dessa lista:

• ❌ Bridge: escreve a carta → fila → lote → lê a carta → resposta pelo mesmo caminho
• ✅ JSI: liga direto → fala → valor na hora, tipado, sem serialização

E é aqui que a peça se encaixa com o artigo anterior: o SharedValue do Reanimated e os TurboModules são a mesma família. Os dois nascem do JSI criando uma ponte de memória direta entre JavaScript e nativo, sem a fila serializada no meio. Worklets levam código para a UI thread; TurboModules trazem funções nativas direto pro JavaScript. A tecnologia por baixo é a mesma.

Performance no React Native não é sobre uma lib mágica. É sobre entender o que existe naquela seta entre os dois mundos — e a New Architecture, basicamente, apagou a seta.

E você? Já sentiu o cold start melhorar ao migrar pra New Architecture? Já teve uma animação que só ficou fluida depois do Reanimated? Conta nos comentários. 🚀

Tags: react-native, bridge, bridgeless, turbomodules, jsi, new-architecture, mobile-architecture, mobile-development