Quark Virtual DOM architecture

Quark Virtual DOM

A virtual DOM exposing the entire QuarkXPress API. Every application setting, every open document, every page, every text box, every measurement — addressable as a node in a standard DOM tree. A scripting client could read or write any part of the running application without a custom per-feature binding. Years before the browser-side virtual- DOM idea entered the public conversation, the same shape was running production at Quark — applied to a desktop publisher instead of a web view.

Era

Quark Inc. · Denver office · May 2000 – March 2005 · 4 years 11 months · Software Engineer III · directly post-MS thesis

Substrate

C++ · QuarkXPress runtime · Mac OS Classic / Mac OS X · Windows · COM bindings on the Windows side

Application

QuarkXPress — the desktop publishing application that defined a generation of print and layout work. quark.com

Lineage back

Carries forward the self-describing posture from the 2000 BML thesis — a system that describes its own structure to itself. BML's grammar parsed itself; the Quark Virtual DOM made QuarkXPress query and mutate itself.

Lineage forward

The everything-is-a-node primitive that became U-CORE in Living-Codex-CSharp and the live-graph data layer in Coherence-Network is the same conviction at network scale — the Quark Virtual DOM was the desktop-app form of the same idea.

The shape of the API

The conventional way to expose a desktop application's API in 2000-era C++ was binding-per-feature: one C function or COM method for each thing the API needed to surface, hand- written, hand-versioned, exposed through a SDK. AppleScript on the Mac side, COM Automation on the Windows side. Every new feature meant a new pair of bindings. The surface area grew faster than the team's capacity to keep it consistent.

The Quark Virtual DOM took the opposite turn. Instead of exposing N APIs, it exposed one API — the standard DOM interface — and made every application object reachable as a DOM node. The running application became a live tree. Settings, documents, pages, text boxes, picture boxes, style sheets, colors, hyphenation rules — each appeared as a node with attributes, children, and the standard DOM operations (getElementById, , ) acting on real application state.

Sample · what a script saw

QuarkXPress as a tree

A script using nothing more than the standard DOM interface — the same shape any web developer was already fluent in — could now drive a desktop publisher:

{`// Read an application-wide preference
const units = xpressDom
  .getElementById('preferences')
  .getAttribute('measurements/units');

// Walk the document tree
const docs = xpressDom.documentElement.children;          // open documents
const firstDoc = docs[0];
const page3 = firstDoc.querySelector('page[index="3"]');
const titleBox = page3.querySelector('text-box[role="title"]');

// Mutate live state — change is reflected immediately
titleBox.setAttribute('font-family', 'Adobe Caslon Pro');
titleBox.setAttribute('font-size', '24pt');
titleBox.firstChild.textContent = 'New headline';

// Listen for changes anyone makes (script, user, plug-in)
firstDoc.addEventListener('attribute-changed', (e) => {
   console.log(e.target.path, e.detail.attr, e.detail.from, e.detail.to);
});`}

Standard idioms — getElementById, querySelector, setAttribute, addEventListener — performing real desktop-app operations. A QA harness could drive QuarkXPress through arbitrary keystrokes by setting attributes. A plug-in could register for change events on any path. An external automation tool could open a document, edit ten boxes, save, and exit — without a single QuarkXPress-specific API call.

The shape is elegant; the implementation was load-bearing. Three things had to be true at once:

Lazy materialization. A QuarkXPress document with hundreds of pages and thousands of objects cannot have all those nodes pre-allocated. Nodes had to materialize on traversal — a child request walked into the underlying C++ object graph and minted the node on demand. GC of unreferenced nodes had to happen invisibly.
Bi-directional change propagation. A script's setAttribute had to land in the real C++ state and trigger every redraw, undo-record, and document-changed notification a user-driven equivalent action would. Symmetrically, a user dragging a box had to make the corresponding DOM attributes update so any listening script saw the change.
Type-tagged dynamic schema. Every node kind had its own attribute set; the resolver had to know what attributes were valid on text-box versus picture-box, what type each attribute carried (point, color, font identifier, percentage), how to coerce string values the DOM API enforced. Dynamic creation of nodes and attributes meant the schema had to be queryable from the API too — the DOM described its own shape.

That last point is the deep one. The tree wasn't a fixed DTD. New plug-ins added new node kinds. New document features grew the attribute vocabulary. The Virtual DOM had to stay self-describing — clients could ask the tree what it could do, and the tree would answer. That's the same posture the 2000 BML thesis committed to with grammar-in-grammar — and the same posture that, twenty-some years later, Coherence-Network now lives at the network scale.

Quark Virtual DOM

The shape of the API

Why this was hard