Ant, un runtime JavaScript léger et son écosystème

 (antjs.org)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Grâce à son moteur Ant Silver développé en interne, il exécute de vrais paquets npm et met en avant un binaire unique d’environ 8,6 Mo ainsi qu’un démarrage rapide
  • Il ne s’agit pas d’une couche autour de V8, JSC ou SpiderMonkey, affiche 100 % sur compat-table et la conformité WinterTC, et prend en charge Hono, Elysia, TypeScript, React, Rolldown, Wasm, etc.
  • Lors d’une mesure de cold start consistant à charger Hono, enregistrer deux routes puis quitter, il a obtenu 5,4 ms, contre 12,8 ms pour Bun, 24,8 ms pour Deno et 31,1 ms pour Node.js
  • Il installe les paquets jusqu’à 40 fois plus vite que npm et permet d’exécuter directement TypeScript ainsi que de servir l’export fetch par défaut, sans build séparé ni adaptateur de framework
  • Il fournit un sandbox isolé par VM pour le code non fiable ainsi que le registre public compatible avec le protocole npm ants.land, et peut être utilisé sur macOS et Linux en arm64 et x86_64 sans toolchain supplémentaire

Moteur maison et flux de développement rapide

  • Ant est un runtime JavaScript haute performance construit de zéro, distribué sous la forme d’un binaire unique portable d’environ 8,6 Mo incluant le moteur Ant Silver
    • Ce n’est pas un wrapper basé sur V8, JSC ou SpiderMonkey
    • Il obtient 100 % sur compat-table et est indiqué comme WinterTC Conformant
    • Il exécute l’écosystème Hono, Elysia, TypeScript, React, Rolldown, WinterTC et Wasm

  • Performances de cold start

    • La mesure charge Hono, enregistre deux routes puis quitte afin d’évaluer uniquement le coût de résolution des modules et d’initialisation
    • Ant: 5,4 ms
    • Bun: 12,8 ms
    • Deno: 24,8 ms
    • Node.js: 31,1 ms

  • Installation de paquets

    • Il est possible d’installer un paquet avec la commande ant i hono et, dans l’exemple, l’installation de hono@latest se termine en 155 ms
    • Le projet met en avant une vitesse d’installation jusqu’à 40 fois supérieure à celle de npm, sans nécessité de configurer un outil de gestion de paquets séparé

  • Serveur et exécution de TypeScript

    • L’export fetch par défaut d’un fichier est servi comme serveur, ce qui permet d’exécuter des frameworks comme Hono sans adaptateur
    • Les fichiers TypeScript peuvent être exécutés directement avec ant app.ts
      • Il n’est pas nécessaire d’ajuster tsconfig, ni d’utiliser un bundler, un répertoire dist ou l’étape tsc && node dist/app.js

