Why Svelte and Kotlin

Texuli renders the web with Svelte 5 and speaks to native platforms throughKotlin. This page explains why both were chosen, what each owns, and how the same component catalog drives the two runtimes.

Why Svelte

Texuli ships as compiled source, not as a runtime you download. Svelte is a compiler: a component becomes plain JavaScript that touches the DOM directly, with no virtual DOM diffing and no framework runtime carried in the bundle. That maps directly onto Texuli's promises:

• Performance is structural, not tuned. There is no reconciliation layer to outgrow. Updates land on exactly the nodes that changed, which is what keeps dense surfaces — grids, charts, decks — inside their size and interaction budgets.
• Small bundles by default. Each subpath is budgeted intexuli.budgets.json and measured by pnpm size; a compiler that emits only what the component uses makes those budgets honest ones.
• Runes make state explicit. Svelte 5's $state,$derived and $effect put reactivity in the language surface, so component contracts stay readable and auditable — important for a library that is designed to be read, copied and owned by agents and humans alike.
• Fewer ways to shoot yourself. Snippets over injection holes, noinnerHTML idiom in the mainstream path, and compile-time warnings on the accessibility mistakes Texuli is held to anyway.

Why Kotlin

The web runtime cannot follow Texuli everywhere. Android applications, Compose surfaces, iOS sharing and desktop tooling live in a world where a JavaScript bundle is the guest, not the host. Kotlin Multiplatform is the bridge:

• One language across the native side. Shared data models, validation and catalog logic compile once per platform instead of being re-written per target.
• First-class tooling. Static typing, multiplatform libraries and IDE support keep the native half held to the same bar as the web half.
• It consumes the contract, not the web code. Kotlin never imports Svelte packages; it reads the generated spec (see below). The layer graph stays one-directional.

One catalog, two runtimes

The seam between the two worlds is the catalog contract: every Texuli component's props, kinds, enums and tiers are declared once in the manifests, and@texuli/spec generates both a TypeScript and a Kotlin projection of that contract (packages/spec/generated/typescript/ andpackages/spec/generated/kotlin/com/texuli/spec/). Svelte components implement the contract on the web; Kotlin consumes it wherever Svelte cannot go. Agent output rendered on either runtime is validated against the same schema with the same URL policy tiers.

What exists today

Honesty first: the web stack is the implemented one. The Svelte packages, the token engine, the catalog, the spec generator and both generated projections are real and tested today; the Kotlin Multiplatform runtime that would consume the Kotlin projection is planned work and not yet released. Nothing is on npm, in Maven, or deployed.