Ant: a 9 MB JavaScript runtime whose published benchmark was measured on the previous major

The published benchmark ran on the previous major version

The cold start table is the most quoted part of the README, and the environment block underneath it records which build produced the numbers. The Ant entry there reads 14.1 followed by two hash-like segments, against Node 26.5.1, Bun 1.4.0 and Deno 2.9.5 on an Apple M5 Pro.

The release tags tell a different story. The three newest are version 15.1.6, 15.0.2 and 15.0.2 with the same hash-like structure, the newest published on 2026-09-13. So the runtime being sold today is a 15.x build and the benchmark describes a 14.x build.

That is not unusual in a fast-moving project, and the revision dates next to the conformance figures show the same thing happening elsewhere. But it does mean the headline ratio belongs to a version you cannot pull from a release page.

The version string format itself is worth noting. A semantic version, a build counter and a commit hash are concatenated with no separator, so 14.1.aa53d9d1.0 and 15.1.6aee72e4.0 are single strings. That is fine for a binary that reports its own version and awkward for a package manager.

Two suites at 100 percent, and test262 at 66

The conformance section is three rows, and reading them as one number would be a mistake.

The compatibility table suite passes completely, 1511 of 1511 across ES1 through ES5, ES6, ES2016 and later, and ESNext. The Temporal suite also passes completely, 4603 of 4603, measured at a revision dated 2026-08-10. The language test suite passes 35590 of 53578, which is around 66 percent, measured at a revision dated 2026-09-13.

That last row is the one that matters for anyone deciding whether to run production code on this runtime. Close to eighteen thousand tests are not passing, and a runtime with its own independent engine is exactly the situation where language coverage differs from the reference implementations in ways an application can hit.

The target is named precisely, which helps. Ant targets the WinterTC Minimum Common API specification, the interoperability standard for server-side JavaScript developed by Ecma TC55, rather than claiming general conformance to something vaguer.

So the honest summary is that the runtime passes the two suites that describe the platform surface it targets, and passes about two thirds of the language surface. The comparison table's single tick in a WinterTC conformance row is accurate; it is just narrower than the word suggests.

Two binary sizes and a rounded comparison row

Size is the project's first argument, and the README shows it as shell output rather than as a claim.

The listing shows a binary of 8.6 megabytes, and then the same listing again after a line noting a build with size optimisation, where the binary is 4.5 megabytes. So the optimisation flag roughly halves it.

Installation is one command:

curl -fsSL https://antjs.org/install | bash

The comparison table rounds the first figure to 9 MB and sets it against approximately 140 MB for Node, approximately 61 MB for Bun and approximately 77 MB for Deno. The ordering is not close: Ant is an order of magnitude under the smallest of the three, and more than an order under Node.

What the same row does not show is the effect of the size-optimised build on speed, because the benchmark table reports only one configuration and the listing does not say which one it measured. A runtime compiled with size optimisation in mind typically trades instruction-level throughput for footprint, so the 3.9 millisecond cold start and the 4.5 megabyte binary are probably not the same build.

That is a small gap and an easy one to close by publishing both, but as it stands a reader choosing between the two configurations has to guess which trade has already been made.

The engine is independent and the JIT backend is a personal fork

The central claim is stated in one sentence and it is the sentence to test first: Ant Silver is an independent engine, not a wrapper around V8, JSC or SpiderMonkey.

That matters because it means every behaviour in the language, from parsing to optimisation, is this project's own, and the 66 percent test262 figure is the cost of that decision rather than an accident.

The JIT compiler is described as using a fork of MIR, a lightweight backend, which the README links to a repository under the same account as the runtime. So the compiler backend is not a third-party dependency but the maintainer's own earlier project, forked for this use.

That has an upside and a downside, and both are ordinary. The upside is that the backend can be specialised for a small footprint and a short cold start, which is exactly what the two headline numbers measure. The downside is that the critical path of the engine depends on one person's fork of one person's earlier work, so the bus factor on the JIT is one.

The comparison table lists a JIT tick for all four runtimes, which is true, and lists the engines by name for the other three, which is the point: two of the three competitors embed an engine that Google, Apple or a foundation maintain, and this one does not.

