Targets · JavaScript · Coding standards
The generated JavaScript is not free-form — it follows the same coding standards the Frenzi project holds its hand-written code to. There are two layers: a set of global rules that every target language obeys, and a set that is specific to JavaScript . Together they are why the output is plain, auditable, and sits line for line against the Program source it came from.
How a Program becomes JavaScript, in parts. Start with the introduction, then follow each part into the rendered output and the runtime it links against.
The single rule that shapes the output more than any other: assign every result to a named local before you pass it on. A function call's arguments are only ever plain variables, constants, or closures — never another call nested inline. One operation per line; every step has a name.
This is exactly why the rendered code reads like the Program that produced it: Program itself has one binding per step ( LET ), and the generator maps each binding to one var and each call to one line. Nothing is ever folded together, so every intermediate value is visible, nameable, and easy to step through in a debugger. A compound Program expression becomes a straight run of named steps:
These apply to every target language, so the same program produces structurally identical code in JavaScript, Dart, Swift and the rest. The ones that shape the JavaScript you see:
On top of the global rules, the JavaScript target follows conventions chosen so the output is plain, broadly browser-compatible, and needs no build tooling to run:
An embedded Program is JavaScript you can open and read. Because it obeys these standards, that JavaScript is uniform from one program to the next: named intermediate values, positional constructors, namespaced functions, one operation per line. The pages that follow — keywords , runtime , drivers — all render to code in exactly this shape.