Ant, runtime JavaScript leve e ecossistema

 (antjs.org)
1 pontos por GN⁺ 1 일 전 | 1 comentários | Compartilhar no WhatsApp
  • Executa pacotes npm reais com o Ant Silver Engine, desenvolvido internamente, destacando-se por um binário único de cerca de 8,6 MB e inicialização rápida
  • Não é uma estrutura que envolve V8, JSC ou SpiderMonkey; indica 100% no compat-table e conformidade com WinterTC, além de oferecer suporte a Hono, Elysia, TypeScript, React, Rolldown, Wasm e outros
  • Em uma medição de cold start que carrega o Hono, registra 2 rotas e encerra, registrou 5,4 ms, menos que Bun com 12,8 ms, Deno com 24,8 ms e Node.js com 31,1 ms
  • Instala pacotes até 40 vezes mais rápido que o npm, e não exige build separado nem adaptador de framework graças à execução direta de TypeScript e ao serviço do export fetch padrão
  • Oferece um sandbox com isolamento por VM para código não confiável e o registro público ants.land compatível com o protocolo npm; pode ser usado em arm64 e x86_64 no macOS e Linux sem toolchain separada

Engine própria e fluxo de desenvolvimento rápido

  • Ant é um runtime JavaScript de alto desempenho construído do zero, distribuído como um binário único portátil de cerca de 8,6 MB que inclui o Ant Silver Engine
    • Não é um wrapper baseado em V8, JSC ou SpiderMonkey
    • Registra 100% no compat-table e é indicado como WinterTC Conformant
    • Executa os ecossistemas Hono, Elysia, TypeScript, React, Rolldown, WinterTC e Wasm

  • Desempenho de cold start

    • Carrega o Hono, registra 2 rotas e encerra, medindo apenas o custo de resolução e inicialização de módulos
    • Ant: 5,4 ms
    • Bun: 12,8 ms
    • Deno: 24,8 ms
    • Node.js: 31,1 ms

  • Instalação de pacotes

    • É possível instalar pacotes com o comando ant i hono; no exemplo, a instalação de 1 pacote hono@latest termina em 155 ms
    • Destaca velocidade de instalação até 40 vezes maior que a do npm, sem necessidade de configurar uma ferramenta separada de gerenciamento de pacotes

  • Servidor e execução de TypeScript

    • Como serve o export fetch padrão do arquivo como servidor, frameworks como Hono podem ser executados sem adaptador
    • Arquivos TypeScript podem ser executados diretamente com ant app.ts
      • Não são necessários ajustes de tsconfig, bundler, diretório dist nem a etapa tsc && node dist/app.js

Execução isolada e ecossistema de pacotes

  • Sandbox baseado em VM

    • O Sandbox de ant:sandbox executa JavaScript não confiável dentro de uma fronteira de isolamento por VM, indo além de uma simples verificação de permissões
    • Cada sandbox usa uma VM KVM ou Hypervisor.framework independente
    • Montagens do sistema de arquivos permanecem somente leitura, a menos que permissão de escrita seja concedida explicitamente
    • A rede é bloqueada por padrão, e apenas as portas especificadas são encaminhadas

  • Registro público de pacotes

    • ants.land é um registro público de pacotes para Ant
    • Usa o protocolo npm, permitindo acesso não só pelo Ant, mas também por npm, Yarn, pnpm e Bun
    • Pacotes são instalados por escopo ou nome comum, e também podem ser usados no navegador por meio de esm.ants.land
    • Faça login com ant land login e publique pacotes com ant land publish
    • As informações do registro incluem uma pontuação de 0 a 100 que reflete documentação, licença e compatibilidade
    • Oferece suporte a arm64 e x86_64 no macOS e Linux, sem necessidade de toolchain separada

Leituras relacionadas

