#Flux

A total, deterministic dataflow language for the web platform. One small VM — with its compiler — runs inside the browser and stands behind a whole class of application: a live chart, a dashboard, a data-visualisation, an animated scene, a server-checked game. The usual move bundles a browser engine to ship web apps on the desktop; Flux runs the mirror move — it makes the web page itself the home for rich, interactive applications: GPU-drawn, reproducible to the byte, and safe to run code you did not write. You describe what a value is; the engine decides when to compute it, and proves it can never repaint, escalate, or drift a byte. Financial charting is the flagship — not the boundary.

Start the Guide → · Browse the Reference →

Figure — feeds, inputs and pointer events pass through one FVM that drives a chart, an app UI, an animated scene, and a server-checked game.

#One line, a whole chart

Everything Flux is meant to feel like is in a single line. This is a complete, shippable program:

plot rsi(close, input(14, 2..50, title: "Length"))     // rsi : osc(0,100) → own pane, 0–100 scale, guides 30/70

Nothing about placement, scale, reference lines or parameter plumbing is written anywhere, and none of it needs to be — it is all inferred from the kind of the expression, the dimensional type that says what the value is physically:

• close has kind price; rsi maps any scalar quantity to osc(0,100) — a bounded, dimensionless oscillator.
• An osc(0,100) shares no scale with price, so it materializes in its own pane with a fixed 0–100 scale.
• The conventional guide lines at 30 and 70 come from the operation’s metadata and are drawn automatically.
• input(14) declares a parameter, and the engine derives a typed control from it — the slider below this live chart. Dragging it retunes the value and re-runs the graph; a range like input(14, 2..50, title: "Length") bounds the slider, and deleting the wrapper removes the control.
• The series is registered — name, render style, semantic class, even its accessibility description — all from the kind.

Figure — the kind of the expression furnishes the pane, the scale, the guides and the parameter control; nothing is configured by hand.

One line. Nothing configured — the kind said everything needed. And it is replayable, bounded, and byte-identical for free. When you do want control, every one of these defaults is overridable in place; Your first session walks through it.

This site is built to show that, not only describe it: where the engine is wired, an example like the one above renders as a live Flux island — a <div> the real engine paints inside an otherwise static page — rather than a screenshot; where it is not yet wired, you see the code and a note. The honest form of a demo is one that runs.

#One idea: every value is a stream

A Flux value is not a number sitting in a variable. It is a stream: a value as it evolves along an ordered axis of data units — sensor readings, log lines, an RSS or WebSocket feed, the cells of a spreadsheet, game turns, or (in the flagship domain) market bars. Where the data comes from is the host’s business: the net pillar speaks generic verbs and codecs, so a stream is a stream whether it arrives over a socket, a feed, or a file. close is not “the latest price”; it is the whole history of closing prices, one value per unit, up to now. Everything else follows from taking that seriously:

• A constant is a degenerate stream — the same value at every unit — so 2 and close are the same kind of thing and combine freely.
• Arithmetic is element-wise: fast - slow subtracts two entire histories, unit by unit, yet the engine evaluates it incrementally, one new value per new unit.
• There is no index and no loop. You never write for i, never manage a buffer, never decide when to recompute.

fast = ema(close, 12)          // a stream: the 12-unit exponential average, over all history
slow = ema(close, 26)
plot fast - slow               // element-wise difference — itself a stream

That is the mental model in one sentence: you describe a pure expression, the engine evaluates it. No for i, no buffer, no await, no “on new bar” callback, no cache invalidation. The compiler inlines your definitions into a typed incremental DAG, checks it — kinds, causality, totality, plane boundaries — and advances it either live (one step per new unit) or in batch (full-history replay). Both runs are the same function and produce the same bytes.

#Guaranteed by construction

Six properties the language enforces by construction — each proven about every accepted program, each linked to the page that specifies it.

No-repaint is a theorem, not a discipline. A value produced for a step can never change afterwards, because reading the future is inexpressible: a negative delay does not parse into a meaning. The stream you compute live and the stream you replay over history are the same function. → Guide §11 · Spec · Time & state

Figure — once a value is produced for a step, nothing downstream can shift it; live and replay trace the same line.

Byte-exact determinism gives you real replay and golden tests. The same program on the same data produces the same bytes — between the editing interpreter and the compiled WASM, between two runs, ARM ≡ x86 — because every source of floating-point variance is pinned as language policy. The equivalence is not assumed: it is verified at every compilation by running both and asserting bit-equality (invariant I7). → Guarantees · FVM · Verification

Figure — interpreter and compiled module run on real data and must agree to the byte, or the artifact does not ship.

Kinds infer your presentation. Every stream carries a dimensional type — price is a point, level a displacement, ratio a dimensionless scalar — so high - low is a level and close + rsi(close, 14) is rejected at compile time with a dimensional explanation. The kind is rich enough to derive the presentation, which is why one line of mathematics becomes a correctly furnished chart. → Guide §5 · Spec · Kinds

Figure — the dimension travels with the value; presentation falls out of it.

One dataflow VM, many kinds of app. The four planes span compute → show → animate → interact, so a live chart, a dashboard, a data-visualisation, an animated scene and a server-checked game are all the same kind of object, built from one algebra on one VM. Financial charting is the flagship specialization, not the definition; nothing in the model is specific to markets. → Guide §8

The four-plane firewall lets guarantees survive decoration. Computation and presentation are separate planes, and dependence crosses in exactly one direction: presentation may read analysis; analysis may never read presentation. An animated, randomized effect can sit pixels away from a signal without any possibility of contaminating it, because the dependency cannot be expressed — a violation is [ErrFirewall] at compile time. → Guide §8

