Zipp releases

Latest: v0.0.35, 11 November 2026

A patch release with speed work, out the same day as v0.0.34's interpreter release. The experimental optimizing tier compiles a function that starts with a loop, with a fix contributed for issue #93; compiled loops that read and write globals are faster again; and frameless calls and object allocation do less work. The benchmarks page still shows v0.0.31's profile-guided capture; the release notes give v0.0.35's measurements against v0.0.34 and Node 24.

• New, from a contributor: the optimizing tier (ZIPP_OPT=1, off by default) compiles a function whose first instruction is a loop's head, through a preheader that merges the values the function is entered with and the values the loop carries back (codeandsolder's fix for #93; v0.0.34 had Tier O decline such functions). Under ZIPP_OPT=1, an integer loop at a function's start runs in 62 ms where the decline took 69, a floating-point one in 16 against 21, and a function that runs its loop once per call 2.4 times faster.
• Faster, compiled code: the blocks that hand an operation back to the interpreter come after a function's code instead of behind each operation, so the success path falls through; v0.0.34 had given one to every compiled global access. With the JIT, class-prototype-hot takes 0.81× v0.0.34's time, sparse-array 0.85× and nbody 0.86×.
• Faster, the interpreter: a small function run without a frame reads its captured variables through one fetch of its closure's list, and a number written to one skips the write barrier; allocating no longer reserves and probes 32 KB of stack in every function that makes an object. Interpreted, upval_rw takes 0.88× v0.0.34's time and is now ahead of node --jitless.
• Over 90 benchmark programs v0.0.35 takes 0.984× v0.0.34's time with the JIT and 0.997× interpreted; it is ahead of Node 24 on 72 of the 89 programs Node runs, and of node --jitless on 71 interpreted.
• v0.0.34 (11 November, not described here before): on the x86-64 command lines, interpreted loops and the calls they make run through a second, leaner form of the interpreter, whose instructions are small functions that jump from one to the next. Interpreted, it takes 0.83× v0.0.33's time over the 90 programs and is ahead of node --jitless on 71 of 89; a global deleted or given an accessor by code a running compiled loop called is no longer read as the plain variable it was; and Tier O no longer runs forever on a function that starts with a loop.
• WebAssembly modules: the six of v0.0.33 and v0.0.34, the same size. As published, the JavaScript engine is 1.25 MB on the wire, ZIPP Lite 0.78 MB, the TypeScript engine 1.32 MB, Python without torch 1.65 MB and the complete engine 2.02 MB; the torch package 0.40 MB. Loader zipp.mjs 1.5.0, unchanged, and host SDK 1.4.0.

Release notes and downloads on GitHub · docs/releases/0.0.35.md · v0.0.34 notes · v0.0.33 notes · v0.0.32 notes · v0.0.30 notes · v0.0.29 notes · v0.0.28 notes · v0.0.27 notes · v0.0.26 notes · v0.0.25 notes · v0.0.24 notes · v0.0.23 notes

Install

# Windows: the portable .exe runs from wherever you saved it
.\zipp-0.0.35-windows-x86_64-portable.exe js app.js
# or install zipp-0.0.35-windows-x86_64-installer.msi, which adds zipp to
# your PATH without administrator rights
zipp js app.js

# Linux x86-64 (zipp-0.0.35-linux-arm64 or -linux-armv7 on Arm), glibc 2.35+
curl -fL -o zipp https://github.com/f2i-com/zipp.org/releases/download/v0.0.35/zipp-0.0.35-linux-x86_64
chmod +x zipp
./zipp js app.js

# WebAssembly, for a web page: the loader zipp.mjs from the embed kit, and one
# engine (or its .wasm.br: the same engine, about a quarter of the size)
curl -fLO https://github.com/f2i-com/zipp.org/releases/download/v0.0.35/zipp-0.0.35-wasm-embed-kit.zip
unzip -j zipp-0.0.35-wasm-embed-kit.zip zipp-0.0.35-wasm-embed-kit/zipp.mjs
curl -fLO https://github.com/f2i-com/zipp.org/releases/download/v0.0.35/zipp-0.0.35-javascript.wasm

# From source, any platform with Rust 1.92
git clone https://github.com/f2i-com/zipp.org && cd zipp.org
cargo build --locked --release
./target/release/zipp --version --json

Zipp is not on crates.io or npm yet. The WebAssembly engines and the embed kit are meant to be served by your own host, over HTTP: a page needs zipp.mjs from the kit beside whichever .wasm it loads. Serve a .wasm.br with Content-Encoding: br and Content-Type: application/wasm and the browser decodes it; zipp.mjs 1.2.0 also loads one itself, decompressing it where the runtime can or falling back to the plain .wasm beside it. The embed section of the home page has a starter project, and the WebAssembly page explains the loader, its sandboxes and the Worker model.

