Skip to content

CONCEPT Cited by 1 source

UI primitives as platform building blocks

Definition

A UI primitive in a server-driven or declarative UI system is a leaf-level component that:

  1. Lives in the client binary, not on the server.
  2. Has a stable, typed contract — (props, events) → rendered output.
  3. Is minimal in count — a small fixed alphabet the server composes rather than a large catalogue of pre-composed shapes.
  4. Is composable — arbitrarily deep trees of primitives compose into complex UI.

The discipline is to keep the client-side vocabulary narrow and stable, and push all composition / variant work onto the server. New primitives require a client release; new screens built from existing primitives do not.

The explicit list in Appcraft

Appcraft names 5 foundational primitives:

  • Label — styled text.
  • Button — tap-target with text/icon.
  • Image — static / networked image.
  • Video — media player.
  • Layout — the composition container, using Flex.

(Source: sources/2024-05-15-zalando-transitioning-to-appcraft-evolution-of-zalandos-server-driven-ui-framework.)

Per the post: "With these foundational elements in place, developers possess the flexibility to combine and customise them according to their application's unique requirements, unlocking a plethora of possibilities for UI design and interaction."

Non-primitives (higher-level components) get composed on the server by arranging primitives in a Flex tree with appropriate props and event wiring. No client-side notion of "a Tile", "a Product Card", "a Promo Banner" exists — all three are different tree arrangements of the same primitives.

Contrast with Composed Tiles (TNA)

TNA, Appcraft's predecessor, went the other way: the client bundled Composed Tiles — named high-level units (e.g. "Showstopper Tile") each with their own schema and variants ("Version C", "Version D"). This caused:

  • Variant proliferation on the client side (each new design variant → client release).
  • Small UI changes require a release (move a button → new Tile version).
  • Backward compatibility complexity because the server had to know which Tile versions each client supported.

Appcraft's move to primitives is precisely a shrinking of the client's responsibility surface: from "understand N high-level UI concepts" to "render M low-level building blocks". See concepts/client-release-needed-only-for-new-primitives for the release-boundary consequence.

Extension discipline

Per the Appcraft post, new primitives do get added — the example cited is Composite Label, added later when a plain Label wasn't sufficient to render prices (needed sub-texts with different font styling, decorations, sizes). The discipline is to extend only when the existing primitive can't express the need via any combination of its props — and to prefer extending an existing primitive's contract over adding a brand-new one.

Why minimal primitives work for SDUI

Three properties matter:

  • Small surface area = easier to keep parity between iOS + Android implementations. A 5-primitive vocabulary is much less work to reconcile than a 50-tile catalogue.
  • Stability = primitives change slowly, so the client-server contract is durable. New screens don't force primitive changes.
  • Composability = any complex UI expressible as a Flex-arranged primitive tree, which the server can ship without a release.

Adjacent concepts

Precedent

  • HTML is effectively a browser-rendered primitive vocabulary (<div>, <span>, <img>, <button>, <video>, <a>); the server composes them into arbitrary pages. Appcraft's primitives mirror HTML's shape on mobile.
  • React Native core components (<View>, <Text>, <Image>, <ScrollView>) — same small-alphabet idea.
  • React Strict DOM (html.div, html.span) — RSD's deliberately narrow HTML subset is the same discipline applied to cross-platform React apps.

Seen in

Last updated · 550 distilled / 1,221 read