Show HN: Ant – Um runtime JavaScript e ecossistema

Artigo original ↗ Discussão no Hacker News ↗

Escopo e posicionamento do projeto

  • Novo runtime JavaScript e ecossistema que afirma ter tamanho reduzido, inicialização rápida, sandboxing e compatibilidade com Node.
  • Inclui seu próprio engine (“Ant Silver”), registry, gerenciador de pacotes, integração com sandbox/hypervisor e planos para um framework de app desktop e compilação para binário.
  • Alguns acham essa abrangência empolgante; outros veem isso como um projeto jovem e prematuramente “tudo-em-um” e complicado.

Apps desktop e tamanho do binário

  • Interesse em usá-lo como uma alternativa leve ao Electron para empacotar HTML/CSS/JS em apps desktop.
  • Uma ferramenta separada, “ant-desktop”, está em desenvolvimento inicial, atualmente com um renderer apenas para Chromium; WebView e outros backends estão planejados.
  • O binário do runtime foi relatado em cerca de 8 MB, o que gera otimismo em comparação com bundles do tamanho do Electron e perguntas sobre o tamanho dos builds para desktop.

Performance e design do engine

  • Em comparação com o V8, diz-se que o Ant é muito menor devido a tiers de JIT mais simples, ausência de dados Unicode do ICU e nenhum snapshot de inicialização do JS.
  • Benchmarks de um site externo mostram atualmente o Ant muito mais lento e com muito menos compatibilidade com ES6 do que o V8, mas o autor afirma que houve uma reescrita quase total do engine e ganhos recentes de performance.
  • Comentadores pedem benchmarks abrangentes e independentes e fuzzing, especialmente se a meta for competir com engines no nível de V8/LLVM.

Sandboxing e hypervisor

  • O “sandbox isolado por VM” anunciado é implementado via KVM no Linux e Hypervisor.framework no macOS, executando um kernel Nanos modificado.
  • A memória é alocada de forma preguiçosa, com um limite padrão de 256 MB; cerca de 35 MB são usados pelo Ant mais a VM.
  • Alguns são céticos quanto ao desempenho, especialmente com virtualização aninhada; outros veem forte potencial para FaaS e execução mais segura no estilo npm. Suporte ao Windows é pedido, mas não respondido.

Ecossistema (registry, ferramentas, compatibilidade)

  • O Ant planeja seu próprio registry e gerenciador de pacotes; vários comentadores sugerem usar o JSR em vez de criar mais um registry.
  • Compatibilidade com o protocolo do npm é um objetivo declarado, o que levanta a dúvida sobre por que seria necessário um registry separado.
  • Perguntas sobre suporte a WSL1, WebGPU e como o sandboxing interage com antx permanecem em grande parte sem resposta.

Autoria, IA e preocupações com confiança

  • Versões iniciais teriam incorporado código de outro engine JavaScript (Elk), levantando questões de AGPL e originalidade; o código atual seria uma reescrita completa.
  • A linguagem de marketing que descreve o engine como “hand-built” gera um longo debate:
    • Alguns argumentam que trabalho assistido por LLM, “vibe-coded”, não deveria ser promovido como feito à mão.
    • Outros veem prompts e supervisão de LLMs como a nova norma e algo que não precisa ser divulgado de forma destacada.
  • Ceticismo adicional surge de:
    • Um site da empresa com uma página /jobs não funcional (explicada como uma piada interna).
    • Uma fonte serifada renomeada no site que é identificada como uma tipografia comercial, levando um comentador a alegar um padrão de “roubo”.
  • O sentimento geral varia de entusiasmado (“elegante”, “muito interessante”) a cauteloso ou desconfiado, com várias pessoas dizendo que gostam das ideias, mas se preocupam com a procedência e a confiabilidade de longo prazo.

Comparações com runtimes existentes

  • Vários comentadores observam que o Deno já oferece muitos recursos semelhantes (sandboxing, compilação, apoio sério da equipe).
  • Bun é mencionado como outro runtime focado em performance, com recursos de compilação e otimização.
  • Alguns questionam se “menor e mais rápido” é motivo suficiente para adotar mais um runtime JS, dado que já existem alternativas maduras.