Octane compila o modelo de programação do React e dispensa o virtual DOM

O Octane se apresenta como "o modelo de programação do React, compilado". Segundo o site oficial do projeto, ele é o sucessor do Inferno e leva adiante a meta de performance daquele framework, mas com uma proposta diferente: compilar hooks, Suspense e actions do React de forma antecipada (ahead of time), sem virtual DOM.

A ideia central é que o desenvolvedor continue escrevendo componentes como funções comuns, com props, hooks e context, e que o compilador faça o trabalho pesado por baixo dos panos.

O que muda na hora de escrever componentes

São três promessas que mexem diretamente com hábitos consolidados de quem escreve React no dia a dia:

• Sem regras de hooks. Segundo a documentação, os slots dos hooks são atribuídos pelo call site, não pela ordem de chamada. Na prática, isso permite colocar um useEffect dentro de um if ou depois de um early return, algo proibido no React tradicional.
• Sem arrays de dependência manuais. O compilador rastreia o que effects, memos e callbacks realmente usam e infere as dependências. No exemplo do site, um useEffect que lê count tem seu [count] inferido automaticamente.
• Sem virtual DOM. Os templates compilam para nós clonados e escritas diretas no DOM, e listas com @for chaveadas movem o menor número possível de nós.

Os arquivos usam a extensão .tsrx, mas o .tsx comum continua funcionando, o que segundo o projeto permite adotar o framework um componente por vez.

Async e SSR

O Octane também mexe no comportamento assíncrono. De acordo com a fonte, chamadas independentes de use() começam juntas, em vez de suspender uma de cada vez descendo pela árvore. Fetches aninhados são pré-aquecidos e o streaming SSR envia cada boundary assim que ela fica pronta.

O projeto afirma manter o modelo familiar: memo, context, portals, transitions, actions, formulários controlados e Suspense se comportam como esperado, eventos são nativos, refs são apenas props, e há 53 bindings first-party para bibliotecas de estado, dados, roteamento, UI, forms, charts e 3D. O suporte a Three.js, por exemplo, vem via @octanejs/three, descrito como um technical preview de port do React Three Fiber.

Por que não signals?

Essa é uma escolha de arquitetura que o próprio projeto antecipa. Segundo a documentação, signals são "uma boa ferramenta" e podem ser usados dentro de um app Octane quando fazem sentido, mas um framework construído sobre signals força todo app a representar e ler estado "do jeito signals". O Octane prefere manter componentes como funções lidas de cima para baixo, deixando o trabalho extra para o compilador.

Números de performance

O site publica uma grade de benchmarks comparando o Octane (baseline 1×) com React 19, Preact 10, Solid 2.0 beta, Svelte 5, Ripple 0.3 e Vue Vapor 3.6 beta. Pela média geométrica de todas as suites, o React 19 aparece em 2.9× e o Preact em 2.7× (números maiores significam mais lento em relação ao Octane), enquanto Solid e Ripple ficam em 1.1× e o Vue Vapor em 0.86× (mais rápido). Em suites específicas como async-waterfall, o React 19 aparece em 11× e o Preact em 8.7×.

Vale a ressalva editorial de sempre: benchmarks publicados pelo próprio projeto medem cenários escolhidos pelo próprio projeto. O site diz rodar mais de 11.500 execuções de teste no runtime, compilador, SSR e bindings.

Adoção incremental e as armadilhas

Para quem já tem um app React 19, o projeto oferece o OctaneCompat, que permite inserir "ilhas" compiladas do Octane dentro do app existente, com eventos nativos, context real do React e SSR com hydration. A exceção declarada é React Server Components, que não atravessam para o Octane.

A documentação também é honesta sobre falhas silenciosas: como a compilação é ahead of time, uma má configuração tende a degradar em vez de dar erro. Dois exemplos citados são ter duas cópias do runtime na mesma árvore (o que quebra hooks e context em silêncio, já que o estado do hook é chaveado por instância de runtime) e o tsc puro tratando mal arquivos .tsrx. Para isso existe o comando octane doctor, com 20 verificações, e um --fix que repara parte delas.

Para o dev brasileiro

Se o Octane vingar, o impacto prático é direto para times BR que hoje penam com dependências de useEffect e a ginástica das regras de hooks. A promessa de migração componente a componente, sem big bang, reduz o risco de adoção, algo relevante em bases de código legadas comuns por aqui. Por enquanto, o mais sensato é acompanhar a maturidade do ecossistema de bindings e a evolução do projeto antes de apostar em produção. O ponto de partida é o octanejs.dev.

Fonte: Hacker News