RingScript moves quickly, and everything it claims is
measured. This page keeps the short version of what has landed, newest
first — each entry links to the code, the documents or the pages behind
it.
August 22, 2026
The local-first library set is complete
pwa 2.0.0 (partition-tolerant by default: ordered idempotent
replay, a loud storage-full refusal, the degraded-mode rung readable by
Ring rules, snapshot/stream with the 8-second alarm), table 1.2.0
and the new money 1.0.0 (integer minor units, exact parsing, one
rounding rule, allocation that never loses a centime) are all published
— and every one is consumed by a shipped sample. The CLI grew
update, add --page and two verified caches on
the way. The story: The local-first
set is complete; the design behind pwa 2.0:
PARTITION-FOUNDATIONS.md.
August 9, 2026
A local-first business application, end to end
Route Orders is a field-sales order pad — a representative walks
a route of shops and takes orders — with every business rule running in
Ring on the device: price tiers, the full-case discount, tax, the stock
check and the credit limit. The server is used exactly twice, to pull the
reference data and to push the finished orders.
There is a switch on the page marked Cut the connection. Press
it and keep working: nothing degrades. A measured session came to
9 actions on the device against 2 network calls totalling
3 KB, and zero actions that failed for want of a line. The
article that goes with it carries the two HTTP endpoints in full, so the
pattern can be built against a back end written in any language.
RingScript is measured against Lua 5.4 and QuickJS — two
C interpreters compiled to WebAssembly, same weight class — and the
result now has a home here rather than only in the repository. Ring wins
four of the nine scenarios, including JSON encode at
0.134 ms, ahead of QuickJS's native
codec, and a megabyte through JSON at 1.53 ms
against 14.2 and 154.7. The five it loses are published with their causes,
because those causes are what produced the wins.
The whole table was re-measured for this, in one recorded run that also
rewrites results.json — the published numbers and the data
file behind them are now the same run. They had drifted: the file still
held a mid-day snapshot saying objects cost 6.12 ms while the page
said 3.05.
The whole site now sits on one type scale: a hero voice, a title
voice, and one reading size, with nothing anywhere below the
legibility floor. That is not a taste call — it is
a
constitution of interface rules
pinned by this family of projects, and the site was measured against it:
every rendered text node checked for computed size and true contrast,
every menu checked against the tree it claims. 396 findings became
zero. The menu lost a stop it should never have had, the two branches
that go a level deep now show their path, and three syntax colours were
darkened until they earned their meaning.
Three new posts joined the blog, chosen from the whole project rather
than the last thing we happened to build: what a browser cannot give a
Ring program, and why the Emscripten build was replaced by Zig.
The first of the two runs live Ring inside the page.
Working with data: a real app, and what it sharpened
A working savings-circle register now runs on the site: 20,000 records
living inside the Ring VM, filtered, sorted and totalled live — every
interaction timed against how a page has to feel, every answer
verified against an independent computation. Driving it at full size made
the runtime better: sorting rows by a column went from
257 ms to 16 ms at 20,000 rows,
aggregating over a sorted view went from
19.8 s to 0.28 s at 50,000, and a
payload-shape rule cut first load from
7.9 s to 0.88 s.
The same scenarios, the same measurement discipline, three
interpreters compiled to WebAssembly. The headline is robustness parity:
10,000 evaluations with errors mixed in grow nobody's heap, and 1,200
hostile inputs kill nobody. On speed, Ring now wins string building,
sorting, JSON encoding — ahead of QuickJS's native codec — and the
one-megabyte round trip outright; the remaining gaps are named, with
their causes.
Six items, each traced to a root cause in the VM source before any
code moved. A fresh VM instance now starts in
3.2 ms (was 6.7) by stamping memory from a
snapshot instead of re-initialising. The JSON codec moved to C — held
byte-identical to the pure-Ring reference by a permanent test — making
encoding 55× faster and a one-megabyte round
trip cost 6 ms. Object creation, dispatch
and the per-call overhead each took their own measured cut.
A week's worth of "what could go wrong" made executable: the page
calling Ring back mid-run is now refused safely instead of corrupting the
outer program; boot() downloads scripts in parallel and
answers clicks that arrive before it finishes; a malformed megabyte of
JSON went from freezing the tab for four minutes to an ordinary error;
and an endurance page lets you soak the runtime on the phone in your
pocket, with a build whose heap can refuse growth on purpose.
The core promise — one VM living for the whole page — met its two
hardest tests. A leak that grew the heap by one class per evaluation
(invisible in short runs, fatal over a long session) was found by
profiling and fixed; memory exhaustion stopped taking the page down and
became an ordinary, recoverable error. Two new suites — a 40,000-eval
soak and a 4,000-case fuzzer — now stand guard so neither can return.
Getting started became one download and one double-click: a zip with
the runtime, a tiny web server for Windows, macOS and Linux, and a
working app structure a desktop programmer can read in one sitting. The
analog-clock tutorial builds a real page from nothing in six steps, and
this site went live to hold it all.
Hardening RingScript surfaced two bugs in the Ring VM itself — a crash
when eval() defines a class with a private
section, and a portability slip that broke string-to-number comparison on
musl-based systems. Both were reported upstream with one-line fixes, in
the spirit this project intends to keep: what we learn goes back to
Ring.
RingScript 0.9 — the Ring VM, in the browser, verified
The announcement that started this site: the real Ring 1.27 virtual
machine compiled to WebAssembly — not a transpiler, not a look-alike —
producing output verified program by program against native
ring.exe across Ring's own samples and every runnable
example in its documentation. One resident VM per page, ~380 KB,
offline by design.