Ant, runtime ligero de JavaScript y su ecosistema

 (antjs.org)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Ejecuta paquetes reales de npm con su propio motor Ant Silver, y destaca un binario único de unos 8.6 MB junto con un arranque rápido
  • No es una capa sobre V8, JSC ni SpiderMonkey; muestra 100% en compat-table y cumplimiento de WinterTC, además de soporte para Hono, Elysia, TypeScript, React, Rolldown y Wasm
  • En una medición de arranque en frío donde se carga Hono, se registran 2 rutas y luego se cierra, obtuvo 5.4 ms, por debajo de Bun con 12.8 ms, Deno con 24.8 ms y Node.js con 31.1 ms
  • Instala paquetes hasta 40 veces más rápido que npm, y al ejecutar TypeScript directamente y servir el fetch export por defecto no requiere build adicional ni adaptadores de framework
  • Ofrece un sandbox aislado por VM para código no confiable y el registro público compatible con el protocolo de npm ants.land; puede usarse en macOS y Linux sobre arm64 y x86_64 sin toolchain adicional

Motor propio y flujo de desarrollo rápido

  • Ant es un runtime de JavaScript de alto rendimiento construido desde cero, distribuido como un binario único portátil de unos 8.6 MB que incluye el motor Ant Silver
    • No es un wrapper basado en V8, JSC ni SpiderMonkey
    • Marca 100% en compat-table y aparece como WinterTC Conformant
    • Ejecuta ecosistemas como Hono, Elysia, TypeScript, React, Rolldown, WinterTC y Wasm

  • Rendimiento de arranque en frío

    • Se midió solo el costo de resolución e inicialización de módulos cargando Hono, registrando 2 rutas y luego cerrando
    • Ant: 5.4ms
    • Bun: 12.8ms
    • Deno: 24.8ms
    • Node.js: 31.1ms

  • Instalación de paquetes

    • Se pueden instalar paquetes con el comando ant i hono, y en el ejemplo la instalación de hono@latest terminó en 155 ms
    • Destaca una velocidad de instalación de hasta 40 veces más rápida que npm, sin necesidad de configurar una herramienta de gestión de paquetes aparte

  • Servidor y ejecución de TypeScript

    • Sirve el fetch export por defecto del archivo como servidor, por lo que frameworks como Hono pueden ejecutarse sin adaptador
    • Los archivos TypeScript pueden ejecutarse directamente con ant app.ts
      • No hace falta ajustar tsconfig, ni usar bundler, directorio dist o el paso tsc && node dist/app.js

