JavaScript é interpretado ou compilado em tempo de execução?

Neste artigo você vai aprender se JavaScript é interpretado ou compilado quando o código é executado no navegador, e também a diferença de ambas as abordagens.

Resposta curta: JavaScript é as duas coisas, interpretado e compilado, no mesmo código e em tempo de execução

A MDN define JavaScript como uma linguagem interpretada ou compilada just-in-time (JIT), e é exatamente isso que acontece na prática

No V8, o motor open source de JavaScript e WebAssembly do Google (escrito em C++, usado no Chrome e no Node.js), todo código JS é primeiro compilado para bytecode do Ignition e executado por interpretação

Enquanto interpreta, o motor coleta metadados da execução e usa esse feedback pra recompilar os trechos quentes em código de máquina, o famoso JIT

Hoje o pipeline do V8 tem quatro camadas: Ignition (interpretador), Sparkplug (baseline), Maglev (otimizador intermediário) e TurboFan (otimizador de pico)

Então: a execução começa interpretada e vira código de máquina compilado durante a corrida, e quem decide isso é o motor, não a linguagem

Fala programador(a), bora aprender mais sobre a forma de execução da linguagem JavaScript!

Interpretação x compilação

Primeiro vamos entender a diferença entre interpretação e compilação

A interpretação tem como objeto transformar o código de uma linguagem em linguagem de máquina para assim ser executado

Podemos dizer que é feita uma tradução do código

Já a linguagem compilada é lida diretamente do seu código fonte e executada, por meio de um compilador

Apesar da linha tênue entre os dois conceitos, as linguagens compiladas acabam sendo mais rapidamente executadas pela ausência da etapa de tradução

E em JavaScript?

A linguagem JavaScript hoje pode ser considerada compilada em tempo de execução, pois foi introduzido aos navegadores a compilação JIT (Just-in-time compilation)

Os compiladores de JavaScript mais conhecidos são o V8 e o Rhino, que transformam o código para C++ e JAVA Bytecode

E estes compiladores suportam e utilizam o JIT nas suas estratégias de compilação

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Conclusão

Neste artigo vimos se o código JavaScript é interpretado ou compilado

Como citado no artigo por casa da adição de compiladores como V8 e Rhino, que usam a abordagem JIT

A linguagem JS pode ser considerada compilada, pois é justamente o que este padrão de arquitetura propõe

Confira também nosso catálogo de cursos gratuitos, com aulas semanais no YouTube

Como o V8 executa o seu código, passo a passo:

O V8 é o motor open source de JavaScript e WebAssembly do Google, escrito em C++, e é ele que roda dentro do Chrome e do Node.js

Antes de sair falando de JIT, se liga na ORDEM das coisas, porque é aqui que quase todo mundo se perde

Todo código JavaScript é primeiro compilado para bytecode do Ignition, e esse bytecode é executado por interpretação

Enquanto interpreta, o motor vai coletando metadados da execução: o que é chamado toda hora, que tipo de valor aparece em cada ponto, e por aí vai

Esse feedback alimenta o compilador otimizador, que recompila os trechos quentes para código de máquina

Ou seja, o V8 usa compilação JIT para código nativo imediatamente antes da execução, com um compilador baseline rápido e depois recompilação dinâmica por um otimizador mais avançado

Então não é interpretado OU compilado: é interpretado primeiro e compilado depois, no meio da corrida 🙂

As quatro camadas do V8: Ignition, Sparkplug, Maglev e TurboFan

O pipeline atual do V8 tem quatro camadas de compilação, e cada uma existe por um motivo diferente

Se você já dirigiu carro com câmbio manual, é a mesma ideia: começa na marcha leve pra sair do lugar e vai subindo conforme ganha velocidade

1. Ignition: o interpretador, roda o bytecode e coleta feedback

2. Sparkplug: o compilador não otimizador (baseline), que chegou no V8 v9.1 e foi liberado no Chrome 91. Ele compila a partir do bytecode já gerado, e não do código fonte, e trouxe ganho de 5% a 15% em benchmarks de mundo real

3. Maglev: o otimizador intermediário, introduzido no Chrome M117 e disponível no Chrome desktop. Ele gera código cerca de 20x mais devagar que o Sparkplug, mas de 10x a 100x mais rápido que o TurboFan, e rendeu +8,2% no JetStream, +6% no Speedometer e cerca de 10% de economia de energia no Speedometer

4. TurboFan: o otimizador de pico, o mais caro de rodar e o que gera o código mais rápido