Exécution isolée et écosystème de paquets

  • Sandbox basé sur une VM

    • Le Sandbox de ant:sandbox ne se limite pas à une simple vérification des permissions et exécute du JavaScript non fiable à l’intérieur d’une frontière d’isolation VM
    • Chaque sandbox utilise une VM KVM ou Hypervisor.framework indépendante
    • Les montages du système de fichiers restent en lecture seule tant qu’une autorisation d’écriture n’est pas accordée explicitement
    • Le réseau est entièrement bloqué par défaut et seuls les ports spécifiés sont redirigés

  • Registre public de paquets

    • ants.land est un registre public de paquets pour Ant
    • Il utilise le protocole npm, ce qui le rend accessible non seulement depuis Ant mais aussi depuis npm, Yarn, pnpm et Bun
    • Les paquets s’installent avec un scope ou un nom classique, et peuvent aussi être utilisés dans le navigateur via esm.ants.land
    • La connexion se fait avec ant land login et la publication d’un paquet avec ant land publish
    • Les informations du registre incluent une note de 0 à 100 reflétant la documentation, la licence et la compatibilité
    • Il prend en charge arm64 et x86_64 sur macOS et Linux, sans nécessiter de toolchain supplémentaire

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Réactions sur Hacker News

  • Je code avec l’IA toute la journée, tous les jours, mais je pense que ce problème, soulevé en mars dernier, mérite qu’on s’y arrête
    Même si le code a ensuite été réécrit, dire que tout a été « fait maison depuis zéro » me gêne un peu, étant donné que l’ancienne base de code sous AGPL représentait une part importante du travail initial
    D’après ce fil, après avoir abandonné l’ancienne version, les auteurs originaux n’avaient pas l’air particulièrement dérangés, et le code actuel semble bien avoir été réécrit, tant sa forme et sa structure ont changé. J’aime vraiment le travail dans son ensemble, donc continuez, mais tout le monde doit rester prudent

    • Cela dit, ce billet ne donne pas l’impression d’avoir été écrit par quelqu’un qui a réellement implémenté un moteur JavaScript
      On dirait plutôt qu’un autre LLM a été prié de transformer en article de blog l’historique Git d’un LLM qui semblait avoir repris du code d’autres moteurs JavaScript, ce qui rend à la fois difficile de comprendre ce qui s’est passé et encore plus difficile de faire confiance au projet
    • Ce problème visait le code de décembre 2025, à une époque où le projet n’avait rien à voir avec sa forme actuelle
      Vers février, l’ancienne base de code a été pratiquement supprimée et un système bien plus fiable a été conçu depuis zéro. Je savais que le code de l’époque était presque entièrement composé de génération IA de mauvaise qualité, mais ce n’était pas la priorité absolue, et aujourd’hui aucun code ne passe sans revue ni tests

  • Il existe déjà Ant d’Apache, donc je me demande pourquoi l’avoir appelé Ant plutôt que « Antjs » ou « Ant.js » : https://ant.apache.org

    • Même dans l’écosystème JavaScript, le nom est déjà largement occupé par Ant Design : https://ant.design/
    • On ne choisirait le nom Ant que si l’on voulait faire une mauvaise première impression aux gens qui codent depuis des décennies
    • J’ai été le premier utilisateur et contributeur d’Apache Ant en dehors de Sun Microsystems, quand James a transmis le projet, mais cela ne me dérange absolument pas que quelqu’un d’autre utilise le même nom
    • J’ai d’abord cru que c’était un framework d’Ant Group d’Alibaba, puisque c’est aussi de là que vient Ant Design

  • Le processus qui a permis de sortir une première version en un mois est raconté dans le premier billet, et la suite quelques mois plus tard dans le deuxième billet
    Je ne sais pas si créer un nouveau runtime et tout un écosystème depuis zéro tient économiquement la route, mais on semble déjà être entrés dans une phase où un développeur seul peut produire un logiciel qui exigeait autrefois une équipe entière, et ce n’est que le début

    • Il est explicitement indiqué que le moteur, Ant Silver, a été développé en interne
    • Si les LLM ne font que recracher du code appris à partir des données d’entraînement, ce n’est pas très impressionnant
      J’aimerais voir des développeurs solo créer de nouveaux logiciels que même des équipes entières n’arrivaient pas à produire auparavant. Je suis très favorable à l’IA, mais j’en ai assez de la surpromotion permanente

  • J’avais plaisanté sur le fait que le CLI ant d’Anthropic se moquait bien d’Apache ant, et voilà maintenant le ant de JavaScript

    • Je pensais être le seul à me souvenir d’Apache Ant. Les noms s’épuisent, certes, mais Ant a été un outil fondamental extrêmement influent
    • Je n’ai encore jamais vu une seule personne utiliser le CLI ant d’Anthropic

  • Je ne connais pas en profondeur l’écosystème JavaScript ni les runtimes, mais j’ai été un peu surpris de voir mises en avant à la fois une plus petite taille, un démarrage rapide, le sandboxing et des performances compétitives
    Je me demande quelle est l’intuition clé ou le choix d’architecture qui permet d’obtenir tous ces avantages face à des stacks JavaScript déjà matures et hautement optimisées, quel est le vrai grand pari technique

    • Comme évoqué ailleurs dans le fil, ce projet semble être une réécriture d’Elk par LLM, un projet lancé en 2019 : https://github.com/cesanta/elk
    • Deno offre déjà pratiquement tout ce qu’on voit ici, tout en étant un projet mature et sérieux, écrit avant l’ère des LLM et soutenu par une équipe solide
      Ce n’est peut-être pas le plus rapide, mais il est difficile d’adopter un nouveau runtime simplement parce qu’il est « plus rapide que X ». Les choix d’architecture de ce projet ressemblent plutôt au résultat de Claude ou Codex qui ont copié une part importante de la base de code d’Elk

  • Je comprends le runtime, le moteur et la monétisation via Colony, mais je ne vois pas forcément pourquoi il faudrait aussi un registre séparé, un gestionnaire de paquets séparé, Ant Desktop, un sandbox et ce treatjs difficile à cerner
    Pour un runtime JavaScript, j’aimerais qu’il fasse surtout une seule chose : exécuter du JavaScript. Je me demande pourquoi tout le monde vise la boîte à outils intégrée, et ce projet paraît déjà complexe

  • On parle de « vitesse proche de V8 », mais dans les benchmarks de zoo.js, cela semble très loin du compte : https://zoo.js.org/
    À moins que les performances n’aient énormément progressé après le 10 février 2026, cette formulation ne semble pas correcte

    • Depuis février, le moteur a été pratiquement entièrement réécrit et les performances se sont beaucoup améliorées
      À l’époque, il fonctionnait surtout comme un interpréteur et il lui manquait plusieurs opérations JIT ; des benchmarks devraient bientôt être ajoutés aux builds nightly

  • Ce qui a attiré mon attention en premier, c’est le sandboxing. Je ne comprends pas pourquoi Node et npm ne l’offrent pas par défaut, alors que cela aiderait grandement à réduire les vers et les attaques de la chaîne d’approvisionnement

    • D’après l’explication en bas de la page, le VM de « VM isolated sandbox » ne désigne pas la machine virtuelle JavaScript, mais un hyperviseur
      Si l’on tourne déjà dans une machine virtuelle et qu’il faut de la virtualisation imbriquée, rien ne dit même que ce soit pris en charge, et cela ne semble pas idéal en termes de vitesse ou d’efficacité
    • Deno propose déjà cette fonctionnalité. Je ne suis pas affilié au projet, juste un utilisateur satisfait

  • Je me demande quelle est la police à empattements utilisée sur le site. On dirait qu’elle a été renommée en ant_serif et que tous les autres identifiants ont été supprimés, mais le rendu est vraiment réussi

    • Cela ressemble à une habitude récurrente de l’auteur original, à savoir se servir sans autorisation

  • Il y a des benchmarks de cold start, mais pourquoi n’y a-t-il pas de benchmarks de performances d’exécution comparés à Node, Deno, Bun, QuickJS, etc. ?