Meet Ant: The 9MB JavaScript Runtime That Cold-Starts in 5ms — A Hands-On Tutorial

I remember the first time I installed Node.js back in 2013. It was version 0.10.something, and the installer was maybe 10MB. Fast forward to today, and Node 26 is pushing 120MB. Bun? 60MB. Deno? 90MB. Somewhere along the way, our JavaScript runtimes bulked up — more features, more bundled tooling, more dependencies, more of everything except minimalism.

So when I stumbled on a Show HN post for Ant — a JavaScript runtime that fits in 9MB and cold-starts in 5 milliseconds — I had to try it. Not because I’m unhappy with Node (I’ve built production apps on it for over a decade, and if you’re still getting used to npm 12’s install scripts being disabled by default, I feel your pain), but because there’s something compelling about a tool that does less but does it faster.

Ant bills itself as “a JavaScript runtime that carries more than it weighs.” After spending a weekend putting it through its paces, I can tell you: that’s not marketing fluff. Let me walk you through what Ant actually is, how to install it, and where it genuinely shines — no hype, just terminal output.

What Makes Ant Different?

Most JavaScript runtimes today wrap an existing engine — V8 for Node and Deno, JavaScriptCore for Bun. Ant doesn’t. Its engine, Ant Silver, is hand-built from scratch. We’re talking NaN-boxed values, a custom bytecode compiler, a JIT backend powered by MIR, and a generational garbage collector. All in about 8MB of compiled binary.

Here’s what that means practically:

• Binary size: ~8-9MB vs 120MB for Node, 60MB for Bun, 90MB for Deno
• Cold start: ~5ms vs 31ms for Node, 13ms for Bun, 25ms for Deno (importing Hono, registering two routes, and exiting)
• compat-table: 100% pass rate — 1,511/1,511 tests across ES1 through ESNext
• WinterTC conformant: Meets the Ecma TC55 Minimum Common API spec for server-side JavaScript
• License: MIT — fully open source, 422 stars on GitHub as of this writing

The kicker? It runs real npm packages. Hono, Elysia, React, TypeScript — they all work out of the box.

Installing Ant: One Line, Three Seconds

Installation is refreshingly simple. Open a terminal and run:

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

That’s it. No Homebrew tap, no npm install -g, no adding repos to your package manager. The script detects your OS (macOS or Linux, arm64 or x86_64) and drops a single ~8MB binary into place.

Let’s verify it worked:

$ ant --version
Ant 12.1.15dd25d.1

If you’re on Windows, you’ll need WSL (which, if you’re reading this blog, you probably already have set up). Native Windows support isn’t there yet, but the installer covers everything else.

Running Your First Script

Ant uses the standard fetch-based server model popularized by Bun and Deno. Create a file called hello.ant.js:

// hello.ant.js
const handler = (req) => {
  const url = new URL(req.url);
  const name = url.searchParams.get('name') || 'World';
  return new Response(`Hello, ${name}! — from Ant`);
};

export default {
  port: 3000,
  fetch: handler
};

Run it:

$ ant hello.ant.js
Listening on http://localhost:3000

$ curl http://localhost:3000/?name=Felix
Hello, Felix! — from Ant

The response time is basically instant. No JIT warmup phase, no delay on first request. That cold-start advantage isn’t just a benchmark number — you feel it immediately.

Package Management: 40x Faster Than npm

Node has npm, Bun has its own installer, Deno uses URL imports. Ant takes a hybrid approach — it speaks the npm protocol but installs packages through its own registry and resolver.

Installing a package is exactly what you’d expect:

$ ant i hono
installed  hono@latest
1 package installed  [155ms]

That’s 155 milliseconds from zero to a working Hono installation. For comparison, the same operation in npm takes about 6 seconds on my machine. Ant claims up to 40x faster package installs, and from what I’ve seen, that’s not an exaggeration for smaller dependency trees.

Ant also ships with its own registry at ants.land. It speaks the npm protocol, so anything you publish there works with npm, yarn, pnpm, or bun too. You can publish your own packages with:

$ ant land login
$ ant land publish
published  @you/[email protected]

TypeScript Without the Build Step

One of my favorite Ant features: it runs TypeScript natively. No tsconfig.json wrangling. No watching files. No dist/ folder cluttering your repo.

// server.ts
import { Hono } from 'hono';

const app = new Hono();

app.get('/', (c) => c.text('Hello from Ant with TypeScript!'));

export default app;

$ ant server.ts
Listening on http://localhost:3000

