18 Ago 2026 · 6 min
The browser is the spatial runtime
Por que hoje eu aposto no navegador como runtime principal para experiências espaciais: WebXR, WebGPU, zero instalação e a disciplina de engenharia que transforma demo em produto.
By Matheus G. Spartalis
A instalação é o primeiro inimigo da imersão
Já vi experiências espaciais morrerem na loja de aplicativos. O usuário encontra um QR code, lê uma promessa de realidade aumentada, e depois precisa aceitar 80 MB de download, permissões de câmera, login e atualização de sistema. A fricção começa antes do valor.
No navegador, o caminho é um link ou uma URL. Isso redefine o produto: você não otimiza o download, otimiza o primeiro segundo de experiência. Eu trato isso como engenharia de distribuição — tão crítica quanto a renderização.
O runtime já está pronto
A WebXR Device API dá acesso consistente a sessões imersivas, tracking de pose, referenciais de espaço e input de controllers. WebGL e WebGPU entregam pipeline gráfico acelerado. Geolocation, DeviceOrientation, WebAudio, WebRTC e WebSockets estão disponíveis sem plugin.
Service Workers e Cache Storage permitem que uma experiência espacial funcione offline ou em conectividade instável — algo que muitos apps nativos ainda não fazem direito. O navegador deixou de ser um leitor de páginas: é um runtime de sistemas operacionais leves.
A disciplina que separa demo de produto
O limite técnico raramente é a API. É o orçamento de performance: draw calls, tempo de frame, carga de texturas, descarte de objetos fora da frustum e degradação elegante para dispositivos modestos. Eu começo sempre pelo menor cenário que prova a hipótese — geralmente uma cena leve, dados reais e uma única interação.
Só depois adiciono profundidade, sensores e camadas de UI. Essa ordem evita o erro clássico do WebXR: uma demonstração impressionante que nunca vira produto operando, porque ninguém mediu latência, memória e conversão antes de investir em produção.