Massa perceber que o motor não escolhe UMA estratégia: ele escolhe a estratégia certa pra cada pedaço do seu código, enquanto o site já está rodando

E nos outros navegadores, funciona igual?

A arquitetura em camadas não é exclusividade do Chrome, beleza?

No Firefox, o SpiderMonkey sobe de camada conforme o script esquenta: Baseline Interpreter, depois Baseline JIT e no topo o WarpMonkey, que substituiu o IonMonkey e trabalha com inlining e especialização. O Warp foi entregue pela Mozilla no Firefox 83, construindo as otimizações em cima dos dados de Inline Cache

No Safari, o JavaScriptCore tem quatro camadas de execução: LLInt (interpretador de bytecode), Baseline JIT, DFG JIT (otimizador de baixa latência) e FTL JIT (otimizador de alta vazão)

E fora do navegador tem caso curioso: o Bun é um runtime de JavaScript movido pelo JavaScriptCore, o motor do Safari, e não pelo V8. Ele até expõe o módulo bun:jsc com APIs de baixo nível do motor

Ou seja, o mesmo código JS que você escreve pode passar por pipelines bem diferentes dependendo de onde roda

Dá pra rodar JavaScript sem JIT?

Dá sim, e esse é o melhor jeito de provar que a interpretação nunca sumiu da jogada

O V8 pode rodar em modo sem JIT: com a flag –jitless não há alocação de memória executável em tempo de execução, e todo o código JavaScript do usuário roda no interpretador Ignition

E isso não é só brincadeira de quem mexe no motor: o Chrome expõe um controle de otimização de JavaScript pro usuário comum, em Configurações > Privacidade e segurança > Segurança > Gerenciar otimização e segurança do JavaScript

Com o Programa de Proteção Avançada do Google ativado, as otimizações de JavaScript ficam desligadas, tanto no desktop quanto no Android

Tome cuidado ao tirar conclusão apressada aqui: menos otimização é uma troca entre superfície de ataque e desempenho, não um "modo turbo" escondido

Onde o Rhino entra nessa história:

O Rhino é uma implementação open source de JavaScript escrita inteiramente em Java, mantida no repositório github.com/mozilla/rhino

E ele é o exemplo mais didático do assunto deste artigo, porque nele os dois modos são uma configuração explícita

Com optimization level -1 ele roda em modo interpretado, sem gerar arquivos .class

Com níveis de 0 a 9 ele compila para bytecode Java

Mesma linguagem, mesmo código, e a resposta pra "interpretado ou compilado?" muda conforme o nível que tu escolhe

A versão estável mais recente é a 1.9.1, publicada em 15 de fevereiro de 2026

Por que a resposta certa é "depende do motor":

A especificação da linguagem descreve o comportamento do JavaScript, não obriga ninguém a interpretar nem a compilar

A edição mais recente é o ECMAScript 2026 (ECMA-262, 17ª edição), aprovada pela Ecma International em 30 de junho de 2026, e o texto oficial fica em tc39.es/ecma262/2026/

Quem decide a estratégia é a implementação: V8, SpiderMonkey, JavaScriptCore, Rhino, cada um com o seu pipeline

Por isso a MDN define JavaScript como uma linguagem interpretada ou compilada just-in-time, com as duas possibilidades na mesma frase

E fora do navegador vale a mesma lógica: o Node.js 26.0.0, lançado em 5 de maio de 2026, traz o V8 14.6.202.33, vindo do Chromium 146. Hoje o Node.js 24 é o Active LTS, o 22 está em manutenção e o 26 é a linha Current, com entrada em LTS prevista para outubro de 2026

Mesmo motor do Chrome, mesma história de interpretar e compilar 😀

Um adendo pessoal antes de fechar, porque essa pergunta quase sempre vem de quem está começando

Dominar é uma palavra muito forte

O que acontece com programador em nível alto é se sentir confortável com a linguagem, e não guardar tudo de cabeça

Você não precisa decorar as quatro camadas do V8 pra escrever bom JavaScript

O ponto ideal é: apareceu o problema, eu sei com qual recurso resolver, e se travar eu abro a documentação, pesquiso, pergunto pra IA quando a dúvida for cabulosa

Saber que o motor interpreta primeiro e otimiza depois muda o jeito de você ler um gargalo, e isso vale mais que decorar nome de compilador

O que ainda falta medir por aqui, e eu prefiro não chutar: comparar o mesmo script com as otimizações ligadas e no modo sem JIT do V8, no meu ambiente, pra falar de diferença com número na mão. Quando eu rodar isso, atualizo o post =)