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).