Figure — decoration reads the numbers; the numbers never read decoration.

Untrusted code runs as a routine. Scripts have no ambient authority: the language has no fetch, no DOM, no eval, no file handles, and every effect is default-deny. A Cmd carries inert data — a sound name, a storage key, a score — never a token or handle, and the host executes it only under a capability the user granted. A shared artifact arrives as WASM only, with an inspectable, transitively aggregated manifest of everything it may ask for, visible before installation. → Guide §11

Figure — the script hands the host a description; the host holds the resource and decides whether it runs.

#One VM, many surfaces

A complete application has parts with very different needs. A computation must be exact and reproducible. An animation must read the clock and may use randomness. A screen transition must interpolate freely without corrupting data. Application state must respond to user events and drive effects. Flux does not average these into one compromise; it separates them into four cooperating planes — one language, one expression algebra, four sets of rules:

The same three programs — an analytic, a scene, an application — read the same way, each with one small twist of the same algebra. On the CANVAS plane, every property is a signal: a constant, a data stream and an animation generator like spring(close) are the same kind of thing, and events (on … ->) spawn or tween primitives. On the APP plane, a pure, total update folds a message journal into new state plus a list of inert commands — so state is replayable by construction.

Scene graphics and text both render on the WebGPU path — text as an SDF glyph atlas, crisp at any zoom and DPR — sidestepping HTML-DOM layout cost entirely. Determinism here means bit-identical compute and a deterministic scene: the same numbers and the same scene on every machine, not the same pixels across different GPUs.

And that GPU path is not flat by necessity. Here is the same kind of chart lifted into real 3-D depth — each candle standing into the depth axis by its volume, tilted into perspective and slowly turning, rendered live on WebGPU as you read:

plot ema(close, 20)

Each surface is delivered as an island: the page around it stays an ordinary static HTML shell — cheap, fast, indexable — while the island carries the live, visual, interactive parts a static page cannot. Visual richness inside an island — background, border, radius, shadow, type — arrives as typed style props the host validates and applies, never a raw CSS string, so the one injection surface a UI language usually exposes is not filtered but structurally absent. That is what lets a stranger’s island render beside yours and touch none of the data your own logic depends on.

#One language, not a stack

Assembled the usual way, an interactive, data-rich page is a stack: a UI framework, a charting library, a 3-D library, a state manager, and — the moment any of the code is not yours — a sanitizer. Flux is one language in the place of that stack, and it carries four properties the stack cannot: every program terminates and states its bounds (totality); the same program produces the same bytes on every machine, so replay and server-checked anti-cheat become possible (byte-identical determinism); the memory plan is fixed at compile time (bounded memory, zero steady-state allocation); and every effect is a declared, default-deny capability, so running a stranger’s island is routine, not a risk assessment (capability-safety by construction).

#Four pillars, one book

The documentation is organized around the owner’s distinction — the ideas, the semantics, the execution model, and the batteries — so a returning reader routes in one click.

• The Language — the mental model, the four planes, the seven design pillars, the non-goals. Start here to understand the shape of the whole thing. → Overview
• Language Spec — the formal semantics: lexical structure, grammar, kinds, operators, inference, and the plane rules, stated normatively. → Grammar
• The FVM — the execution model: the compiler pipeline, interpreter ≡ WASM (I7), the optimizer with translation validation, memory, concurrency, and verification. → Overview
• The FDK — the batteries: the standard prelude and the pillar APIs, all held to the same determinism bar as the core. → Overview

#Batteries included

The FDK (Flux Development Kit) ships the standard prelude and the pillar APIs — compute · collections · color · text · i18n · units · net · display · host-services · server · asset/currency — all bounded, capability-gated, and specified to the same determinism bar as the language core. → FDK overview

#What Flux deliberately won’t do

A trust page that only lists strengths is a sales page. Flux is client-side and reactive, and that is a boundary, not a boast: it is not a backend, not a general-purpose systems language, and not for unbounded or SIMD-heavy computation. It is total — every program provably terminates — which by definition makes it not Turing-complete: unbounded over time, bounded per step, in the synchronous-dataflow lineage of Lustre and SCADE. A program that cannot state its bound is rejected with [ErrTotal] at compile time rather than killed by a timeout, and an unbounded inner loop on a render path — the one thing that limit rules out — is a hung tab you never wanted. Determinism also forecloses SIMD, floating-point reassociation, and true ambient randomness in the pure planes; presentation goes through vetted primitives rather than free-form DOM. Each of these is a choice with a rationale, named with the same confidence as the strengths. → What Flux deliberately doesn’t do · Guarantees — what is not guaranteed

The public sharing and marketplace rollout follows v1; the trust model that makes it safe is v1 and is not weakened anywhere.

#Three doors

• Learn — read the Guide in order: it builds the mental model from one line to a small application, one runnable idea at a time.
• Look up — the Reference: the normative language across four pillars, plus the full FDK surface and the capability catalogue.
• Evaluate trust — the Guarantees page: what is promised, and the machine check that enforces each promise.

Reading paths for where you stand:

• New to Flux — What is Flux → Why it is built this way → Your first session → The four planes.
• Writing programs — the Cookbook, then the FDK reference for the API you need.
• Evaluating the guarantees — Guarantees, then Compiler & runtime and Kinds.

#See also

• What is Flux — start here if the language is new to you.
• The seven design pillars — the guarantees behind everything above.
• Kinds — the dimensional type system the rest leans on.
• Guarantees — what is promised, and how each promise is machine-checked.
• FDK overview — the libraries and the capability model.
• Glossary — every term, precisely defined.