Skip to content

SYSTEM Cited by 1 source

Figma Instance Updater (retired 2026)

What it was

Instance Updater was Figma's 2016-era runtime responsible for maintaining component instances — smart copies of a main component that stay in sync as the main component changes. It resolved instance properties, managed their structure, and kept them in sync with their backing component. It was retired in 2026, replaced by the generic Materializer framework.

Recorded here for historical context — Materializer's design is largely shaped by the accumulated pains of Instance Updater's decade of feature accretion.

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

Original 2016 design (as remembered in 2026)

  • Self-contained runtime — owned all instance-related logic internally.
  • Delegation target for other systems — layout engines called into Instance Updater whenever they encountered an instance; same for other subsystems.
  • Fit for its time — 2016 instance behavior was simple; Figma's client runtime was less complex. The insulated design "made sense."

Feature-accretion pressure (2019–2024)

Each wave of new parametrization / layout features required adding "specialized, bespoke logic" inside Instance Updater:

  • 2019: auto layout.
  • 2020: variants.
  • 2022: component properties.
  • 2023: variables.

By 2024–2025, a modern Figma instance could simultaneously use variants, have variable bindings, apply auto layout, nest other instances with their own overrides, carry variable modes, and participate in layout rules. Instance Updater had accreted handling for every combination. Each integration was "a careful dance that was powerful when it worked, but increasingly fragile and slow as responsibilities piled up."

Named failure modes at worst cases

  • Cascade amplification: single variable-mode change could trigger instance updates + layout recalcs across thousands of nodes.
  • Subsystem fighting: "Different systems would 'fight' over the same subtree, repeatedly invalidating each other." No shared runtime orchestration.
  • Editor-locking operations: instance swap or property change could take seconds in the worst cases.
  • Blurred separation of concerns: Instance Updater was doing its own auto layout and variable evaluation, not just instance resolution.
  • Whole-instance invalidation: "The old system updated entire instances whenever anything changed," even when only a single property had actually changed.

Why incremental optimization exhausted

"As our users built design systems of growing complexity […] we optimized where we could. But the underlying problem remained: A system designed for simple component copies was now responsible for coordinating layout, variables, and reactivity at massive scale."

The substrate assumption (self-contained runtime that also coordinates everything else) was structurally wrong for the 2025 workload; patching around it couldn't recover the lost perf.

What Materializer changed

  • Factored out the generic "maintain a derived subtree from a source" concern into a framework (concepts/derived-subtree).
  • Component instances become one blueprint; rich text is another; slots composes on top.
  • Layout logic moved to layout systems; variable evaluation moved to variable systems; Instance Updater's bespoke responsibilities evaporated.
  • Invalidation granularity moved from whole-instance to property- granular (concepts/push-based-invalidation).
  • Runtime subsystems unified under a shared orchestration layer, moving toward unidirectional flow and eliminating back-dirties (concepts/back-dirty / patterns/runtime-orchestration-unidirectional-flow).

Not documented

Figma's 2026 post is a retrospective from the replacement team; it does not detail Instance Updater's internal architecture, data structures, or sizing. What we have is the summary framing: self-contained runtime, delegation target, feature-accreted, whole-instance invalidation, subsystem-fighting.

Seen in

Last updated · 200 distilled / 1,178 read