# Ant: a 9 MB JavaScript runtime built on its own Ant Silver engine

> Ant is a from-scratch JavaScript runtime written in C, targeting WinterTC conformance and millisecond cold starts. It is early, its test262 pass rate is about 65 percent, and that number is the whole adoption decision.

**theMackabu/ant** — javascript for 's, a tiny runtime with big ambitions. Each runtime loads the same bench-coldstart.js script from examples/npm/hono/ that creates a Hono app with two routes, prints "ready", and calls process.exit(0).

- Repository: https://github.com/theMackabu/ant
- Website: https://antjs.org
- Stars: 1,278 · Forks: 31
- Language: C
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/themackabu-ant

## The problem Ant picks: runtimes are large and slow to boot

A Node binary is around 140 MB and takes roughly 30 ms before your first line of code runs. On a long-lived server that is noise. In a serverless function that scales to zero, or a CLI tool invoked once per shell command, it is the dominant cost. Ant's answer is a C runtime with an independent engine, Ant Silver, that the README describes as not a wrapper around V8, JSC, or SpiderMonkey. The stated binary is 9 MB, or 4.7 MB when built with -Os, and the README's own cold-start table puts Ant at 3.9 ms against Bun's 8.8 ms, Deno's 18.6 ms and Node's 29.4 ms. The audience the README names is specific: serverless functions, edge computing, embedded systems and CLI tools. If your process lives for hours, the size and boot advantage shrinks toward irrelevance.

## Ant Silver, MIR, and what the cold-start benchmark actually measures

The engine is the interesting part. Ant Silver is written from scratch, and its JIT uses a fork of MIR, described in the README as a lightweight backend that enables near-native performance. The runtime does not embed a third-party engine, which is why the binary can be single-digit megabytes. The benchmark that anchors the performance claim is narrow by design. Each runtime loads the same examples/npm/hono/bench-coldstart.js script, which imports Hono, registers two routes, prints ready, and calls process.exit(0). No HTTP server starts. The README says this isolates module resolution and initialization overhead, and that is exactly what it isolates: it says nothing about request throughput, memory under load, or steady-state execution speed once the JIT has warmed up. Treat the table as a startup measurement, not a general performance verdict. The numbers also come from one machine, an Apple M5 Pro, with hyperfine at 10 warmup and 100 timed runs, and the README publishes the hardware and the exact command so you can reproduce or contradict it.

## Installing Ant and running a first script

The README gives a single install path, a shell script served from the project's site. There is no npm package for the runtime itself; package.json in the repository is a task runner whose scripts all invoke ./build/ant, meaning they assume a local build.

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

That fetches and runs the installer. Piping a remote script into bash means you are trusting antjs.org at the moment of install; if that matters in your environment, download the script first and read it. After installation the runtime is a single ant executable, and the README's size comparison shows it as 9.0M, or 4.7M built with -Os.

A first real use is the project's own benchmark script, which is also the smallest honest smoke test of module resolution. From the repository root:

```bash
ant examples/npm/hono/bench-coldstart.js
```

The script imports Hono, registers two routes, prints ready, and exits with process.exit(0). If you see ready and the process returns immediately, module resolution and startup worked. If it fails, the failure will most likely be in resolving the npm dependency tree rather than in the language itself, which is the first thing worth probing before you trust Ant with anything larger.

## Building Ant from source is a real toolchain commitment

BUILDING.md holds the source instructions and the supported platform list, and the Dockerfile shows what those instructions cost. The image starts from Alpine 3.23, installs clang, lld, llvm, meson, ninja, cmake, libunwind, util-linux and Node, then downloads Zig 0.16.0 pinned by ZIG_VERSION and symlinks it into /usr/local/bin. Dependencies come from meson subprojects download against vendored wrap files, including BoringSSL. The build sets CC=clang, CC_LD=lld, AR=llvm-ar and RANLIB=llvm-ranlib. This is not a project where you clone and run make. It is a project where you either accept a long first build with a pinned Zig toolchain, or you use the prebuilt installer and give up the ability to patch the engine. Note also that the Dockerfile handles only amd64 and arm64 and exits with an error on any other TARGETARCH.

## The conformance gap is the honest limitation

The README publishes three conformance numbers, and they do not agree with each other. compat-table is 100 percent, 1511 of 1511, covering ES1 through ESNext. Temporal is 100 percent, 4603 of 4603 at revision 2026-08-10. test262 is about 65 percent, 34758 of 53578 at the same revision. A runtime that passes every compat-table entry but roughly two thirds of test262 is a runtime whose gaps live in the corners test262 was built to probe: coercion edge cases, exotic object behaviour, the precise semantics of built-ins under unusual arguments. Your code may never touch them. But the failure mode is unpleasant when it does, because a spec-conformance bug surfaces as a wrong value rather than a crash. The README does not list which test262 areas fail, so you cannot predict the gap from the documentation. WinterTC conformance is also marked partial for Node in the README's own comparison table, which is a reminder that this column measures an API surface, not language correctness. If your workload is a Hono app on an edge node, 65 percent may be entirely sufficient. If it is a data pipeline that leans on Date, Intl or regular-expression semantics, measure before you migrate.

