Show HN: Ant – A JavaScript runtime and ecosystem

Original Article ↗ Hacker News Discussion ↗

A new JavaScript runtime called Ant promises much smaller binaries, fast startup, sandboxed execution, and an ecosystem including a package manager, registry, and desktop app tooling, positioning itself as a lightweight alternative to Node, Deno, Bun, and V8. Commenters are intrigued by its potential for embedding, FaaS, and Electron-like desktop apps, but question the maturity of the project, the need for yet another registry and package manager, and the lack of comprehensive performance and security benchmarks. Concerns are also raised about code provenance, heavy use of LLMs in its development, and naming conflicts with existing “Ant” projects, leading some to doubt how trustworthy or sustainable the ecosystem will be.

Project scope & positioning

  • New JavaScript runtime and ecosystem claiming small size, fast startup, sandboxing, and node compatibility.
  • Includes its own engine (“Ant Silver”), registry, package manager, sandbox/hypervisor integration, and plans for a desktop app framework and binary compilation.
  • Some find this breadth exciting; others see it as prematurely “all‑in‑one” and convoluted for a young project.

Desktop apps & binary size

  • Interest in using it as a lightweight Electron alternative for packaging HTML/CSS/JS into desktop apps.
  • A separate “ant-desktop” tool is in early development, currently with a Chromium-only renderer; WebView and other backends are planned.
  • Runtime binary reported around 8 MB, prompting optimism vs Electron-sized bundles and questions about desktop build sizes.

Performance & engine design

  • Compared to V8, Ant is said to be much smaller due to simpler JIT tiers, no ICU Unicode data, and no JS startup snapshot.
  • Benchmarks from an external site currently show Ant far slower and less ES6-complete than V8, but the author claims a near-total engine rewrite and recent performance gains.
  • Commenters request comprehensive, independent benchmarks and fuzzing, especially if it aims to compete with V8/LLVM-level engines.

Sandboxing & hypervisor

  • The advertised “VM-isolated sandbox” is implemented via KVM on Linux and Hypervisor.framework on macOS, running a patched Nanos kernel.
  • Memory is lazily allocated with a default 256 MB limit; about 35 MB is used by Ant plus the VM.
  • Some are skeptical about performance, especially with nested virtualization; others see strong potential for FaaS and safer npm-style execution. Windows support is asked but not answered.

Ecosystem (registry, tooling, compatibility)

  • Ant plans its own registry and package manager; multiple commenters suggest using JSR instead of building yet another registry.
  • npm protocol compatibility is a stated goal, raising questions about why a separate registry is needed.
  • Questions about WSL1 support, WebGPU, and how sandboxing interacts with antx remain mostly unanswered.

Authorship, AI, and trust concerns

  • Early versions reportedly incorporated code from another JS engine (Elk), raising AGPL and originality questions; current code is said to be a full rewrite.
  • Marketing language describing the engine as “hand-built” sparks a long debate:
    • Some argue LLM-assisted, “vibe-coded” work should not be marketed as hand-built.
    • Others see prompting and supervising LLMs as the new normal and not something that must be disclosed prominently.
  • Additional skepticism arises from:
    • A company site with a nonfunctional /jobs page (explained as an inside joke).
    • A custom-renamed serif font on the site that is identified as a commercial typeface, leading one commenter to allege a pattern of “stealing.”
  • Overall sentiment ranges from enthusiastic (“slick”, “very interesting”) to cautious or distrustful, with several people saying they like the ideas but are wary of provenance and long-term reliability.

Comparisons to existing runtimes

  • Multiple commenters note that Deno already offers many similar features (sandboxing, compilation, serious team backing).
  • Bun is mentioned as another performance-focused runtime with compilation and optimization features.
  • Some question whether “smaller and faster” is enough reason to adopt yet another JS runtime given mature alternatives.