Ant: A 9 MB JavaScript runtime that prioritizes cold start over spec completeness
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).
At a glance
- What is it?
- Ant is a from-scratch JavaScript runtime built in C, targeting WinterTC conformance and very fast startup. Its 9 MB binary and ~4 ms cold start are real, but only 65% test262 conformance means it is not a drop-in Node replacement.
- Who is it for?
- Adopt Ant if you need a minimal runtime for serverless functions, edge computing, embedded systems, or CLI tools where binary size and startup latency dominate and where WinterTC Minimum Common API coverage is sufficient. Do not adopt it if you need full Node API compatibility or broad test262 conformance, since a 65% pass rate means many language features will fail at runtime.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Ant actually solves
Ant is a JavaScript runtime written in C, built from scratch, with its own engine called Ant Silver. The README positions it for environments where size and startup time dominate: serverless functions, edge computing, embedded systems, and CLI tools. The core claim is a 9 MB binary versus roughly 140 MB for Node, 61 MB for Bun, and 77 MB for Deno. Cold start is quoted at about 4 ms on an Apple M5 Pro, compared to 29.4 ms for Node, 18.6 ms for Deno, and 8.8 ms for Bun. These numbers come from the project's own hyperfine benchmark, so treat them as vendor measurements, not independent verification. The audience is clearly developers who ship JavaScript where every megabyte and every millisecond of startup counts.
How Ant Silver is different under the hood
Ant does not wrap V8, JavaScriptCore, or SpiderMonkey. The engine is independent, and the JIT compiler uses a fork of MIR, a lightweight backend that the README says enables near-native performance. This is a significant architectural choice. Building a JIT from scratch is expensive and error-prone, and the README's own conformance numbers show the cost. The runtime targets the WinterTC Minimum Common API, a specification from Ecma TC55 for server-side JavaScript interoperability. That means Ant is not trying to match Node's full API surface. It is aiming for a smaller, agreed-upon subset. The trade-off is explicit: you get a tiny runtime with a JIT, but you give up the full Node ecosystem compatibility.
Getting Ant running and building it
Installation is a single curl command: curl -fsSL https://antjs.org/install | bash. That is the only installation path shown in the README. Building from source is referenced in BUILDING.md, which is not included in the material, so the exact build steps are unknown. The README does show that the binary can be built with -Os, reducing it from 9 MB to 4.7 MB. That optimization flag is a real configuration detail, but the rest of the build process is undocumented in the provided text. If you want to compile from source, you will need to read BUILDING.md in the repository. For running scripts, the benchmark command shows ant examples/npm/hono/bench-coldstart.js, so execution is straightforward: pass a file path to the ant binary.
The benchmark that matters: cold start
The cold start benchmark is well defined. It loads a Hono app with two routes, prints 'ready', and calls process.exit(0). No HTTP server starts, so the measurement isolates module resolution and initialization. The command uses hyperfine with 10 warmup runs and 100 timed runs. Ant reports a mean of 3.9 ms, with Bun at 8.8 ms, Deno at 18.6 ms, and Node at 29.4 ms. The relative numbers are 2.26x, 4.74x, and 7.50x slower than Ant. These are impressive figures, but they come from the project's own hardware and setup. The environment is an Apple M5 Pro with 64 GB RAM, which is a specific and recent machine. You should not expect the same numbers on older or different hardware. The benchmark is honest in its methodology, but it is not a third-party audit.
Spec conformance: the real limitation
Ant's conformance numbers are mixed. The README claims 100% on compat-table, which covers ES1 through ESNext, and 100% on Temporal with 4603/4603 passing. But test262, the standard conformance suite for JavaScript, shows only about 65%: 34758 out of 53578 tests pass. That is a large gap. A 65% pass rate means many language features are missing or partially implemented. For a runtime that aims to be WinterTC conformant, this might be acceptable if your code stays within the Minimum Common API. But if you are porting an existing Node application, you will likely hit unsupported syntax or semantics. The README does not list which features fail, so you cannot predict what breaks without testing. This is the single biggest reason to be cautious before adopting Ant.
Security and community: what the README does and does not say
The README links to SECURITY.md for vulnerability reporting, but the content of that file is not provided. There is also a GOVERNANCE.md and a CONTRIBUTING.md, both referenced but not included. The community channels are a Discord server and a blog post. The project is not archived, and the last push was August 18, 2026, with releases roughly every two to three weeks. That suggests active maintenance. The license is MIT, which is permissive and generally favorable for adoption, but you should review the MIR fork's license separately, since it is a fork of another project. The README does not state the MIR license, so you need to check the repository for that detail. The governance model is also unknown from the material, so decision-makers should look at GOVERNANCE.md before relying on the project long-term.
Alternatives: Bun and Node, and the difference in approach
The obvious alternatives are Bun and Node. Bun is a drop-in replacement for Node with a much larger API surface and a JIT based on JavaScriptCore. Its binary is about 61 MB, and its cold start is around 8.8 ms in the same benchmark. Bun aims for full Node compatibility, so you can run existing npm packages without modification. Node is the baseline, with the largest ecosystem and a 29.4 ms cold start. The difference in approach is that Ant chooses a minimal API target and accepts a conformance gap, while Bun and Node prioritize compatibility and ecosystem breadth. If you need Node's full API, Ant is the wrong tool. If you only need a small subset and startup speed is critical, Ant's approach is coherent. The trade-off is clear: you trade compatibility for size and speed.
Maintenance and upgrade cost
The release cadence is steady, with versions like v14.0.ff84a70d.0, v13.0.ca8e720d.0, and v12.2.8f8451f4.0 over a span of about six weeks. The versioning scheme includes commit hashes, which suggests a rolling release model rather than semantic versioning. That has implications for upgrades: you may not get stable API guarantees between releases. The README does not describe a migration path or a changelog. Given the conformance gaps, each new release could change behavior in ways that break your code. The maintenance cost is therefore higher than for a mature runtime like Node. You should pin a specific version and test thoroughly before upgrading. The MIT license reduces legal friction, but the MIR fork's license and the project's governance remain open questions that you must verify from the repository files.
Editorial conclusion
Adopt Ant if you need a minimal runtime for serverless functions, edge computing, embedded systems, or CLI tools where binary size and startup latency dominate and where WinterTC Minimum Common API coverage is sufficient. Do not adopt it if you need full Node API compatibility or broad test262 conformance, since a 65% pass rate means many language features will fail at runtime. Before committing, verify that your specific dependencies and language constructs are covered by the WinterTC API and that the 65% test262 gap does not affect your code. Also check the MIR JIT fork for license and maintenance implications. The project is actively pushed, with releases every few weeks, but the conformance gap is the boundary you must test against.
Community notes