ZIPP

What is ZIPP?

ZIPP is a JavaScript execution engine written in Rust. Its lexer, parser, bytecode compiler, register virtual machine, garbage collector, inline caches and native JIT implementation live in the same project. It is aimed at embedders and tools that need a runtime they can inspect and integrate, rather than a complete browser or a replacement operating system.

The engine can run natively or as WebAssembly. An experimental Python frontend compiles Python source directly into the same register bytecode. It does not ship CPython or translate the program into JavaScript for a second interpreter. Language coverage and host capabilities still depend on the selected build profile.

JavaScript execution with explicit host capabilities

The native CLI runs scripts and module entry points, while the Rust embedding API lets another application own the engine instance. The browser build can run inside a Web Worker. The embedding application decides which APIs and resources are exposed, including any database, network or user-interface bridge.

That distinction matters for portability. A JavaScript language feature is not the same as a browser DOM API or a Node.js system module. A script that depends on one of those environments needs the corresponding host integration or a supported alternative. Evaluate the actual application workload rather than assuming language compatibility implies platform compatibility.

• Use native execution for a supported embedded or command-line workload.
• Run a WebAssembly engine in a browser worker.
• Supply application-specific host functions and resource budgets.
• Explore parser, compiler, VM and optimisation code in one repository.
• Compare reproducible workloads and documented conformance evidence.

Python on the same VM, with an experimental surface

The Python frontend is an active compatibility experiment. The playground supports projects containing multiple files and data, with an editor, a virtual filesystem, a console and graphical examples. Supported Python code is lowered into ZIPP bytecode and executes in the same engine as JavaScript.

A trusted-code build can enable Python-to-JavaScript evaluation in the same VM instance. That optional interoperation copies supported scalar and container values; it is not a general system of live object proxies across two fully interchangeable languages. Review the interoperation contract before exposing it to untrusted input.

The bundled Torch-compatible subset includes eager CPU tensor operations, autograd and training capabilities. It is not a drop-in replacement for the full PyTorch ecosystem. Existing Python packages with native dependencies or unsupported runtime behaviour need individual evaluation.

Browser GPU compute is a separate execution layer

Supported tensor models or explicit compute graphs can be passed from the playground to a browser GPU host. That host executes supported operations through WebGPU compute shaders or WebGL2 fragment shaders, with a visible CPU fallback when automatic selection allows it. Ordinary JavaScript can also use the graph runtime without the Python frontend.

This does not move arbitrary JavaScript or Python instructions onto the GPU. ZIPP runs the program; the GPU backend handles the supported numerical graph. The experimental Torch compile path also has asynchronous submission extensions, so it does not behave like PyTorch’s synchronous compile API.

GPU availability and performance depend on the browser, adapter, graph shape, transfer costs and supported operations. Small demonstrations establish that a path works, not that it outperforms a CPU. The compatibility guide records the current limits, including graph preparation and supported training operations.

The engine underneath SoftN and FormLogic logic

SoftN uses ZIPP to run application .logic files and exposes permitted host bridges for data and interface behaviour. FormLogic uses ZIPP in its browser/server form scripting and hosted-app execution paths. Those integrations choose their own budgets, permissions and execution profiles.

The engine itself is not the database or the access-control system. A host remains responsible for isolation, allowed I/O, process supervision and resource limits. Use the appropriate hardened profile for untrusted workloads; a native JIT configuration for trusted code is not automatically an equivalent security boundary.

Evaluate the evidence for your workload

The project publishes Test262 evidence, benchmark methodology and raw results with scope and corrections documented separately. Treat a conformance percentage as a statement about the named suite and configuration, not a universal claim about every JavaScript host API. Review original and corrected result sets when assessing compatibility.

Start with the browser playground or a native release, then run representative scripts from your own application. Record cold start, steady-state time, peak memory, output correctness and host-boundary costs separately. For Python or GPU work, check the compatibility guide and confirm which backend actually ran.