Coming from a Node + TypeScript setup where I need ts-node, tsx, or a full build pipeline just to run a script — this is genuinely refreshing. It just works. Ant handles module resolution, type stripping, and compilation transparently.

Building a Real Hono Server

Let’s put it all together with a slightly more realistic example — a REST-style API with Hono:

import { Hono } from 'hono';
import { cors } from 'hono/cors';

const app = new Hono();

app.use('*', cors());

const todos = [
  { id: 1, title: 'Try Ant JS', done: true },
  { id: 2, title: 'Write a tutorial', done: true },
  { id: 3, title: 'Deploy something with it', done: false },
];

app.get('/api/todos', (c) => c.json(todos));

app.get('/api/todos/:id', (c) => {
  const todo = todos.find(t => t.id === Number(c.req.param('id')));
  return todo
    ? c.json(todo)
    : c.json({ error: 'Not found' }, 404);
});

app.post('/api/todos', async (c) => {
  const body = await c.req.json();
  const newTodo = { id: todos.length + 1, ...body };
  todos.push(newTodo);
  return c.json(newTodo, 201);
});

export default app;

$ ant todos.ts
Listening on http://localhost:3000

$ curl http://localhost:3000/api/todos
[{"id":1,"title":"Try Ant JS","done":true},...]

Everything works: CORS, route params, JSON parsing, POST bodies. No adapter layer, no configuration file — just write Hono code and run it.

The Sandbox Feature: Running Untrusted Code Safely

Here’s something neither Node nor Bun ships out of the box — a hardware-isolated sandbox for running untrusted JavaScript. Ant uses KVM or Hypervisor.framework to spin up lightweight VMs for each sandbox:

import { Sandbox } from 'ant:sandbox';

const box = new Sandbox({
  mount: '.:/workspace',  // read-only mount by default
});

await box.run('untrusted.js');
await box.close();

By default, sandboxes have no network access and read-only filesystem mounts. You explicitly grant write access and open specific ports. This is exactly the kind of defense-in-depth I talked about in my supply chain security guide for AI-assisted development — having a hard boundary between trusted and untrusted code is becoming essential, not optional.

This is useful for:

• Running user-submitted code in a coding platform
• Evaluating third-party scripts before running them in production
• Plugin or extension execution in your app

Where Ant Falls Short (Real Talk)

I’ve been writing JavaScript for over a decade, and I’ve learned that no runtime is perfect. Ant has some real limitations right now:

• Windows support: No native Windows build yet. WSL works fine, but it’s an extra hop for devs on Windows.
• Ecosystem maturity: Node has a >10-year head start. While basic npm packages work, complex native addons (N-API is still partial) may not.
• test262 conformance: Ant passes about 64% of the full ECMAScript test suite. For everyday code you won’t notice, but edge cases exist.
• Tooling: No debugger, no profiler, no inspector protocol. You’re working with console.log for now.
• Community: 422 GitHub stars and one primary maintainer. Compare that to Node’s massive ecosystem, and the risk is obvious.

That said — Ant is MIT-licensed, actively developed (1,748 commits and counting), and the architecture is genuinely impressive for a solo project. The limitations are real, but as I’ve written before about new tools that deserve scrutiny, they’re also the kind of thing a growing community can address over time.

Should You Use Ant in Production?

Right now? Probably not for anything critical. But that’s not really the point.

Ant shines in specific scenarios:

• Serverless functions — where cold start time directly impacts user experience
• Edge computing — where binary size and memory matter
• CLI tools — where you want to distribute a script without asking users to install Node
• CI/CD pipelines — where every millisecond of setup time adds up across hundreds of runs
• Learning tool — honestly, reading Ant’s source code taught me more about how JavaScript engines work than any blog post ever did

I’m keeping it in my toolbox for side projects and serverless experiments. For production Node apps with complex dependency trees and native modules? Stick with Node or Bun. But for lightweight APIs, scripts, and TypeScript services where startup time matters — Ant is genuinely worth a spin. And if you’re worried about running unfamiliar code from a new runtime, you’re right to be cautious — that’s healthy engineering discipline.

The fact that one developer built a JavaScript engine, compiler, JIT, package manager, and runtime that runs real npm packages in a single 9MB binary is the kind of thing that reminds me why I love this industry. Sometimes the best tools aren’t the ones built by massive teams with infinite funding. Sometimes they’re the ones built by someone who just refused to stop.

Give it a try. Install it, write a simple server, see how fast it feels. Then maybe star the GitHub repo — projects like this deserve the encouragement.