DEV Community

Nina Kitsu
Nina Kitsu

Posted on

Runtimes JavaScript [pt-br]

Para desenvolver e/ou rodar uma aplicação local JavaScript você precisa instalar um Runtime localmente.

Mas o que é um runtime?

A palavra em si pode significar muitas coisas na área da computação. Porém um significado em específico será utilizado aqui, que é o de ambiente de runtime.

Este ambiente de runtime é a base, a interface que lida entre seu programa e a máquina, que pode ser local, virtual, na nuvem...

Um famoso runtime é o Ambiente de Runtime do Java, do inglês Java Runtime Environment, também conhecido por sua sigla JRE. Simplificando, este é responsável por rodar uma aplicação Java na Máquina Virtual do Java.

Então pro JavaScript teria algo como um ambiente de Runtime JavaScript, certo? SIM! Mas sendo este artigo sobre ferramentas, listarei apenas as que rodam direto numa máquina e não num navegador.

Infelizmente nenhuma ferramenta tem um nome sugestivo sendo sigla do que ele faz. Mesmo porquê teria as mesmas iniciais da Runtime do Java. Mas os desenvolvedores das runtimes foram até que criativos.

Node.js

Este é o mais famoso runtime JavaScript e um dos primeiros a existir fora do navegador.

Ele foi desenvolvido em cima do interpretador V8, criado pelo Google, o mesmo interpretador de código JavaScript embutido nos motores de renderização Blink, presente em navegadores Chrome e outros navegadores baseados na versão de código aberto Chromium.

Confuso né?

Abaixo uma caixa com o V8, acima dele uma linha separando verticalmente. De um lado, denominado máquina, tem uma caixa escrito Node.js, do outro lado, denominado navegador, tem duas caixas. Acima, escrito Chrome/Chromium e no meio, Blink

Diagrama comparando o navegador com o Node.js

Assim tornou-se possível rodar aplicações escritas em JavaScript fora do navegador. E aplicações de diversas naturezas. Aqui abordo ferramentas, porém devido ao seu suporte para diversos sistemas operacionais, o Node também pode ser usado para criar aplicações web para servidores e até mesmo ser utilizado em controle de dispositivos IoT.

Infelizmente este artigo não é focado em desenvolvimento utilizando Node.js. Existem diversos artigos e cursos espalhados pela Internet. Irei focar nos executáveis em si.

Existem outros runtimes para ambientes JavaScript?

Sim, e citarei duas que estão dominando as discussões ultimamente (no momento de escrita deste artigo).

Deno

DENO LOGO

Desenvolvido pelo mesmo criador do Node.js, Ryan Dahl. Escrito em Rust e também tendo como base o motor JavaScript V8.

A motivação da criação desta nova runtime foram alguns arrependimentos do criador em relação a decisões tomadas quando o Node foi criado. O Deno foi anunciado em 2018, quase 10 anos após o lançamento do Node.

Abaixo o vídeo, em inglês somente, da talk do Ryan Dahl com o título de "10 Coisas que me arrependo sobre o Node.js".

Dentre estas melhorias:

  • Rodar TypeScript e usar ES6 por padrão;
  • Não requer um gerenciador de pacote, a resolução de módulos é feita por URLs;
  • Melhor controle de permissões...

Em 2020 foi lançada sua primeira versão estável.

Bun

BUN LOGO

Já o Bun, criado em 2021 pelo Jarred Sumner, tenta ir por outro caminho diferente do Node/Deno.

Ao invés de ter como base o V8, o Bun utiliza como base de seu interpretador o Webkit, presente no navegador Safari. E foi programado em Zig, outra linguagem de programação low-code voltada a performance, como o Rust.

Suporta TypeScript e JSX por padrão e possui um instalador eficiente compatível com npm.

Porém como toda novidade, este runtime ainda está em fase experimental, sem lançamento de uma versão estável.

Diferenciais

Uma premissa de ambos desde sua concepção foi serem criados com suporte ao TypeScript. Muito do que a linguagem evolui sobre padrões EcmaScript da TC39 é também atrelado a este suporte ao TS, já que o próprio TypeScript acaba adotando como padrão as evoluções das propostas da ES. Logo também é padrão a utilização de ESModules.

O Bun está em estágio experimental e é o caçula dos runtimes. Podem ter funcionalidades, bibliotecas e ferramentais que ainda não possuam suporte.

Um diferencial que considero legal de se citar do Deno é que desde sua criação teve-se uma preocupação maior sobre permissões. Ou seja, ao rodar uma aplicação feita em Deno, é preciso prover explicitamente permissões ao rodar a aplicação. Pode até ser algo que parece irritante durante o desenvolvimento esquecer de dar alguma permissão, porém evita que alguma dependência execute certos scripts, maliciosos ou não.

Conclusão

Como tanto o Deno quanto o Bun são runtimes um tanto recentes e não cheguei a estudar profundamente.

Se deseja testá-los, é possível instalá-los utilizando o asdf. Ambos possuem plugins já criados:

Links

Top comments (0)