I Built a Rust-Native Web Framework That Can Explain Every Build
I kept running into the same uncomfortable gap in modern web tooling. We are very good at producing interfaces. We are much worse at explaining them. Which input produced this file? Why did this route rebuild? Can the application replay its state and reach the same result? When a WebGL scene disappears, who owns the cleanup? Can the release I downloaded be tied back to an exact source commit? Those questions became the starting point for PliegoRS, a Rust-native web framework for verifiable, repl
I kept running into the same uncomfortable gap in modern web tooling.
We are very good at producing interfaces. We are much worse at explaining them.
Which input produced this file? Why did this route rebuild? Can the application replay its state and reach the same result? When a WebGL scene disappears, who owns the cleanup? Can the release I downloaded be tied back to an exact source commit?
Those questions became the starting point for PliegoRS, a Rust-native web framework for verifiable, replayable, durable interfaces.
Today I am releasing PliegoRS 0.0.1 as an Apache-2.0 public preview.
This is not a JavaScript-free purity project
The principle behind PliegoRS is simple:
The framework owns the system. The browser owns the medium.
Rust owns the authored application model: routes, typed views, content, events, folds, reactive state, build artifacts, diagnostics, and the client behavior that benefits from Rust/WASM.
The browser still owns the browser. PliegoRS does not try to reimplement GSAP, Lenis, Three.js, WebGL, or the platform APIs they already use well. Mature JavaScript libraries remain JavaScript, but they run behind an explicit lifecycle boundary instead of becoming invisible global state.
The goal is not fewer technologies at any cost. The goal is clearer ownership.
1. An interface can be a projection, not just a mutable snapshot
The default PliegoRS application starts with typed, versioned events and a fold that projects those events into state.
typed events -> append-only log -> deterministic fold -> interface
| |
| +-> snapshot
+-------------------> replay
Enter fullscreen mode Exit fullscreen mode
A reducer must be pure. A replay of the same admitted history must produce the same projected state. Snapshots are bound to the event head, schema set, reducer identity, codec configuration, and canonical state bytes.
That makes features such as history, undo, provenance, audit, and synchronization part of the application model rather than an afterthought bolted onto components.
Static projects do not need a database. When durable synchronization is required, PliegoRS exposes a verified protocol boundary for Hyphae, but the framework does not claim that a production Hyphae gateway exists in this preview.
2. A build should leave evidence
Most build tools tell you whether a build succeeded. PliegoRS also tries to preserve enough evidence to explain what happened.
Every successful build emits a deterministic output ledger and a causal graph. The CLI can answer questions about individual artifacts and rebuild decisions:
pliego inspect
pliego why artifact /journal/index.html
pliego why-rebuilt
Enter fullscreen mode Exit fullscreen mode
The output pipeline guards its namespace, stages changes before publication, hashes emitted artifacts, and records the inputs that influence the result. A content hash is integrity evidence, not authorship, so PliegoRS keeps that distinction explicit.
The 0.0.1 GitHub release goes further: it contains five target archives, SHA-256 files, a two-replica reproducibility record, and an Ed25519-signed exact-set manifest. The release was built from commit e4d0d3d.
This is not a claim of a perfectly hermetic universe. It is a practical attempt to make release claims inspectable instead of implicit.
3. Imperative browser code needs an owner
Visual websites need animation, smooth scrolling, 3D, media, and direct access to browser APIs. Pretending otherwise only pushes those concerns into unmanaged scripts.
PliegoRS adapters have a versioned mount / update / unmount contract. The runtime owns admission, lazy triggers, cancellation, reduced-motion and Save-Data policy, error isolation, and deterministic LIFO cleanup.
An adapter can still use the natural API of its library:
export async function mount(node, context) {
const scene = createThreeScene(node, context);
return () => {
scene.dispose();
};
}
Enter fullscreen mode Exit fullscreen mode
The difference is that teardown is no longer a convention hidden in a component. It belongs to a framework-owned lifecycle. If a mount is cancelled, fails, or leaves the document, its resources still have an explicit owner.
Useful HTML first, Rust/WASM by intent
PliegoRS emits complete static documents with typed metadata, safe HTML defaults, routes, content, assets, and SEO. A static page does not need a framework runtime to remain useful.
Rust/WASM resumes only the behavior the document needs. External browser libraries are loaded only when their declared policy admits them. Adaptive media plans can account for viewport tier, Save-Data, reduced motion, and transfer budgets before a heavy asset is selected.
That division matters to me: the first response should be a document, not a promise that a document will eventually appear.
Try the public preview
You need Rust 1.85 or newer.
cargo install pliego-cli --version 0.0.1 --locked
pliego new field-notes
cd field-notes
pliego check
pliego dev
Enter fullscreen mode Exit fullscreen mode
The default starter is a small replayable application, not an empty marketing screen. Three additional maintained templates are included:
pliego templates
pliego new my-journal --template editorial
pliego new my-film --template cinematic
pliego new tiny-site --template minimal
Enter fullscreen mode Exit fullscreen mode
Linux production binaries and macOS/Windows development binaries are also available in the signed GitHub release. Download them to disk and verify the release bundle before running them; the project deliberately does not recommend piping an installer from the network into a shell.
What is actually in 0.0.1?
The preview includes:
- deterministic static generation with typed routes, heads, assets, and build ledgers;
- a typed view macro, signals, memos, effects, ownership scopes, and cleanup;
- typed Markdown, JSON, and TOML content collections;
- typed/versioned events, transactional folds, snapshots, and exact-tail replay;
- Rust/WASM clients and resumable standard browser actions;
- lifecycle adapters for external ESM libraries;
- adaptive plans for images, video, fonts, and 3D assets;
- native-event development, preview, structured diagnostics, causal inspection, and typed HMR;
- default, minimal, editorial, and cinematic starters;
- fifteen published Rust crates and a cross-platform release pipeline.
The documentation site is built with PliegoRS itself and covers the framework contracts, security boundaries, release verification, starters, content, lifecycle adapters, and the Hyphae protocol boundary.
What it does not claim yet
0.0.1 is pre-1.0 software. APIs may evolve between minor releases.
PliegoRS does not yet claim broad server-framework parity, production-verified Hyphae synchronization, signed production support for the macOS and Windows artifacts, or 1.0 stability. The current strongest path is deterministic static generation with focused Rust/WASM interaction and explicit adapters for browser-native libraries.
I would rather publish a narrow, testable boundary than hide unfinished systems behind a large version number.
Why release it now?
A framework cannot become useful in isolation. It needs projects that stress its assumptions, developers who dislike its ergonomics, and bug reports that its own test suite did not imagine.
So the first public preview is an invitation to challenge the model:
- Create a project.
- Build it twice.
- Inspect the ledger.
- Add a small Rust/WASM interaction or a JavaScript lifecycle adapter.
- Tell us where the framework stops helping.
Start with the source on GitHub, read the documentation, or inspect the pliego-cli API docs.
If the web framework you want is one that can explain its state, its artifacts, and its ownership boundaries, I would genuinely like to hear what you build with PliegoRS.
PliegoRS is an Apache-2.0 project by Celiums Solutions LLC.