Up to v0.0.25 the downloads were archives: zipp-<v>-x86_64-pc-windows-msvc.zip for Windows, zipp-<v>-x86_64-unknown-linux-gnu.tar.gz for Linux, which unpacks to a folder holding zipp, and zipp-wasm-<v>-web.zip and its siblings for the WebAssembly engines. From v0.0.26 they are the plain files above, and the WebAssembly page describes the engine files and the embed kit.

What a release has to pass

Pushing a vX.Y.Z tag runs the release workflow. It refuses to publish unless the tag object matches the checkout; the root Cargo.toml, the WebAssembly crate and the landing page all carry the same version; and the reusable CI, the full security workflow (including the pinned Test262 corpus), the native build and the WebAssembly build all pass at that exact commit. A green main at some other revision is not a release gate. The job is retry-safe: it re-downloads existing assets, verifies SHA256SUMS, and checks that BUILD-INFO.json is not dirty and names the right commit before deciding to do nothing. A dispatched re-run may skip the two longest gate jobs - the native workspace suite and Test262 - only when the identical tree has been through them elsewhere; v0.0.19 was published that way, with both run locally on the tagged commit (308 test binaries, 2,453 tests; 95,680 of 95,680 corrected-core executions) and every other job in the workflow, and so was v0.0.20, whose JavaScript engine source had not changed since v0.0.19 passed them. From v0.0.21 the workflow also builds the torch package with the two engines it pairs with, and refuses to publish unless python plus the package prints exactly what all prints over the torch suites. From v0.0.22 it also builds ZIPP Lite. v0.0.24's first run lost four gate jobs to GitHub runner shutdowns, and those jobs were re-run at the same commit before it published. v0.0.27 was dispatched the same way: its tagged commit changes only versions and release notes from 05d2bd9b, where the full security workflow, the native workspace suite and Test262 on 64-bit and 32-bit builds included, had passed. So was v0.0.28, after the CI and the full security workflow had passed on its tagged commit itself. So was v0.0.29: the full security workflow on its prep commit, 8cd844fd, had failed one test, a heap-ceiling regression, whose fix and the heap and limit tests around it were run before 58c92a59 was tagged, and Test262 then passed on the published Windows binary, with its JIT and without. So was v0.0.30: the full security workflow passed at ef3bea8a once its benchmark lane stopped running the hour-long comparison of the profile-guided training corpus, which tools/pgo.sh still runs before every profile-guided build, and the tagged commit, fd6b48a5, changes only a landing test from it; and Test262 then passed on the published Windows binary, with its JIT and without. So was v0.0.31: CI and the full security workflow passed at 051577de after its dependency audit had refused Wasmtime 44.0.3 for eight advisories, and the release run's own builds then found two faults no gate builds for, an extra parenthesis in the release smoke test's WebAssembly program and dead code on 32-bit Arm, fixed in 1a0098b0 and 85fb9d3e, which change no x86-64 code; the tagged commit, fcfb1934, changes only the release notes from them. The release's arm64 build ran the pinned Test262 corpus in full, and it then passed on the published Windows and Linux x86-64 binaries, with their JIT and without. So was v0.0.32, after its gate refused the first commit tagged: the first release run, at 6112d701, failed the pinned Test262 corpus on one test, strict and sloppy, a class's static initializer whose arrow reads the class's name through eval, which that release's own fix for arrows in class methods (08f34f83) had broken. The tag was moved to the fix, e312cf40, before anything was published, and the release run's CI and full security workflow, the corpus included, then passed at that commit, with the arm64 build running it in full. v0.0.33's gate caught a crash before the tag: the release build's dry run stopped on its arm64 build, where one Test262 test, staging/sm/extensions/recursion.js, overflowed the native stack instead of throwing a RangeError. The fix (78097701) bounds native re-entry by the stack the command line declares; CI, the full security workflow and the dry run then passed at that commit, and the release was tagged on it with only versions and notes changed (cc75c2a3). v0.0.34 was published twice: the build of 10 November was withdrawn within the hour and replaced by one with the optimizing tier's fix for #93 and without the 22% slowdown on a request loop that the first build's notes had reported. For v0.0.35 the release build's dry run, CI and the full security workflow, the corpus included, passed at cd86ccdb, and the release was tagged on it with only versions and notes changed (384cb93a).

All releases

Release notes for v0.0.1 through v0.0.17 live in the annotated tag messages; v0.0.18 is the first with a notes file in docs/releases/, and from v0.0.20 that file is the GitHub release body verbatim. The engineering journal tells the story between the tags.