## Where Ant is the wrong tool, and what to use instead

Ant is the wrong choice when your application depends on native Node addons. The README makes no claim of Node addon compatibility, and a from-scratch engine cannot load a .node binary compiled against V8's ABI. It is also the wrong choice when you need the full Node standard library: the project targets the WinterTC Minimum Common API, which is a server-side interoperability baseline, not Node's API. Bun is the closest alternative and the more pragmatic default for most teams. Bun embeds JavaScriptCore and ships a package manager, a test runner and a bundler alongside the runtime, so it is a platform rather than a runtime. Ant is the opposite bet: a smaller surface, a smaller binary, an engine the project controls end to end. The README's own table puts Bun at 61 MB and 8.8 ms cold start against Ant's 9 MB and 3.9 ms. If you want a drop-in Node replacement with ecosystem coverage, Bun or Deno answers that question. If you want the smallest possible process that starts a JavaScript module graph and exits, Ant is aiming at a narrower target, and it is winning on that specific axis.

## Maintenance, release cadence and the MIT licence

The last push to master was on 2026-08-18, and the most recent release is v14.0.ff84a70d.0 from the same day, following v13.0.ca8e720d.0 on 2026-08-02 and v12.2.8f8451f4.0 on 2026-07-11. The cadence is fast, and the version strings carry a commit hash fragment, which tells you releases are cut from specific commits rather than from a long-lived stable line. The README's benchmark environment lists Ant 14.1.aa53d9d1.0, a version ahead of the latest release shown here, so the project moves between releases too. For upgrade cost, that means pinning matters. The repository has a GOVERNANCE.md and a CONTRIBUTING.md, and the README points to SECURITY.md for vulnerability reporting, so there is process around the code. The licence is MIT, which is permissive and imposes no copyleft obligation on your own source. One caveat worth checking yourself: the Dockerfile builds BoringSSL from a vendored wrap, and BoringSSL carries its own licence terms distinct from Ant's MIT licence. If you redistribute a binary built that way, read vendor/ before you assume MIT covers everything in the artifact.

## Conclusion

Ant fits teams whose workload is a small module graph that must start in single-digit milliseconds, and who can tolerate a runtime whose test262 pass rate the README puts at roughly 65 percent. It does not fit anyone running an existing Node application with native addons, or a codebase that leans on the parts of ECMAScript that test262 covers and Ant may not. Before adopting, verify three things yourself: run your own dependency tree under ant and watch for module resolution failures, check the WinterTC Minimum Common API surface you actually call, and read BUILDING.md plus the Dockerfile before committing to a source build, because the image pulls Zig 0.16.0 and builds BoringSSL from vendored wraps. The cold-start table is the project's own measurement on an Apple M5 Pro, not a neutral one.

## FAQ

### Is Ant open source?

Yes. The repository is public, the primary language is C, and the licence is MIT. The README also links a CONTRIBUTING.md, a GOVERNANCE.md and a SECURITY.md.

### What is the purpose of the Ant JavaScript runtime?

Ant is a JavaScript runtime built from scratch for environments where binary size and startup time matter, which the README lists as serverless functions, edge computing, embedded systems and CLI tools. It targets the WinterTC Minimum Common API and uses its own engine, Ant Silver.

### How do I install Ant?

The README gives one command: curl -fsSL https://antjs.org/install | bash. Building from source is documented separately in BUILDING.md, and the repository's package.json scripts all invoke a locally built ./build/ant.

### How does Ant compare to Node, Bun and Deno on cold start?

The README's own table, measured with hyperfine on an Apple M5 Pro, puts Ant at 3.9 ms mean, Bun at 8.8 ms, Deno at 18.6 ms and Node at 29.4 ms. The script imports Hono, registers two routes, prints ready and exits, so the measurement covers module resolution and initialization, not request throughput.

### Does Ant pass test262?

Partially. The README reports test262 at about 65 percent, 34758 of 53578 at revision 2026-08-10, while compat-table is 100 percent and Temporal is 100 percent at the same revision. The README does not list which test262 areas fail.

## Sources

- [Official documentation](https://antjs.org)
- [Official README](https://github.com/theMackabu/ant#readme)
- [Project repository](https://github.com/theMackabu/ant)
- [Release notes](https://github.com/theMackabu/ant/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/themackabu-ant