Compiles to the vanilla JavaScript you would have written

How it works

Standard JavaScript in. Vanilla DOM code out.

There is no compiler magic to learn and nothing to un-learn. The source on the left is a real file that runs unchanged in a browser through an import map. The output on the right is the actual emitted code — hoisted template, positional walks, one tiny effect per dynamic hole. It is the code a careful developer would have written by hand.

import { signal, computed, html, mount } from '@amojs.dev/core';

function Counter() {
  const count  = signal(0);
  const double = computed(() => count.value * 2);

  return html`<button onclick=${() => count.value++}>${count} × 2 = ${double}</button>`;
}

mount(Counter, document.body);

import { signal, computed, mount } from '@amojs.dev/core/runtime';
import { tpl as _$t, bindChild as _$child,
  bindEvent as _$event } from '@amojs.dev/core/compiled';

const _t0 = _$t("<button><!----> × 2 = <!----></button>",
              [[0,0],[0,2]]);

function Counter() {
  const count  = signal(0);
  const double = computed(() => count.value * 2);

  return (() => {
    const _r  = _t0().firstChild;
    const _n0 = _r.firstChild;
    const _n1 = _r.childNodes[2];
    _$child(_n0, count);
    _$child(_n1, double);
    _$event(_r, "click", () => count.value++);
    return _r;
  })();
}

mount(Counter, document.body);

Notice what is not there: no component registry, no lifecycle object, no virtual nodes, no diff. When count changes, exactly one expression re-evaluates and exactly one text node is written. And because the compiler saw that html`` is no longer used, the template parser is never even loaded.

Why AmoJS

A framework you can uninstall

Every framework asks you to bet your codebase on its future. AmoJS is designed so that bet is reversible — and so that the day-one experience needs no toolchain at all.

Measurements

Numbers, not adjectives

Every figure below is a gate in continuous integration, not a claim in a README. If one regresses, the build goes red.

Measured on core 0.6.x. “All-in” means bundled, minified and gzipped with the runtime included — the way frameworks quote size.

Against Lit — the nearest neighbour

Lit shares the technique: html`` tagged templates, zero dependencies, no build required, one cached template cloned per instance. What differs is the update model — so that is what these numbers isolate. Lit is measured in its smallest configuration (bare html + render, no LitElement, no decorators, no shadow DOM).

The same app: a card with five bindings, an event listener and a keyed list. DOM mutations tie in every row — Lit does no wasted DOM work either. The difference is how many expressions must run to discover that.

What these numbers do not measure: ecosystem, server-side rendering, tooling maturity, browser-vendor backing and years of production hardening — all of which Lit, React, Vue and Svelte have and AmoJS does not. Being technically distinct is not the same as being a safe default.

Surface area

The whole API is twelve names

Three concepts, and that is the framework. There is deliberately no component API and no lifecycle object: a component is a plain function returning a DOM node, props are its arguments, composition is an ESM import, and teardown belongs to the ownership tree.

A template hole is exactly one of three things — a constant written once, a signal bound reactively, or a function wrapped in an effect. The same rule holds compiled and uncompiled, which is why there is no “this works in dev but not in prod” class of bug.

Routing · @amojs.dev/router

You never write a loading state again

The router is built on the Navigation API (Baseline since January 2026) — the platform's own routing primitive, which every older router still hand-builds around the History API. One idea carries the whole design: a page's load() settles before the page renders, so data is a resolved value, not a resource. No page ever sees a loading or error state — those live in one place, the router options.

import { html, mount } from '@amojs.dev/core';
import { router } from '@amojs.dev/router';

const app = router({
  '/':          () => import('./pages/home.js'),
  '/users':     () => import('./pages/users.js'),
  '/users/:id': () => import('./pages/user.js'),
  '*':          () => import('./pages/404.js'),
}, {
  pending: () => html`<p>loading…</p>`,   // once, for every page
  error: (err, retry) =>
    html`<p>${err.message} <button onclick=${retry}>retry</button></p>`,
});

mount(app, document.getElementById('app'));

// pages/user.js
export async function load({ params, signal }) {
  // the navigation's own AbortSignal — an abandoned
  // page's fetch cancels itself, zero router code
  return (await fetch(`/api/users/${params.id}`, { signal })).json();
}

export const title = (data) => data.name;

export default ({ data, params }) =>
  html`<h1>${data.name}</h1>`;   // never a promise, never a spinner

The platform does what other routers hand-build: plain <a href> just works — no <Link> component, no click listener, no target="_blank" edge cases; stale responses abort themselves; scroll restoration on back/forward is free; a plain <form method="post"> is handed to the page's action() with native validation running first. A browser without the Navigation API gets full page loads — the app is slower, not broken. The router adds ~1.3 KB min+gzip (its own CI gate), never loads the template parser, and amo eject hands it over with the runtime — the router you can uninstall.

Two honest notes: the browser tab spinner runs while load() is pending — that is the platform's real progress indicator, not a page reload; and the URL commits before the content arrives, which differs from React Router and may surprise you.

Anti-goals

What AmoJS will never have

These are closed decisions, not open questions. Knowing what a tool refuses to become tells you more than its feature list.

• Hydration. Hydration exists so a framework’s client runtime can re-attach to server HTML. AmoJS compiles to the code you would have written; there is no runtime to re-attach. Server rendering, when it lands, is islands — static HTML plus interactive pieces that build their own DOM.
• A virtual DOM. Not as an option, not behind a flag.
• Proxy-based deep reactivity. No human writing vanilla JavaScript wraps their arrays in a Proxy, so magic mutation cannot be ejected as “code you would have written”. Replace the array, or put a signal inside each item.
• Global event delegation. A real addEventListener on the element is the answer — identical semantics to vanilla, and no escape hatch to document.
• A clever compiler. It rewrites templates and import specifiers, and touches nothing else. It never reasons about module boundaries, lazy loading or dead code — which is why it can be trusted next to any other tool in your pipeline.

Status

Honest state of the project

AmoJS is pre-release and built in the open. The core, compiler, CLI, router, server rendering and ownership model are done and tested; documentation and the public release are not.

• v0.1 ✓Reactive core — signals, computed values, html`` templates, mount. Runs in a browser with no build.
• v0.2 ✓The compiler — parse → IR → codegen, plus the identity benchmark that caps output at +10% of hand-written vanilla.
• v0.3 ✓Blocks — conditionals and keyed lists, behaving identically in both modes.
• v0.4 ✓The CLI — amo build and amo eject.
• v0.5 ✓Composition — components, props, the ownership tree, and a dispose suite that proves no leaks.
• v0.6 ✓Size and speed — CI budgets, DOM-work parity, benchmarks against Solid, Vue Vapor, alien-signals and Lit.
• v0.7 ✓Public packages on npm, and the router — @amojs.dev/router, built on the Navigation API, pages receive resolved data.
• v0.8 ✓Server rendering as islands — a second codegen over the same IR emits strings, so amo ssg renders pages on node. A page with no island ships zero script bytes. No hydration, ever.
• v0.9 ✓Rendering per request with amo build --target server, a dynamic <title>, prebuilt single-file bundles, and @amojs.dev/vite for projects that want a bundler.
• nextThis site, built with amo ssg — documentation as live, pokeable demos rather than prose.
• v1.0Public release — documentation, a live playground on this domain, and a stable API.

FAQ

Questions people ask first