shard-wiki/research/260614-processing-deep-dive/findings.md

# Processing & Processing.js — deep dive (findings)

**Date:** 2026-06-14 · **Source:** SHARD-WP-0004 T4 · **Subject:** Processing (creative
coding) and Processing.js / p5.js — **the sketch *is* the document**, rendered live at view
time in the browser.

## Why this dive

Low-priority, enrichment-focused. Processing tests a page-model edge the notebooks (T2/T3)
didn't: a page that is **wholly a program whose presentation *is* its running output** — no
separate input/output cells, no prose envelope. The defining question: what is a "page" when
**the rendered form is a live computation evaluated at view time**? It feeds UC-54
(computation-defined content) and UC-55 (non-Markdown / executable content) and sharpens the
**live↔snapshot** axis named at T6.

## 1. Program-as-page

- A **Processing sketch** is a program (`setup()` + `draw()`) whose output is a **canvas of
  visual/animated/interactive content**. There are no "output cells" — **the program's
  execution is the content**.
- **Processing.js** (Resig, 2008; now largely **p5.js**) runs sketches **client-side in the
  browser** on `<canvas>`. The page ships the **source**; the **rendering happens at view
  time** in the reader's browser — no server, no pre-rendered artifact required.
- So the durable artifact is **text (the sketch source)**; the *presentation* is a **live,
  view-time derivation** of that source (a derivation-projection, T1) — with the twist that
  the derivation runs **in the viewer**, continuously (animation/interaction), not once.

## 2. The view-time / live-render dimension

This adds a wrinkle beyond Jupyter's *captured* outputs (UC-84) and Mathematica's CDF:

- **No captured output at all by default** — unlike a notebook, a sketch typically stores
  **only source**; there is nothing cached. The output exists only when executed.
- **Continuous & interactive** — `draw()` loops; mouse/keyboard drive it. The output is
  **time-based and interaction-based**, so any static capture is a **single frame** (or a
  recording) — it cannot represent the artifact faithfully (shared limit with Mathematica
  `Dynamic` and, more extremely, Strudel T5).
- **Client-side execution = a capability + trust surface** — running arbitrary sketch code in
  the viewer is an execution capability with sandboxing concerns; shard-wiki must treat
  "render live in the viewer" as an explicit, gated capability, never an automatic behavior.

## 3. INTENT mapping (enrichment-only — no new UC)

### Reinforcements / refinements

- **Executable-as-page (UC-54/55).** Processing is the cleanest **"the whole page is the
  program"** case: content = source text, presentation = view-time live render. Strengthens
  the page model's need to represent **executable content whose rendered form is derived at
  view time**, distinct from notebooks (which interleave cells + captured outputs).
- **Derivation-projection, view-time variant (T1/UC-83).** The render is a derivation-
  projection that runs **in the viewer, continuously** — extends the projection model: a
  derivation may be *materialized ahead* (CDF/nbconvert) or *run at view time* (sketch).
- **Live↔snapshot axis (T6).** With **no cached output** and **continuous/interactive**
  rendering, the only static form is a **snapshot frame or recording** — a concrete point on
  the live↔snapshot axis; honest treatment offers the snapshot and **marks it as a frame of a
  live artifact**, never as the artifact.
- **Capability + trust gating.** "Execute in the viewer" is an explicit capability with a
  sandbox/trust boundary — mechanism-over-policy: whether to run, sandbox, or only snapshot
  stays configurable.

### Boundaries

- shard-wiki is **not a sketch runtime**; default is **attach the source + offer a captured
  snapshot/recording**; live in-viewer rendering is a gated capability. Source is canonical;
  the render is a degrading, view-time projection.

## 4. UC disposition (enrichment-only)

| Mechanism (findings §) | Catalog UC / thread |
|------------------------|---------------------|
| Sketch = program-as-page; presentation = view-time live render (§1) | UC-54 (enriched: executable/view-time content), UC-55 (enriched: non-Markdown executable) |
| Render = derivation-projection run **in the viewer, continuously** (§1, §2) | links UC-83 (view-time variant) |
| No cached output; continuous/interactive → static = snapshot frame only (§2) | links UC-84, live↔snapshot axis (T6) |
| Client-side execution = capability + trust/sandbox surface (§2) | links UC-35 (capability-awareness) |

**No new UC** — Processing is design prior art reinforcing executable-as-page; its
contribution is the **view-time, no-cached-output, continuous-render** point on the
projection/liveness model.

## 5. Architecture notes for SHARD-WP-0002

- **T12/T15 (page model):** represent **program-as-page** — a page whose canonical content is
  **source text** and whose presentation is an **executable render**; no inherent cached
  output (contrast notebooks). Non-Markdown executable content type.
- **T16 (projection):** add a **materialization timing** facet to derivation-projection:
  **ahead-of-time** (CDF/nbconvert/static HTML) vs **at view time** (sketch render); and a
  **continuity** facet: one-shot vs continuous/interactive. Continuous → static is a snapshot
  frame/recording on the live↔snapshot axis (T6).
- **T11 (capabilities):** "execute/render in the viewer" is a capability with a **trust/
  sandbox** sub-concern; default off → snapshot.

## 6. Open questions

1. Is **view-time execution** ever offered (sandboxed in-viewer render), or does shard-wiki
   always degrade program-as-page to a captured snapshot/recording? (Capability/trust policy.)
2. Should **materialization timing** (ahead-of-time vs view-time) and **continuity**
   (one-shot vs continuous) be explicit projection metadata, alongside the live↔snapshot
   axis? (Recurs at T5.)

## 7. Sources

- `processing.org`; **p5.js** (`p5js.org`); Processing.js (Resig) history; `<canvas>` /
  client-side rendering model.
- prior: `research/260614-jupyter-deep-dive/` (captured vs no-cached output, UC-84);
  `research/260614-mathematica-deep-dive/` (`Dynamic`/CDF, snapshot-only);
  `research/260614-squeak-pharo-deep-dive/` (live↔snapshot axis).

## 8. Traceability

**No new UC** (enrichment / design prior art). Enriched: UC-54, UC-55; links UC-83 (view-time
derivation-projection), UC-84 (no-cached-output contrast), UC-35 (execute capability +
trust). Architecture cross-refs: SHARD-WP-0002 T12/T15 (program-as-page, source-canonical/
render-derived), T16 (materialization-timing + continuity facets on the live↔snapshot axis),
T11 (view-time-execute capability + sandbox).