Show HN: Ant – A JavaScript runtime and ecosystem

Original Article ↗ Hacker News Discussion ↗

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.