1 comentários

 
GN⁺ 1 일 전
Comentários do Hacker News

  • Eu programo com IA o dia todo, todos os dias, mas acho que esta questão, levantada em março passado, ainda vale ser considerada
    Mesmo que o código tenha sido reescrito depois, dizer que foi “feito do zero” incomoda um pouco, já que a base de código AGPL existente representou uma parte significativa do trabalho inicial
    Pelo que consta na thread, depois que a versão antiga foi descartada, os autores originais não pareceram se importar muito, e o código atual parece de fato ter sido reescrito, com forma e estrutura diferentes. No geral, gosto muito do trabalho, então sigam em frente, mas todos precisam ter cuidado

    • No entanto, este texto não parece ter sido escrito por alguém que realmente implementou um motor JavaScript
      Dá a impressão de que pegaram o histórico de commits de um LLM que aparentemente trouxe código de outros motores JavaScript e pediram a outro LLM que transformasse isso em um post de blog; é difícil até entender o que aconteceu, e mais difícil ainda confiar no projeto
    • Essa questão apontava para o código de dezembro de 2025, quando o projeto era totalmente diferente do que é agora
      Por volta de fevereiro, a base de código anterior foi praticamente apagada e um sistema muito mais confiável foi projetado do zero. Eu sabia que o código daquela época era quase inteiramente geração de IA de baixa qualidade, mas isso não era a maior prioridade; hoje, nenhum código passa sem revisão e testes

  • Já existe o Ant da Apache, então fico me perguntando por que chamaram de Ant em vez de “Antjs” ou “Ant.js”: https://ant.apache.org

    • Mesmo no ecossistema JavaScript, o nome já está ocupado pelo grande Ant Design: https://ant.design/
    • Parece o tipo de nome que você escolheria se quisesse causar uma má primeira impressão em quem programa há décadas
    • Quando James entregou o Apache Ant, eu fui o primeiro usuário e colaborador de fora da Sun Microsystems, mas não me incomoda nem um pouco que outra pessoa use o mesmo nome
    • Achei que fosse um framework do Ant Group, da Alibaba, já que o Ant Design também veio de lá

  • O processo de criar a primeira versão em um mês está no primeiro texto, e o acompanhamento alguns meses depois está no segundo texto
    Não sei se faz sentido economicamente criar um novo runtime e ecossistema do zero, mas parece que já entramos numa fase em que um software que antes exigia uma equipe inteira agora pode ser feito por um único desenvolvedor, e isso é só o começo

    • Está explicitamente escrito que o motor, Ant Silver, foi feito internamente
    • Se isso for só um LLM despejando código aprendido dos dados de treino, não é tão impressionante assim
      Quero ver desenvolvedores solo criando software realmente novo, algo que nem equipes conseguiam fazer antes. Sou muito favorável à IA, mas já estou cansado da promoção exagerada constante

  • Eu brinquei que a CLI ant da Anthropic não estava nem aí para o Apache ant, e agora apareceu até o ant do JavaScript

    • Achei que eu era o único que ainda lembrava do Apache Ant. Os nomes estão se esgotando, mas Ant foi uma ferramenta fundamental muito influente
    • Nunca vi uma única pessoa usando a CLI ant da Anthropic

  • Não conheço profundamente o ecossistema JavaScript nem runtimes, mas fiquei um pouco surpreso ao ver promessas de tamanho menor, inicialização rápida, sandboxing e desempenho competitivo ao mesmo tempo
    Fico curioso sobre qual seria a sacada central ou escolha de design que torna possível obter essas vantagens em relação a stacks JavaScript já maduras e altamente otimizadas, qual foi a grande aposta técnica

    • Como mencionado em outra parte da thread, este projeto parece ser uma reescrita por LLM do Elk, iniciado em 2019: https://github.com/cesanta/elk
    • O Deno já oferece praticamente tudo o que aparece aqui, mas é um projeto maduro e sério, escrito antes da era dos LLMs e sustentado por uma equipe sólida
      Talvez não seja o mais rápido, mas é difícil adotar um novo runtime só porque ele é “mais rápido que X”. As escolhas de design deste projeto parecem ser resultado de Claude ou Codex copiando grandes partes da base de código do Elk

  • Entendo o runtime, o motor e a monetização via Colony, mas não sei se precisava também de um registro separado, um gerenciador de pacotes separado, Ant Desktop, sandbox, e ainda esse treatjs de identidade duvidosa
    Se é um runtime JavaScript, eu preferiria que fizesse uma única coisa, executar JavaScript, e a fizesse bem; fico me perguntando por que todo mundo quer virar uma caixa de ferramentas integrada, e este projeto já parece complexo demais

  • Dizem que está em velocidade próxima à do V8, mas no benchmark do zoo.js isso parece estar bem longe: https://zoo.js.org/
    A menos que o desempenho tenha melhorado drasticamente desde 10 de fevereiro de 2026, essa afirmação não parece correta

    • Desde fevereiro, o motor foi praticamente todo reescrito, e o desempenho melhorou bastante
      Na época, ele funcionava majoritariamente como interpretador e ainda faltavam várias operações de JIT; em breve, pretendemos incluir benchmarks também nas builds nightly

  • A primeira coisa que me chamou atenção foi o sandboxing. Não sei por que Node e npm não oferecem isso por padrão; ajudaria bastante a reduzir worms e ataques à cadeia de suprimentos

    • Segundo a explicação no fim da página, o VM em “VM isolated sandbox” não se refere à máquina virtual JavaScript, e sim a um hipervisor
      Se você já estiver rodando dentro de uma máquina virtual e ainda precisar de virtualização aninhada, nem está claro se haverá suporte, e também não parece algo que vá ser rápido ou eficiente
    • O Deno já tem isso. Não sou afiliado, só um usuário satisfeito

  • Fiquei curioso sobre qual é a fonte serifada usada no site. Parece que renomearam para ant_serif e removeram todos os outros identificadores, mas ela é bem bonita

    • Isso parece ser um padrão recorrente do autor original: usar coisa roubada

  • Há benchmark de cold start, mas por que não existe comparação de desempenho de execução com Node, Deno, Bun, QuickJS etc.?