#The vision

This page states what Flux is and what it is for, in one place, so that every other page can describe a mechanism without re-arguing the identity. It is the shortest chapter and the one the rest of the book refers back to. Nothing here requires prior knowledge of Flux, of our host chart, or of trading.

#One sentence

Flux is a total, causal, deterministic, capability-safe language for streaming computation and typed user interface, compiled to WebAssembly and the GPU. A single dataflow VM spans the whole arc a real application needs — compute → show → animate → interact — as one expression algebra under one set of guarantees.

That arc is the point. Most tools give you one part of it and leave you to assemble the rest. Flux is one language across all four.

#Three pillars of identity

These are what the language is for. They are distinct from the seven formal guarantees of Design pillars — those are properties the language has; these are capabilities it offers.

1. Streaming computation. Total, causal, deterministic math over an ordered stream of data units. Its origin is the market indicator; its general case is any bounded causal computation over a series — a sensor trace, a log, a game’s turns. This pillar is the mature core of v1.

2. Bounded data and collections. Real algorithms — sort, rank, group, graph traversal — over real data, staying total, bounded and replayable. Value-semantic containers (Vec, Map, Set, Deque, Tree) with a declared capacity are v1; the runtime-loop tier that lets a single operation iterate a large collection at O(1) graph cost, rather than unrolling it, is designed and in progress. The lifted bounds land with that tier; until then, collection work is bounded by the node budget, and pages say so.

3. Typed, GPU-native, safe user interface. Flux renders interactive islands — a live chart, a dashboard, a data-visualisation, a 3-D scene, a small application. The output is host-painted on the GPU: scene graphics and text both render through WebGPU in 2-D and 3-D alike — 2-D is the flat case of the one GPU engine, text an SDF glyph atlas crisp at any zoom — and the parts that move the most cost zero JavaScript per frame. Every island is safe to run even when its author is a stranger. The chart surface is real today; the typed style vocabulary that closes the gap with hand-written CSS is designed and named as it lands, and a general 3-D scene surface beyond the chart’s own is held open and inert.

#The moat — what a stack does not give you

A conventional interactive, data-rich page is assembled: 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 assembly, and it carries four properties the assembly cannot:

• Totality. Every program terminates and states its bounds at compile time. There is no runaway loop to time out, no unbounded work to cap at runtime.
• Byte-identical determinism. The same program produces the same bytes on every machine, interpreter and compiled module alike — verified at every compilation (invariant I7). This is what makes replay, and therefore server-checkable anti-cheat, possible; a general-purpose UI stack cannot promise it.
• Bounded memory, zero steady-state allocation. The memory plan is computed at compile time and declared to the module; the running program allocates nothing per step.
• Capability safety by construction. The language has no ambient I/O to abuse. Every effect is a declared capability, default-deny, carried in an inspectable manifest. Running a stranger’s program is a routine act, not a risk assessment.

Why this framing is allowed. This is a contrast of category — one language versus an assembly of libraries — not a comparison with any named product. It names nothing and disparages nothing; it states the scope of the language positively. That distinction is the rule, not a loophole: see the style contract, §2.

#The islands model

Flux does not replace the web page; it inhabits it. A page is a static HTML shell — cheap, fast, indexable — with interactive <div> islands rendered by Flux where the content is live, rich, or visual. The server-side prerender and the live client island are two halves of the same output membrane: the shell carries the prose and the search-engine surface, the island carries the parts a static page cannot do at all.

This is why “should the site be built in Flux?” has a precise answer: the shell is ordinary web; the islands are Flux, and they are the credible part.

#Safety by construction

A free CSS or HTML string is the one real injection surface a UI language exposes — it can smuggle a script, an off-origin URL, or a tracking pixel past any reviewer. In Flux that surface is not filtered; it is structurally absent. No constructor produces a raw style string, and the lexer carries no such literal. Visual richness — background, border, radius, shadow, gradient, typography — arrives as typed style props the host validates and applies, never as a string the script hands over.

Why this rule exists. A sanitizer is a filter, and filters leak; new escapes are found against them for as long as they exist. A closed, typed vocabulary has nothing to filter. This is what lets a stranger’s island render beside yours and touch none of the data your own logic depends on. It is not a promise enforced by review — it is a property enforced by the shape of the language.

#The flagship — financial charting

Financial charting and market analytics are the flagship: the origin of the language and the proof that it carries real, demanding applications. But charting is a domain that rides on top of the model, not the model itself. Two market assumptions are baked into the substrate — the six source columns of a price series, and the morph chart transition literal — and the documentation carries them as the flagship’s fingerprints, stated plainly rather than apologised for. Everything else in the language reads correctly to someone who has never traded.

#Dogfood — this site is the proof

This documentation and the site around it are built to be live Flux islands rendered by the real engine: a running example beside its own code, a playground, a hero that computes rather than depicts. The most credible statement a language can make about its reach is not a paragraph — it is the reader watching the language do, on the page, what the page claims. Where an example is not yet live, the page says so; the honest form of a demo is one that runs.

#Honest status — real versus in progress

The reframe of this documentation from “a charting language” to “a general-purpose language with a charting flagship” is a change of framing, and the framing must never outrun the engine. The discipline, applied on every page:

• Prose and figures are general-purpose; the domain name is a parenthetical gloss.
• A runnable sample on the ANALYSIS plane stays a charting sample where that is what runs today — the engine type-checks the analysis plane, so an invented domain variable would be a fiction the gate rejects. That is not skew; it is pillar 1 being real while pillars 2 and 3 are still landing.
• Anything designed but not shipped is described in the present tense, with any held-back rollout or reserved seam explained where it arises; the single source of truth for status is the matrix in README and FDK index.

A trust page that only lists strengths is a sales page. This one names its frontier.

#See also

• What is Flux — the mental model: streams, the four planes, what a program is.
• Design pillars — the seven formal guarantees behind the identity above.
• The four planes — compute · show · animate · interact, and the firewall.
• FDK · display — scenes, islands, the 2-D/3-D surfaces, the typed style membrane.
• README — the documentation map and the implementation-status matrix.