Ejecución aislada y ecosistema de paquetes

  • Sandbox basado en VM

    • ant:sandbox de Sandbox ejecuta JavaScript no confiable dentro de un límite de aislamiento por VM, más allá de una simple verificación de permisos
    • Cada sandbox usa una VM independiente con KVM o Hypervisor.framework
    • Los montajes del sistema de archivos se mantienen en solo lectura a menos que se otorguen permisos de escritura de forma explícita
    • La red está bloqueada por completo de manera predeterminada y solo reenvía los puertos especificados

  • Registro público de paquetes

    • ants.land es un registro público de paquetes para Ant
    • Usa el protocolo de npm, por lo que puede accederse no solo desde Ant sino también desde npm, Yarn, pnpm y Bun
    • Los paquetes se instalan con scope o con nombre común, y también pueden usarse en el navegador mediante esm.ants.land
    • Se inicia sesión con ant land login y se publica un paquete con ant land publish
    • La información del registro incluye una puntuación de 0 a 100 que refleja documentación, licencia y compatibilidad
    • Soporta arm64 y x86_64 en macOS y Linux, sin necesidad de toolchain adicional

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Opiniones en Hacker News

  • Programo con IA todo el día, todos los días, pero creo que vale la pena señalar este problema planteado en marzo pasado.
    Aunque hayan reescrito el código después, la frase “lo hicimos desde cero” me hace algo de ruido, considerando que la base de código AGPL existente representó una parte importante del trabajo inicial.
    Según ese hilo, después de descartar la versión anterior, a los autores originales no pareció importarles demasiado, y el código actual tiene una forma y estructura distintas, así que parece que efectivamente fue reescrito. Me gusta mucho el trabajo en general, así que sigan adelante, pero todos deberían tener cuidado.

    • Pero este artículo no parece escrito por alguien que haya implementado un motor de JavaScript por su cuenta.
      Da la impresión de que le pidieron a otro LLM que escribiera una entrada de blog a partir del historial de Git de un LLM que parece haber tomado código de otro motor de JavaScript, así que cuesta entender qué ocurrió y es aún más difícil confiar en el proyecto.
    • Ese problema apuntaba al código de diciembre de 2025, cuando el proyecto era completamente distinto de lo que es ahora.
      Alrededor de febrero, prácticamente eliminamos la base de código existente y diseñamos desde cero un sistema mucho más confiable. Sabíamos que el código de entonces era casi por completo generación de IA de baja calidad, pero no era la prioridad más grande; ahora nos aseguramos de que no pase nada de código sin revisión y pruebas.

  • Me pregunto por qué lo llamaron Ant y no “Antjs” o “Ant.js”, cuando ya existe Ant de Apache: https://ant.apache.org

    • Incluso en el ecosistema JavaScript, Ant Design, que ya es bastante grande, ocupa ese nombre: https://ant.design/
    • Ant parece el nombre que elegirías si quisieras causar una mala primera impresión en gente que lleva décadas o más programando.
    • Fui el primer usuario y contribuidor fuera de Sun Microsystems cuando James entregó Apache Ant, pero no me molesta en absoluto que alguien más use el mismo nombre.
    • Pensé que era un framework de Ant Group de Alibaba. Ant Design también salió de ahí.

  • El proceso de crear la primera versión en un mes está en el primer artículo, y el seguimiento de unos meses después está en el segundo artículo.
    No sé si tiene sentido económico crear desde cero un nuevo runtime y ecosistema, pero parece que ya entramos en una etapa en la que un solo desarrollador puede hacer software que antes requería un equipo completo, y esto apenas empieza.

    • Ahí se indica explícitamente que “el motor, Ant Silver, fue creado internamente”.
    • Si un LLM solo está escupiendo código que aprendió de sus datos de entrenamiento, no es tan impresionante.
      Quiero ver a desarrolladores individuales crear software nuevo que antes ni siquiera equipos completos podían construir. Soy muy favorable a la IA, pero ya estoy harto del hype constante.

  • Hice un chiste de que el CLI ant de Anthropic no le hacía caso a Apache ant, y ahora aparece también el ant de JavaScript.

    • Pensé que era el único que recordaba Apache Ant. Los nombres se están agotando, pero Ant fue una herramienta base muy influyente.
    • No he visto a absolutamente nadie usar el CLI ant de Anthropic.

  • No conozco a fondo el ecosistema ni los runtimes de JavaScript, pero me sorprendió un poco que afirmen tener menor tamaño, arranque rápido, sandboxing y rendimiento competitivo al mismo tiempo.
    Me pregunto cuál fue el hallazgo clave o decisión de diseño, o la gran apuesta técnica, que les permitió obtener esas ventajas frente a stacks de JavaScript ya maduros y altamente optimizados.

    • Como se trató en otra parte del hilo, este proyecto parece ser una reescritura con LLM de Elk, iniciado en 2019: https://github.com/cesanta/elk
    • Deno ofrece prácticamente todas las funciones que se ven aquí, además de ser un proyecto maduro y serio, escrito antes de los LLM y respaldado por un equipo sólido.
      No es el más rápido, pero es difícil adoptar un nuevo runtime solo porque “es más rápido que X”. Las decisiones de diseño de este proyecto parecen ser resultado de que Claude o Codex copiaron una parte considerable de la base de código de Elk.

  • Entiendo el runtime, el motor y la monetización mediante Colony, pero no sé si hacen falta un registro separado, un gestor de paquetes separado, Ant Desktop, un sandbox y hasta un treatjs de identidad poco clara.
    Si es un runtime de JavaScript, me gustaría que hiciera bien una sola cosa: ejecutar JavaScript. Me pregunto por qué todos apuntan a ser una caja de herramientas integrada, y este proyecto ya se ve complejo.

  • Dicen que tiene “velocidad cercana a V8”, pero en el benchmark de zoo.js parece estar muy lejos: https://zoo.js.org/
    Si el rendimiento no mejoró mucho desde el 10 de febrero de 2026, esa afirmación no es correcta.

    • Desde febrero reescribimos prácticamente por completo el motor y el rendimiento mejoró mucho.
      En ese momento funcionaba mayormente como intérprete y le faltaban varias operaciones JIT; pronto también incluiremos benchmarks en las compilaciones nightly.

  • Lo primero que me llamó la atención fue el sandboxing. No entiendo por qué Node y npm no lo ofrecen por defecto; ayudaría mucho a reducir gusanos y ataques a la cadena de suministro.

    • Según la explicación al final de la página, la VM de “sandbox con aislamiento de VM” no se refiere a una máquina virtual de JavaScript, sino a un hipervisor.
      Si ya se está ejecutando dentro de una máquina virtual y se necesita virtualización anidada, ni siquiera queda claro si estará soportada, y tampoco parece que vaya a ser rápida o eficiente.
    • Deno ya tiene esa función. No tengo relación con el proyecto; solo soy un usuario satisfecho.

  • Me pregunto cuál es la fuente serif usada en el sitio web. Parece que la renombraron como ant_serif y quitaron todos los demás identificadores; se ve bastante bien.

    • Esto parece ser el patrón recurrente del autor original. Es decir, robar cosas.

  • Hay benchmarks de cold start, pero me pregunto por qué no hay datos que comparen el rendimiento de ejecución con Node, Deno, Bun, QuickJS, etc.