Four build systems, and the container build needs the network

The repository root carries four build and tooling systems, which tells you the project has moved between several.

Meson is the build system, with a build file, a directory of Meson files and a options file. A Nix flake and its lock file are committed, so a reproducible developer environment is defined. A Maid task file provides task automation. And there is a vendored dependency tree with wrap files and package files, plus a sources manifest and an include directory at the root.

The container build shows what that costs. It starts from Alpine and installs a full native toolchain including the C and C++ compilers, the linker and archiver from LLVM, CMake, Meson, Ninja, the unwinder development files, and both Node and Python. It then downloads a pinned Zig release, choosing the archive by target architecture and failing the build on an architecture it does not recognise.

Two details are worth pausing on. The Zig download happens at build time rather than being vendored, so the build is not hermetic without network access. And the dependency fetch line is written as a fallback: try to download the Meson subprojects, and if that fails, continue only if a vendored BoringSSL checkout with its own Git directory is already present. That is an offline escape hatch, and it is also a hint about how much of the dependency tree has to be pre-fetched to build without a network.

Published images exist for both amd64 and arm64, so a user does not need any of this unless they are building.

The npm manifest has no dependencies and shells into the built binary

The JavaScript manifest for the project declares no dependencies and no development dependencies at all. It exists to name the package and to hold scripts.

Every script invokes the built binary directly. There is a deploy script that renders an install script, a spec runner, a JIT runner, and five test scripts: the general suite, a mode that updates expectations, and three narrower suites for servers, for network behaviour and for a load-testing tool.

The pattern is the interesting part. Running the project's own test suites is a matter of executing the runtime you just built against test files, with no JavaScript dependencies in between. For a language runtime that is the right shape, since the tests exercise the thing being built rather than a harness layered on top of it.

The one place JavaScript dependencies do appear is the build. The container build installs Node and Python in its first stage, copies a manifest and a shrinkwrap file for the tools directory, and runs a clean install with that shrinkwrap before compiling. So the toolchain is pinned for reproducible installs while the runtime itself carries nothing.

The deployment script explains the other half of the packaging story: one of the build outputs is the installer that the documented curl command fetches, which means the install path is generated rather than hand-written.

Twenty-one example directories and a single published benchmark

The examples directory is far larger than the documentation implies, and it points at where this runtime is being pushed.

Twenty-one entries cover the obvious ground and then some. There are three separate benchmark directories, one for the published cold start through a web framework, one for another framework, and one against a specific engine. There is a conformance directory, a test suite directory, and a quirks file that reads as a running list of behaviours worth knowing about.

Then there are the directions the runtime is aiming at: foreign function interface examples, WebAssembly, a JSON database, embedding, a desktop application, a terminal interface, a router, remote procedure calls, a server, a JavaScript package example, and one named for a speech model.

That list is a better statement of intent than the README's positioning paragraph, which mentions serverless functions, edge computing, embedded systems and command line tools. A desktop application, an embedding host, a JSON store and a speech model are not in that paragraph at all.

The gap between the two is measurement. Twenty-one example directories and three benchmark directories exist, and the README publishes the results of exactly one benchmark on one machine.

Editorial conclusion

Ant fits someone shipping JavaScript where a 140 MB runtime and a 30 millisecond startup are not options, such as a small function, a command line tool or an embedded host, and who can accept a runtime that passes two thirds of the language test suite. It does not fit a production service that needs broad language coverage today. Verify four things before you adopt it. Read the conformance table for what it is, because full passes on a compatibility table and on the Temporal suite sit next to roughly 66 percent of test262, which is close to eighteen thousand tests not passing. Check the version the numbers came from, since the benchmark environment records Ant 14.1 while the release line is 15.1.6. Judge the speed claim on minimums rather than means, because Ant's own spread runs from 2.1 to 5.3 milliseconds and the headline ratio is a ratio of means. And read the build documentation before assuming reproducibility, since the container build downloads a pinned Zig release and Meson subprojects over the network, with a vendored BoringSSL checkout as the fallback. The project is MIT licensed on the default branch master, publishes amd64 and arm64 images, and its last commit is dated 2026-10-01.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes