Skip to content

SYSTEM Cited by 1 source

Figma Materializer

What it is

Materializer is Figma's generic client-runtime framework (shipped 2026 after a year-long rewrite) for creating and maintaining derived subtrees of the document tree — subtrees whose structure and properties are computed from other sources of truth via feature-owned blueprints. It replaces Instance Updater, the 2016-era component-instance runtime that had grown specialized logic for auto layout, variants, component properties, and variables over a decade of feature accretion.

(Primary source: sources/2026-04-21-figma-rebuilt-foundations-of-component-instances)

Why

Component instances — "smart copies" of a main component that stay in sync — were the single use-case Instance Updater was designed around in 2016. By 2024, they could layer variants, variable bindings, auto layout, nested instances with their own overrides, variable modes, and layout rules. Instance Updater kept accreting bespoke logic for each new feature. Named failure modes at the worst cases:

  • Single variable-mode change cascading to thousands of nodes in some files.
  • Different subsystems "fighting" over the same subtree, repeatedly invalidating each other.
  • Instance swap or property change taking seconds, locking the editor.
  • Instance Updater doing its own auto-layout and variable-evaluation work, violating separation of concerns.

With slots (announced 2025, open beta 2026) on the roadmap — explicit customizable nested-content regions — the complexity ceiling was visibly about to grow further. The team decided the substrate needed to be rewritten, not patched.

Architecture

The abstraction

Materializer operates on derived subtrees of Figma's document tree. For any derived subtree:

  1. A source of truth lives elsewhere (for component instances: the main component; for rich text: the rich-text block list; potentially: a CMS document).
  2. The feature provides a blueprint — code that reads the source and describes what the subtree should look like.
  3. Materializer runs the blueprint and materializes the subtree into the document.
  4. As the blueprint reads source data, Materializer records those reads as dependencies (see concepts/automatic-dependency-tracking).
  5. On source changes, Materializer marks affected derived subtrees dirty (see concepts/push-based-invalidation) and re-materializes only what actually changed.

The canonical framing:

"The instance system would focus solely on what it did best: dynamically resolving which properties and children an instance should have based on its main component."

Same applies by contract to rich text, to slots, and to future derived-subtree features.

Reactivity choice

Push-based invalidation, with automatic dependency tracking. Pull-based (React-style) was explicitly rejected because Figma's "cross-tree references and deeply nested dependencies" force reconstructing large portions of the dependency chain on every read. Push is expensive on writes but cheap on reads; Figma's workload is read-heavy (rendering + editing) so the trade favors push. Auto- tracking is the refinement that makes the explicit dep graph correct-by-construction rather than hand-declared (removes the drift-between-declared-and-actual-reads bug class that QueryGraph had to shadow-validate the hand-enumerated edges against).

Runtime orchestration

Materializer doesn't operate in isolation. Figma's client has grown into "a set of powerful runtime systems, including layout engines, variable resolvers, and constraint enforcers that all respond to changes in the document." The second thrust of the Materializer project: unify all of these under a shared runtime orchestration layer that runs updates in a predictable order. The patterns/runtime-orchestration-unidirectional-flow pattern is the result.

Predictable ordering surfaced previously-hidden back-dirties (concepts/back-dirty) — feedback loops where later subsystems invalidated earlier ones and forced re-runs. "Making them explicit helped us eliminate many of them and move closer to a more unidirectional flow."

Post-unification ownership

  • Layout logic lives in layout systems.
  • Variable logic lives in variable systems.
  • Instance resolution lives in Materializer (as one blueprint among several).
  • No subsystem has special-case branching for instances anymore.

"Product teams can now own their features vertically, building on shared infrastructure instead of re-solving the same orchestration problems."

Shipped features on top

  • Component instances — ported from Instance Updater to Materializer as the motivating use case.
  • Rich text nodes — first net-new feature built on Materializer. Rich-text blocks (<h1>, <p>, <img>) feed the blueprint; Materializer creates text/image nodes that stay in sync with CMS-sourced content.
  • Slots (open beta, April 2026) — "built by composing on top of the new architecture rather than introducing another bespoke system." Slots define flexible regions for nested customized content; the customization logic composes over Materializer's blueprint-and-derive primitive.
  • "Other teams across Figma's products are already building on the Materializer framework to ship new kinds of dynamic content."

Rollout

Side-by-side runtime validation for months. Specifics (Source: post):

  • Scale: hundreds of thousands of real production files.
  • Comparison: data models + rendered output + performance.
  • Gate: rollout began only after both correctness AND performance matched.
  • Perf trade-off tracked: automatic reactivity required "additional dependency caches" — improved interactive perf, with potential cost on file load time and memory usage. Tracked in the same validation framework alongside correctness; targeted optimizations landed before rollout.
  • Staged production rollout: after parallel validation cleared.

See patterns/side-by-side-runtime-validation for the generalised pattern.

Reported impact

  • Variable-mode changes in large files: 40–50% faster — "one of the most expensive cases […] representative of the broader gains we saw across common instance edits."
  • Swap-instance and nested-component edits "significantly faster."
  • Eliminated entire classes of subtle bugs where subsystems fought over the same subtree.
  • Developer velocity — framed as "perhaps the biggest return": rich text + slots + other in-progress features ship on the shared framework instead of each reimplementing reactivity.

No absolute latency or memory numbers disclosed.

Interplay with other Figma client systems

Figma's client now has at least three reactive graphs over the object-tree document model, each indexing different edges:

System Edges indexed Responsibility
QueryGraph Read+write deps between document nodes (FK edges + implicit layout/constraint edges) Per-session subscription + edit fan-out in the collab server
Parameter Runtime Parameter-to-bound-property edges Reactive re-resolution when parameter values change
Materializer Source-of-truth → derived-subtree edges, recorded implicitly by read tracking Derived-subtree maintenance for instances / rich text / slots / future dynamic content

All three share "bidirectional in-memory index over document state, maintained by the client runtime, property-granular invalidation." All three sit on top of the same object-tree data model. They differ in what edge they index and which subsystem consumes it.

The 2026 runtime-orchestration unification (see patterns/runtime-orchestration-unidirectional-flow) is the substrate they now interoperate through.

Not disclosed

  • Absolute latency / memory / throughput numbers for Materializer stages.
  • Dependency-tracking implementation mechanism (read-hook vs proxy vs tracking context).
  • Memory cost of dependency caches at production-file scale.
  • Which specific subsystems had back-dirties; how many were eliminated; how many remain.
  • Migration strategy for existing files from Instance-Updater state to Materializer state.
  • Concrete scheduling algorithm in the runtime orchestration layer.
  • Interaction with server-side QueryGraph when Materializer's re-materialization produces document-node mutations that must be synced to collaborators.

Seen in

  • sources/2026-04-21-figma-rebuilt-foundations-of-component-instances — canonical source. Architecture description, push-vs-pull trade-off framing, automatic-dep-tracking commitment, runtime-orchestration unification, back-dirty concept, side-by-side validation rollout, variable-mode 40–50% perf win, rich-text + slots as composition proofs.
Last updated · 200 distilled / 1,178 read